Commit Graph

4687 Commits

Author SHA1 Message Date
Kristóf Umann fb4d590a62 Fix a unittest file after D108695 when Z3 is enabled 2021-09-14 16:11:11 +02:00
Corentin Jabot 601102d282 Cleanup identifier parsing; NFC
Rename methods to clearly signal when they only deal with ASCII,
simplify the parsing of identifier, and use start/continue instead of
head/body for consistency with Unicode terminology.
2021-09-14 09:12:22 -04:00
Kristóf Umann 0213d7ec0c [analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it
Fix a compilation error due to a missing 'template' keyword.

Differential Revision: https://reviews.llvm.org/D108695
2021-09-13 13:50:01 +02:00
owenca 3205dd3d59 [clang-format] Restrict the special handling for K&R C to C/C++
Commits 58494c856a, f6bc614546, and 0fc27ef196 added special
handlings for K&R C function definitions and caused some
JavaScript/TypeScript regressions which were addressed in D107267,
D108538, and D108620. This patch would have prevented these known
regressions and will fix any unknown ones.

Differential Revision: https://reviews.llvm.org/D109582
2021-09-10 15:51:35 -07:00
Jan Svoboda 8dc76ab799 [clang][tooling] Properly initialize DiagnosticsEngine for cc1 command-line construction
In `ToolInvocation::run`, the driver -> cc1 command-line transformation uses `DiagnosticsEngine` that wasn't completely initialized. This patch ensures `ProcessWarningOptions(DiagnosticsEngine&, const DiagnosticOptions &)` is called.

Depends on D108982.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D108974
2021-09-10 13:54:24 +02:00
Kadir Cetinkaya 73c00d40bd
[clang][Driver] Pick the last --driver-mode in case of multiple ones
This was an accidental behaviour change in D106789 and this patch
restores it back to original state.

Differential Revision: https://reviews.llvm.org/D109361
2021-09-07 15:33:45 +02:00
Balazs Benics d6ca91ea42 [clang][AST] Add support for SubstTemplateTypeParmPackType to ASTImporter
Thank you @martong for acquiring a suitable test case!

Reviewed By: shafik, martong

Differential Revision: https://reviews.llvm.org/D109237
2021-09-04 10:19:57 +02:00
Louis Dionne 79f8b5f0d0 Revert "[Coroutines] [Clang] Look up coroutine component in std namespace first"
This reverts commit 2fbd254aa4, which broke the libc++ CI. I'm reverting
to get things stable again until we've figured out a way forward.

Differential Revision: https://reviews.llvm.org/D108696
2021-09-03 16:01:09 -04:00
Alexandre Rames 655bea4226 [modules] Use `HashBuilder` and `MD5` for the module hash.
Per the comments, `hash_code` values "are not stable to save or
persist", so are unsuitable for the module hash, which must persist
across compilations for the implicit module hashes to match. Note that
in practice, today, `hash_code` are stable. But this is an
implementation detail, with a clear `FIXME` indicating we should switch
to a per-execution seed.

The stability of `MD5` also allows modules cross-compilation use-cases.
The `size_t` underlying storage for `hash_code` varying across platforms
could cause mismatching hashes when cross-compiling from a 64bit
target to a 32bit target.

Note that native endianness is still used for the hash computation. So hashes
will differ between platforms of different endianness.

Reviewed By: jansvoboda11

Differential Revision: https://reviews.llvm.org/D102943
2021-09-03 11:13:36 -07:00
Jessica Paquette b9e57e0305 Revert "[analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it"
This reverts commit a375bfb5b7.

This was causing a bot to crash:

https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/23380/
2021-09-03 10:28:07 -07:00
Vassil Vassilev 8859640461 Revert "Reland "[clang-repl] Re-implement clang-interpreter as a test case.""
This reverts commit 6fe2beba7d which fails on
clang-hexagon-elf
2021-09-03 13:18:09 +00:00
Vassil Vassilev 6fe2beba7d Reland "[clang-repl] Re-implement clang-interpreter as a test case."
Original commit message: "
    Original commit message:"
      The current infrastructure in lib/Interpreter has a tool, clang-repl, very
      similar to clang-interpreter which also allows incremental compilation.

      This patch moves clang-interpreter as a test case and drops it as conditionally
      built example as we already have clang-repl in place.

      Differential revision: https://reviews.llvm.org/D107049
    "

    This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
    which may be a feature request for the jit infrastructure. Also, adds a missing
    build system dependency to the orc jit.
"

Additionally, this patch defines a custom exception type and thus avoids the
requirement to include header <exception>, making it easier to deploy across
systems without standard location of the c++ headers.

Differential revision: https://reviews.llvm.org/D107049
2021-09-03 12:02:58 +00:00
Kristóf Umann a375bfb5b7 [analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it
D105553 added NoStateChangeFuncVisitor, an abstract class to aid in creating
notes such as "Returning without writing to 'x'", or "Returning without changing
the ownership status of allocated memory". Its clients need to define, among
other things, what a change of state is.

For code like this:

f() {
  g();
}

foo() {
  f();
  h();
}

We'd have a path in the ExplodedGraph that looks like this:

             -- <g> -->
            /          \
         ---     <f>    -------->        --- <h> --->
        /                        \      /            \
--------        <foo>             ------    <foo>     -->

When we're interested in whether f neglected to change some property,
NoStateChangeFuncVisitor asks these questions:

                       ÷×~
                -- <g> -->
           ß   /          \$    @&#*
            ---     <f>    -------->        --- <h> --->
           /                        \      /            \
   --------        <foo>             ------    <foo>     -->

Has anything changed in between # and *?
Has anything changed in between & and *?
Has anything changed in between @ and *?
...
Has anything changed in between $ and *?
Has anything changed in between × and ~?
Has anything changed in between ÷ and ~?
...
Has anything changed in between ß and *?
...
This is a rather thorough line of questioning, which is why in D105819, I was
only interested in whether state *right before* and *right after* a function
call changed, and early returned to the CallEnter location:

if (!CurrN->getLocationAs<CallEnter>())
  return;
Except that I made a typo, and forgot to negate the condition. So, in this
patch, I'm fixing that, and under the same hood allow all clients to decide to
do this whole-function check instead of the thorough one.

Differential Revision: https://reviews.llvm.org/D108695
2021-09-03 13:50:18 +02:00
Chuanqi Xu 2fbd254aa4 [Coroutines] [Clang] Look up coroutine component in std namespace first
Summary: Now in libcxx and clang, all the coroutine components are
defined in std::experimental namespace.
And now the coroutine TS is merged into C++20. So in the working draft
like N4892, we could find the coroutine components is defined in std
namespace instead of std::experimental namespace.
And the coroutine support in clang seems to be relatively stable. So I
think it may be suitable to move the coroutine component into the
experiment namespace now.

But move the coroutine component into the std namespace may be an break
change. So I planned to split this change into two patch. One in clang
and other in libcxx.

This patch would make clang lookup coroutine_traits in std namespace
first. For the compatibility consideration, clang would lookup in
std::experimental namespace if it can't find definitions in std
namespace and emit a warning in this case. So the existing codes
wouldn't be break after update compiler.

Test Plan: check-clang, check-libcxx

Reviewed By: lxfind

Differential Revision: https://reviews.llvm.org/D108696
2021-09-03 10:22:55 +08:00
Kristóf Umann 3891b45a06 Revert "[analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it"
This reverts commit 7d0e62bfb7.
2021-09-02 17:19:49 +02:00
Kristóf Umann 7d0e62bfb7 [analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it
D105553 added NoStateChangeFuncVisitor, an abstract class to aid in creating
notes such as "Returning without writing to 'x'", or "Returning without changing
the ownership status of allocated memory". Its clients need to define, among
other things, what a change of state is.

For code like this:

f() {
  g();
}

foo() {
  f();
  h();
}

We'd have a path in the ExplodedGraph that looks like this:

             -- <g> -->
            /          \
         ---     <f>    -------->        --- <h> --->
        /                        \      /            \
--------        <foo>             ------    <foo>     -->

When we're interested in whether f neglected to change some property,
NoStateChangeFuncVisitor asks these questions:

                       ÷×~
                -- <g> -->
           ß   /          \$    @&#*
            ---     <f>    -------->        --- <h> --->
           /                        \      /            \
   --------        <foo>             ------    <foo>     -->

Has anything changed in between # and *?
Has anything changed in between & and *?
Has anything changed in between @ and *?
...
Has anything changed in between $ and *?
Has anything changed in between × and ~?
Has anything changed in between ÷ and ~?
...
Has anything changed in between ß and *?
...
This is a rather thorough line of questioning, which is why in D105819, I was
only interested in whether state *right before* and *right after* a function
call changed, and early returned to the CallEnter location:

if (!CurrN->getLocationAs<CallEnter>())
  return;
Except that I made a typo, and forgot to negate the condition. So, in this
patch, I'm fixing that, and under the same hood allow all clients to decide to
do this whole-function check instead of the thorough one.

Differential Revision: https://reviews.llvm.org/D108695
2021-09-02 16:56:32 +02:00
Duncan P. N. Exon Smith 8976a1e111 VFS: Document goals of 'use-external-name' and related logic, NFC
Document 'use-external-name' and the various bits of logic that make it
work, to avoid others having to repeat the archival work (given that I
added getFileRefReturnsCorrectNameForDifferentStatPath to
FileManagerTest, seems possible I understood this once before!).

- b59cf679e8 added 'use-external-name' to
  RedirectingFileSystem. This causes `stat`s to return the external
  name for a redirected file instead of the name it was accessed by,
  leaking it through the VFS.
- d066d4c849 propagated the external name
  further through clang::FileManager.
- 4dc5573acc, which added
  clang::FileEntryRef to clang::FileManager, has complicated concession
  to account for this as well (since refactored a bit).

The goal of 'use-external-name' is to enable Clang to report "real" file
paths to users (via diagnostics) and to external tools (such as
debuggers reading debug info and build systems reading `.d` files).

I've added FIXMEs to look at other channels for communicating the
external names, since the current implementation adds complexity to
FileManager and exposes an inconsistent interface to clients.

Besides that, the FileManager logic appears to be kicking in outside of
'use-external-name'. Seems that *some* vfs::FileSystem implementations
canonicalize some paths returned by `stat` in *some* cases (the bug
isn't fully understood yet). Volodymyr Sapsai is investigating, this at
least better documents what *is* understood.
2021-09-01 15:55:33 -04:00
Nico Weber 9b6c8132d3 Revert "Reland "[clang-repl] Re-implement clang-interpreter as a test case.""
This reverts commit f0514a4d26.
Test fails on macOS: https://reviews.llvm.org/D107049#2976603
2021-09-01 08:35:33 -04:00
Vassil Vassilev f0514a4d26 Reland "[clang-repl] Re-implement clang-interpreter as a test case."
Original commit message:"
  The current infrastructure in lib/Interpreter has a tool, clang-repl, very
  similar to clang-interpreter which also allows incremental compilation.

  This patch moves clang-interpreter as a test case and drops it as conditionally
  built example as we already have clang-repl in place.

  Differential revision: https://reviews.llvm.org/D107049
"

This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
which may be a feature request for the jit infrastructure. Also, adds a missing
build system dependency to the orc jit.
2021-09-01 10:21:38 +00:00
Vassil Vassilev 04bbd189a9 Revert "[clang-repl] Re-implement clang-interpreter as a test case."
This reverts commit 319ce98011 because it fails
on various platforms.
2021-09-01 06:49:52 +00:00
Vassil Vassilev 319ce98011 [clang-repl] Re-implement clang-interpreter as a test case.
The current infrastructure in lib/Interpreter has a tool, clang-repl, very
similar to clang-interpreter which also allows incremental compilation.

This patch moves clang-interpreter as a test case and drops it as conditionally
built example as we already have clang-repl in place.

Differential revision: https://reviews.llvm.org/D107049
2021-09-01 05:23:21 +00:00
owenca 4b1fde8a2b [clang-format] Add PackConstructorInitializers backward compat test
Add backward compatibility tests for mapping the deprecated
ConstructorInitializerAllOnOneLineOrOnePerLine and
AllowAllConstructorInitializersOnNextLine to
PackConstructorInitializers.

Differential Revision: https://reviews.llvm.org/D108882
2021-08-29 13:47:11 -07:00
owenca 696e7905a1 [clang-format] [NFC] Fix the coding style of unit tests header file 2021-08-27 14:25:38 -07:00
mydeveloperday ed367b9dff [clang-format] [PR51640] - New AfterEnum brace wrapping changes have cause C# behaviour to change
LLVM 13.0.0-rc2 shows change of behaviour in enum and interface BraceWrapping (likely before we simply didn't wrap)  but may be related to {D99840}

Logged as https://bugs.llvm.org/show_bug.cgi?id=51640

This change ensure AfterEnum works for

`internal|public|protected|private enum A {`  in the same way as it works for `enum A {` in C++

A similar issue was also observed with `interface` in C#

Reviewed By: krasimir, owenpan

Differential Revision: https://reviews.llvm.org/D108810
2021-08-27 19:13:53 +01:00
owenca 8a780a2f18 [clang-format] Group options that pack constructor initializers
Add a new option PackConstructorInitializers and deprecate the
related options ConstructorInitializerAllOnOneLineOrOnePerLine and
AllowAllConstructorInitializersOnNextLine. Below is the mapping:

PackConstructorInitializers  ConstructorInitializer... AllowAll...
        Never                            -                  -
        BinPack                        false                -
        CurrentLine                    true               false
        NextLine                       true               true

The option value Never fixes PR50549 by always placing each
constructor initializer on its own line.

Differential Revision: https://reviews.llvm.org/D108752
2021-08-27 06:27:46 -07:00
Jan Kuehle e708808f87 [clang-format] Support TypeScript override keyword
TypeScript 4.3 added a new "override" keyword for class members. This
lets clang-format know about it, so it can format code using it
properly.

Reviewed By: krasimir

Differential Revision: https://reviews.llvm.org/D108692
2021-08-25 14:11:50 +02:00
Krasimir Georgiev befb9dc369 [clang-format] keep TypeScript argument decorators in line
As a follow-up from https://reviews.llvm.org/D108538, ensure TypeScript
argument decorators are kept in line with the argument.

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D108620
2021-08-24 12:37:08 +02:00
Krasimir Georgiev f3671a688d [clang-format] break after the closing paren of a TypeScript decoration
This fixes up a regression we found from
https://reviews.llvm.org/D107267: in specific contexts, clang-format
stopped breaking after the `)` in TypeScript decorations. There were no test cases covering this, so I added one.

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D108538
2021-08-23 15:52:14 +02:00
Owen f6928cf455 [clang-format] Distinguish K&R C function definition and attribute
This is a follow-up to https://reviews.llvm.org/D107950 which
missed user-defined types in K&R C.

Differential Revision: https://reviews.llvm.org/D107961
2021-08-14 05:00:40 -07:00
David Spickett 98eb348eb3 Revert "[clang-format] Distinguish K&R C function definition and attribute"
This reverts commit de763c4037.

Causing test failures on the Arm/AArch64 quick bots:
https://lab.llvm.org/buildbot/#/builders/188/builds/2202
2021-08-13 16:25:32 +01:00
Owen de763c4037 [clang-format] Distinguish K&R C function definition and attribute
This is a follow-up to https://reviews.llvm.org/D107950 which
missed user-defined types in K&R C.

Differential Revision: https://reviews.llvm.org/D107961
2021-08-13 05:28:19 -07:00
Sam McCall 2ff7ca98a9 [clangd] Avoid "expected one compiler job" by picking the first eligible job.
This happens in createInvocationWithCommandLine but only clangd currently passes
ShouldRecoverOnErorrs (sic).

One cause of this (with correct command) is several -arch arguments for mac
multi-arch support.

Fixes https://github.com/clangd/clangd/issues/827

Differential Revision: https://reviews.llvm.org/D107632
2021-08-13 00:36:30 +02:00
Sam McCall 18f9e25ce1 [AST][clangd] Expose documentation of Attrs on hover.
This adds a method to Attr to get at the documentation programmatically.

Differential Revision: https://reviews.llvm.org/D107703
2021-08-12 21:16:37 +02:00
Krasimir Georgiev 45934922fa [clang-format] improve distinction of K&R function definitions vs attributes
After
9da70ab3d4
we saw a few regressions around trailing attribute definitions and in
typedefs (examples in the added test cases). There's some tension
distinguishing K&R definitions from attributes at the parser level,
where we have to decide if we need to put the type of the K&R definition
on a new unwrapped line before we have access to the rest of the line,
so we're scanning backwards and looking for a pattern like f(a, b). But
this type of pattern could also be an attribute macro, or the whole
declaration could be a typedef itself. I updated the code to check for a
typedef at the beginning of the line and to not consider raw identifiers
as possible first K&R declaration (but treated as an attribute macro
instead). This is not 100% correct heuristic, but I think it should be
reasonably good in practice, where we'll:
  * likely be in some very C-ish code when using K&R style (e.g., stuff
    that uses `struct name a;` instead of `name a;`
  * likely be in some very C++-ish code when using attributes
  * unlikely mix up the two in the same declaration.

Ideally, we should only decide to add the unwrapped line before the K&R
declaration after we've scanned the rest of the line an noticed the
variable declarations and the semicolon, but the way the parser is
organized I don't see a good way to do this in the current parser, which
only has good context for the previously visited tokens. I also tried
not emitting an unwrapped line there and trying to resolve the situation
later in the token annotator and the continuation indenter, and that
approach seems promising, but I couldn't make it to work without
messing up a bunch of other cases in unit tests.

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D107950
2021-08-12 10:29:06 +02:00
Krasimir Georgiev 0fc27ef196 [clang-format] handle trailing comments in function definition detection
A follow-up to
f6bc614546
where we handle the case where the semicolon is followed by a trailing
comment.

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D107907
2021-08-12 08:55:54 +02:00
Christopher Di Bella c874dd5362 [llvm][clang][NFC] updates inline licence info
Some files still contained the old University of Illinois Open Source
Licence header. This patch replaces that with the Apache 2 with LLVM
Exception licence.

Differential Revision: https://reviews.llvm.org/D107528
2021-08-11 02:48:53 +00:00
Sam McCall c8f148274f Reapply "Support Attr in DynTypedNode and ASTMatchers."
This reverts commit 3241680f11.
Fixed mangled post-test formatting :-(
2021-08-06 22:30:32 +02:00
Sam McCall 3241680f11 Revert "Support Attr in DynTypedNode and ASTMatchers."
This reverts commit a4bdcdadc6.

Fails bots:
https://lab.llvm.org/buildbot/#/builders/109/builds/20231/steps/6/logs/stdio
2021-08-06 22:27:54 +02:00
Sam McCall a4bdcdadc6 Support Attr in DynTypedNode and ASTMatchers.
Differential Revision: https://reviews.llvm.org/D89743
2021-08-06 22:06:04 +02:00
Corentin Jabot 3c8e94bc20 Disallow narrowing conversions to bool in noexcept specififers
Completes the support for P1401R5.
2021-08-06 10:26:39 -04:00
Krasimir Georgiev f6bc614546 [clan-format] detect function definitions more conservatively
https://reviews.llvm.org/D105964 updated the detection of function
definitions. It had the unfortunate effect to start marking object
definitions with attribute-like macros as function definitions.

This addresses this issue.

Reviewed By: owenpan

Differential Revision: https://reviews.llvm.org/D107269
2021-08-03 16:19:35 +02:00
Krasimir Georgiev 4f4f278305 [clang-format] don't break between function and function name in JS
The patch https://reviews.llvm.org/D105964 (58494c856a)
updated detection of function declaration names. It had the unfortunate
consequence that it started breaking between `function` and the function
name in some cases in JavaScript code.

This patch addresses this.

Reviewed By: MyDeveloperDay, owenpan

Differential Revision: https://reviews.llvm.org/D107267
2021-08-03 11:18:21 +02:00
Melanie Blower bc5b5ea037 [clang][patch][FPEnv] Make initialization of C++ globals strictfp aware
@kpn pointed out that the global variable initialization functions didn't
have the "strictfp" metadata set correctly, and @rjmccall said that there
was buggy code in SetFPModel and StartFunction, this patch is to solve
those problems. When Sema creates a FunctionDecl, it sets the
FunctionDeclBits.UsesFPIntrin to "true" if the lexical FP settings
(i.e. a combination of command line options and #pragma float_control
settings) correspond to ConstrainedFP mode. That bit is used when CodeGen
starts codegen for a llvm function, and it translates into the
"strictfp" function attribute. See bugs.llvm.org/show_bug.cgi?id=44571

Reviewed By: Aaron Ballman

Differential Revision: https://reviews.llvm.org/D102343
2021-07-29 12:02:37 -04:00
Björn Schäpers 75f6a795ee [clang-format] Fix aligning with linebreaks #2
This amends c5243c63cd to fix formatting
continued function calls with BinPacking = false.

Differential Revision: https://reviews.llvm.org/D106773
2021-07-29 08:43:41 +02:00
Luna Kirkby 71616722d4 [clang-format] Correctly attach enum braces with ShortEnums disabled
Previously, with AllowShortEnumsOnASingleLine disabled, enums that would have otherwise fit on a single line would always put the opening brace on its own line.
This patch ensures that these enums will only put the brace on its own line if the existing attachment rules indicate that it should.

Reviewed By: HazardyKnusperkeks, curdeius

Differential Revision: https://reviews.llvm.org/D99840
2021-07-28 10:29:15 +02:00
Jan Svoboda 0f98e6e875 [clang][tooling] Link LLVMOption to ToolingTests
This fixes a build failure introduced in 11ee699b3c.
2021-07-27 11:48:44 +02:00
Jan Svoboda 5bcbb5ec5f [clang][tooling] Link clangDriver to ToolingTests
This fixes a build failure introduced in 11ee699b3c.
2021-07-27 11:09:45 +02:00
Jan Svoboda 11ee699b3c [clang][tooling] Accept Clang invocations with multiple jobs
When `-fno-integrated-as` is passed to the Clang driver (or set by default by a specific toolchain), it will construct an assembler job in addition to the cc1 job. Similarly, the `-fembed-bitcode` driver  flag will create additional cc1 job that reads LLVM IR file.

The Clang tooling library only cares about the job that reads a source file. Instead of relying on the fact that the client injected `-fsyntax-only` to the driver invocation to get a single `-cc1` invocation that reads the source file, this patch filters out such jobs from `Compilation` automatically and ignores the rest.

This fixes a test failure in `ClangScanDeps/headerwithname.cpp` and `ClangScanDeps/headerwithnamefollowedbyinclude.cpp` on AIX reported here: https://reviews.llvm.org/D103461#2841918 and `clang-scan-deps` failures with `-fembed-bitcode`.

Depends on D106788.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D105695
2021-07-27 10:47:55 +02:00
Jan Svoboda b76c7c6faf [clang][driver] NFC: Expose InputInfo in Job instead of plain filenames
This patch exposes `InputInfo` in `Job` instead of plain filenames. This is useful in a follow-up patch that uses this to recognize `-cc1` commands interesting for Clang tooling.

Depends on D106787.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D106788
2021-07-27 09:18:58 +02:00
Balázs Kéri 41adc09b22 [clang][AST] Add support for DecompositionDecl to ASTImporter.
BindingDecl was added recently but the related DecompositionDecl is needed
to make C++17 structured bindings importable.
Import of BindingDecl was changed to avoid infinite import loop.

Reviewed By: martong

Differential Revision: https://reviews.llvm.org/D105354
2021-07-22 13:09:42 +02:00