Commit Graph

4501 Commits

Author SHA1 Message Date
Yaxun Liu 1282889347 [HIP] Support new kernel launching API
Differential Revision: https://reviews.llvm.org/D67947

llvm-svn: 372773
2019-09-24 19:16:40 +00:00
Jan Korous b26e9e2a8f Revert "[static analyzer] Define __clang_analyzer__ macro in driver"
This reverts commit fbd13570b0.

llvm-svn: 372687
2019-09-24 03:21:22 +00:00
Jan Korous fbd13570b0 [static analyzer] Define __clang_analyzer__ macro in driver
Differential Revision: https://reviews.llvm.org/D67938

llvm-svn: 372679
2019-09-24 00:33:47 +00:00
Lubos Lunak 533434fc72 make -frewrite-includes also rewrite conditions in #if/#elif
Those conditions may use __has_include, which needs to be rewritten.
The existing code has already tried to rewrite just __has_include,
but it didn't work with macro expansion, so e.g. Qt's
"#define QT_HAS_INCLUDE(x) __has_include(x)" didn't get handled
properly. Since the preprocessor run knows what each condition evaluates
to, just rewrite the entire condition. This of course requires that
the -frewrite-include pass has the same setup as the following
compilation, but that has always been the requirement.

Differential Revision: https://reviews.llvm.org/D63508

llvm-svn: 372248
2019-09-18 19:09:41 +00:00
Raphael Isemann 1442efea9a [lldb] Print better diagnostics for user expressions and modules
Summary:
Currently our expression evaluators only prints very basic errors that are not very useful when writing complex expressions.

For example, in the expression below the user made a type error, but it's not clear from the diagnostic what went wrong:
```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: invalid operands to binary expression ('int' and 'double')
```

This patch enables full Clang diagnostics in our expression evaluator. After this patch the diagnostics for the expression look like this:

```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: <user expression 1>:1:54: invalid operands to binary expression ('int' and 'float')
printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
                                               ~~~~~~^~~~
```

To make this possible, we now emulate a user expression file within our diagnostics. This prevents that the user is exposed to
our internal wrapper code we inject.

Note that the diagnostics that refer to declarations from the debug information (e.g. 'note' diagnostics pointing to a called function)
will not be improved by this as they don't have any source locations associated with them, so caret or line printing isn't possible.
We instead just suppress these diagnostics as we already do with warnings as they would otherwise just be a context message
without any context (and the original diagnostic in the user expression should be enough to explain the issue).

Fixes rdar://24306342

Reviewers: JDevlieghere, aprantl, shafik, #lldb

Reviewed By: JDevlieghere, #lldb

Subscribers: usaxena95, davide, jingham, aprantl, arphaman, kadircet, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D65646

llvm-svn: 372203
2019-09-18 08:53:35 +00:00
Jan Korous f69c91780f [Support] Add overload writeFileAtomically(std::function Writer)
Differential Revision: https://reviews.llvm.org/D67424

llvm-svn: 371890
2019-09-13 20:08:27 +00:00
Manoj Gupta 41d9d5092a Reland r371785: Add -Wpoison-system-directories warning
When using clang as a cross-compiler, we should not use system
headers to do the compilation.
This CL adds support of a new warning flag -Wpoison-system-directories which
emits warnings if --sysroot is set and headers from common host system location
are used.
By default the warning is disabled.

The intention of the warning is to catch bad includes which are usually
generated by third party build system not targeting cross-compilation.
Such cases happen in Chrome OS when someone imports a new package or upgrade
one to a newer version from upstream.

This is reland of r371785 with a fix to test file.

Patch by: denik (Denis Nikitin)

llvm-svn: 371878
2019-09-13 18:00:51 +00:00
Nandor Licker 950b70dcc7 [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 371834
2019-09-13 09:46:16 +00:00
Richard Smith c624510f13 For PR17164: split -fno-lax-vector-conversion into three different
levels:

 -- none: no lax vector conversions [new GCC default]
 -- integer: only conversions between integer vectors [old GCC default]
 -- all: all conversions between same-size vectors [Clang default]

For now, Clang still defaults to "all" mode, but per my proposal on
cfe-dev (2019-04-10) the default will be changed to "integer" as soon as
that doesn't break lots of testcases. (Eventually I'd like to change the
default to "none" to match GCC and general sanity.)

Following GCC's behavior, the driver flag -flax-vector-conversions is
translated to -flax-vector-conversions=integer.

This reinstates r371805, reverted in r371813, with an additional fix for
lldb.

llvm-svn: 371817
2019-09-13 06:02:15 +00:00
Jonas Devlieghere 4aaa77e48d Revert "For PR17164: split -fno-lax-vector-conversion into three different"
This breaks the LLDB build. I tried reaching out to Richard, but haven't
gotten a reply yet.

llvm-svn: 371813
2019-09-13 05:16:59 +00:00
Richard Smith 49c4e58b75 For PR17164: split -fno-lax-vector-conversion into three different
levels:

 -- none: no lax vector conversions [new GCC default]
 -- integer: only conversions between integer vectors [old GCC default]
 -- all: all conversions between same-size vectors [Clang default]

For now, Clang still defaults to "all" mode, but per my proposal on
cfe-dev (2019-04-10) the default will be changed to "integer" as soon as
that doesn't break lots of testcases. (Eventually I'd like to change the
default to "none" to match GCC and general sanity.)

Following GCC's behavior, the driver flag -flax-vector-conversions is
translated to -flax-vector-conversions=integer.

llvm-svn: 371805
2019-09-13 02:20:00 +00:00
Manoj Gupta 38f6b3fd8d Revert r371785.
r371785 is causing fails on clang-hexagon-elf buildbots.

llvm-svn: 371799
2019-09-13 00:28:37 +00:00
Manoj Gupta 4fe2732161 Add -Wpoison-system-directories warning
When using clang as a cross-compiler, we should not use system
headers to do the compilation.
This CL adds support of a new warning flag -Wpoison-system-directories which
emits warnings if --sysroot is set and headers from common host system location
are used.
By default the warning is disabled.

The intention of the warning is to catch bad includes which are usually
generated by third party build system not targeting cross-compilation.
Such cases happen in Chrome OS when someone imports a new package or upgrade
one to a newer version from upstream.

Patch by: denik (Denis Nikitin)

llvm-svn: 371785
2019-09-12 22:36:13 +00:00
Kristof Umann 72649423c0 [analyzer][NFC] Fix inconsistent references to checkers as "checks"
Traditionally, clang-tidy uses the term check, and the analyzer uses checker,
but in the very early years, this wasn't the case, and code originating from the
early 2010's still incorrectly refer to checkers as checks.

This patch attempts to hunt down most of these, aiming to refer to checkers as
checkers, but preserve references to callback functions (like checkPreCall) as
checks.

Differential Revision: https://reviews.llvm.org/D67140

llvm-svn: 371760
2019-09-12 19:09:24 +00:00
Dmitri Gribenko 20f45ed699 Removed some questionable default arguments from setters
Summary:
They can be confusing -- what does it mean to call a setter without a
value? Also, some setters, like `setPrintTemplateTree` had `false` as
the default value!

The callers are largely not using these default arguments anyway.

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D67491

llvm-svn: 371731
2019-09-12 12:16:43 +00:00
Heejin Ahn e8b2b8868d [WebAssembly] Add -fwasm-exceptions for wasm EH
Summary:
This adds `-fwasm-exceptions` (in similar fashion with
`-fdwarf-exceptions` or `-fsjlj-exceptions`) that turns on everything
with wasm exception handling from the frontend to the backend.

We currently have `-mexception-handling` in clang frontend, but this is
only about the architecture capability and does not turn on other
necessary options such as the exception model in the backend. (This can
be turned on with `llc -exception-model=wasm`, but llc is not invoked
separately as a command line tool, so this option has to be transferred
from clang.)

Turning on `-fwasm-exceptions` in clang also turns on
`-mexception-handling` if not specified, and will error out if
`-mno-exception-handling` is specified.

Reviewers: dschuff, tlively, sbc100

Subscribers: aprantl, jgravelle-google, sunfish, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D67208

llvm-svn: 371708
2019-09-12 04:01:37 +00:00
Petr Hosek 7bdad08429 Reland "clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM"
This patch contains the basic functionality for reporting potentially
incorrect usage of __builtin_expect() by comparing the developer's
annotation against a collected PGO profile. A more detailed proposal and
discussion appears on the CFE-dev mailing list
(http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a
prototype of the initial frontend changes appear here in D65300

We revised the work in D65300 by moving the misexpect check into the
LLVM backend, and adding support for IR and sampling based profiles, in
addition to frontend instrumentation.

We add new misexpect metadata tags to those instructions directly
influenced by the llvm.expect intrinsic (branch, switch, and select)
when lowering the intrinsics. The misexpect metadata contains
information about the expected target of the intrinsic so that we can
check against the correct PGO counter when emitting diagnostics, and the
compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight.
We use these branch weight values to determine when to emit the
diagnostic to the user.

A future patch should address the comment at the top of
LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and
UnlikelyBranchWeight values into a shared space that can be accessed
outside of the LowerExpectIntrinsic pass. Once that is done, the
misexpect metadata can be updated to be smaller.

In the long term, it is possible to reconstruct portions of the
misexpect metadata from the existing profile data. However, we have
avoided this to keep the code simple, and because some kind of metadata
tag will be required to identify which branch/switch/select instructions
are influenced by the use of llvm.expect

Patch By: paulkirth
Differential Revision: https://reviews.llvm.org/D66324

llvm-svn: 371635
2019-09-11 16:19:50 +00:00
Dmitri Gribenko 57256af307 Revert "clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM"
This reverts commit r371584. It introduced a dependency from compiler-rt
to llvm/include/ADT, which is problematic for multiple reasons.

One is that it is a novel dependency edge, which needs cross-compliation
machinery for llvm/include/ADT (yes, it is true that right now
compiler-rt included only header-only libraries, however, if we allow
compiler-rt to depend on anything from ADT, other libraries will
eventually get used).

Secondly, depending on ADT from compiler-rt exposes ADT symbols from
compiler-rt, which would cause ODR violations when Clang is built with
the profile library.

llvm-svn: 371598
2019-09-11 09:16:17 +00:00
Petr Hosek 394a8ed8f1 clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM
This patch contains the basic functionality for reporting potentially
incorrect usage of __builtin_expect() by comparing the developer's
annotation against a collected PGO profile. A more detailed proposal and
discussion appears on the CFE-dev mailing list
(http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a
prototype of the initial frontend changes appear here in D65300

We revised the work in D65300 by moving the misexpect check into the
LLVM backend, and adding support for IR and sampling based profiles, in
addition to frontend instrumentation.

We add new misexpect metadata tags to those instructions directly
influenced by the llvm.expect intrinsic (branch, switch, and select)
when lowering the intrinsics. The misexpect metadata contains
information about the expected target of the intrinsic so that we can
check against the correct PGO counter when emitting diagnostics, and the
compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight.
We use these branch weight values to determine when to emit the
diagnostic to the user.

A future patch should address the comment at the top of
LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and
UnlikelyBranchWeight values into a shared space that can be accessed
outside of the LowerExpectIntrinsic pass. Once that is done, the
misexpect metadata can be updated to be smaller.

In the long term, it is possible to reconstruct portions of the
misexpect metadata from the existing profile data. However, we have
avoided this to keep the code simple, and because some kind of metadata
tag will be required to identify which branch/switch/select instructions
are influenced by the use of llvm.expect

Patch By: paulkirth
Differential Revision: https://reviews.llvm.org/D66324

llvm-svn: 371584
2019-09-11 01:09:16 +00:00
Petr Hosek 7d1757aba8 Revert "clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM"
This reverts commit r371484: this broke sanitizer-x86_64-linux-fast bot.

llvm-svn: 371488
2019-09-10 06:25:13 +00:00
Petr Hosek a10802fd73 clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM
This patch contains the basic functionality for reporting potentially
incorrect usage of __builtin_expect() by comparing the developer's
annotation against a collected PGO profile. A more detailed proposal and
discussion appears on the CFE-dev mailing list
(http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a
prototype of the initial frontend changes appear here in D65300

We revised the work in D65300 by moving the misexpect check into the
LLVM backend, and adding support for IR and sampling based profiles, in
addition to frontend instrumentation.

We add new misexpect metadata tags to those instructions directly
influenced by the llvm.expect intrinsic (branch, switch, and select)
when lowering the intrinsics. The misexpect metadata contains
information about the expected target of the intrinsic so that we can
check against the correct PGO counter when emitting diagnostics, and the
compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight.
We use these branch weight values to determine when to emit the
diagnostic to the user.

A future patch should address the comment at the top of
LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and
UnlikelyBranchWeight values into a shared space that can be accessed
outside of the LowerExpectIntrinsic pass. Once that is done, the
misexpect metadata can be updated to be smaller.

In the long term, it is possible to reconstruct portions of the
misexpect metadata from the existing profile data. However, we have
avoided this to keep the code simple, and because some kind of metadata
tag will be required to identify which branch/switch/select instructions
are influenced by the use of llvm.expect

Patch By: paulkirth
Differential Revision: https://reviews.llvm.org/D66324

llvm-svn: 371484
2019-09-10 03:11:39 +00:00
Jan Korous 0aee387321 [clang][DependencyFileGenerator] Fix missing -MT option handling
Targets in DependencyFileGenerator don't necessarily come from -MT option.

Differential Revision: https://reviews.llvm.org/D67308

llvm-svn: 371279
2019-09-07 00:59:13 +00:00
Craig Topper 6c8a34ed9b [X86] Prevent passing vectors of __int128 as <X x i128> in llvm IR
As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type.

I'm restricting this to change to Linux and NetBSD based on the
how similar ABI changes have been handled in the past.
PS4, FreeBSD, and Darwin are unaffected. I've also added a
new -fclang-abi-compat version to restore the old behavior.

This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment.

llvm-svn: 371169
2019-09-06 06:02:13 +00:00
Richard Smith a6e8b685e1 [c++20] P1143R2: Add support for the C++20 'constinit' keyword.
This is mostly the same as the
[[clang::require_constant_initialization]] attribute, but has a couple
of additional syntactic and semantic restrictions.

In passing, I added a warning for the attribute form being added after
we have already seen the initialization of the variable (but before we
see the definition); that case previously slipped between the cracks and
the attribute was silently ignored.

llvm-svn: 370972
2019-09-04 20:30:37 +00:00
Ilya Biryukov 433927595d [Driver] Use shared singleton instance of DriverOptTable
Summary:
This significantly reduces the time required to run clangd tests, by
~10%.

Should also have an effect on other tests that run command-line parsing
multiple times inside a single invocation.

Reviewers: gribozavr, sammccall

Reviewed By: sammccall

Subscribers: kadircet, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D67163

llvm-svn: 370908
2019-09-04 14:26:28 +00:00
Roman Lebedev 2c9f83cfab Revert "[Clang Interpreter] Initial patch for the constexpr interpreter"
Breaks BUILD_SHARED_LIBS build, introduces cycles in library dependency
graphs. (clangInterp depends on clangAST which depends on clangInterp)

This reverts r370839, which is an yet another recommit of D64146.

llvm-svn: 370874
2019-09-04 10:57:06 +00:00
Nandor Licker 32f82c9cba [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370839
2019-09-04 05:49:41 +00:00
Nandor Licker c3bdad8c1e Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370636 (git commit 8327fed947)

llvm-svn: 370642
2019-09-02 11:34:47 +00:00
Nandor Licker 8327fed947 [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370636
2019-09-02 10:38:08 +00:00
Nandor Licker a6bef738bf Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370584 (git commit afcb3de117)

llvm-svn: 370588
2019-08-31 15:15:39 +00:00
Nandor Licker afcb3de117 [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370584
2019-08-31 15:00:38 +00:00
Alex Lorenz 0377ca641c Introduce a DirectoryEntryRef that stores both a reference and an
accessed name to the directory entry

This commit introduces a parallel API that returns a DirectoryEntryRef
to the FileManager, similar to the parallel FileEntryRef API. All
uses will have to be update in follow-up patches. The immediate use of the new API in this
patch fixes the issue where a file manager was reused in clang-scan-deps,
but reported an different file path whenever a framework lookup was done through a symlink.

Differential Revision: https://reviews.llvm.org/D67026

llvm-svn: 370562
2019-08-31 01:26:04 +00:00
Nandor Licker 0300c3536a Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370531 (git commit d4c1002e0b)

llvm-svn: 370535
2019-08-30 21:32:00 +00:00
Nandor Licker d4c1002e0b [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370531
2019-08-30 21:17:03 +00:00
Nandor Licker 5c8b94a672 Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370476 (git commit a559095054)

llvm-svn: 370481
2019-08-30 15:41:45 +00:00
Nandor Licker a559095054 [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370476
2019-08-30 15:02:09 +00:00
Evgeny Mankov 2ed2e62498 [preprocessor] Add an opportunity to retain excluded conditional blocks
It is handy for clang tooling, for instance, in source to source transformation.

Reviewers: vpykhtin (Valery Pykhtin), erichkeane (Erich Keane)

Subscribers: rsmith (Richard Smith), akyrtzi (Argyrios Kyrtzidis)

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66597

llvm-svn: 370123
2019-08-27 22:15:32 +00:00
Dmitri Gribenko 1fac68b0dc ArrayRef'ized CompilerInvocation::CreateFromArgs
Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66797

llvm-svn: 370122
2019-08-27 22:13:31 +00:00
Alex Lorenz 1c8a4b7204 Use FileEntryRef for PPCallbacks::HasInclude
This fixes the issue where a filename dependendency was missing if the file that
was referenced with __has_include() was accessed through a symlink in an earlier run,
if the file manager was reused between runs.

llvm-svn: 370081
2019-08-27 17:32:42 +00:00
Ilya Biryukov 999e4c4793 [Driver] Add an option for createInvocationFromCommandLine to recover on errors
Summary:
Previously, it would always return nullptr on any error.
This change adds a parameter, controlling whether the function should
attempt to return a non-null result even if unknown arguments (or other
errors were encountered).

The new behavior is only used in clangd.

Considered an alternative of changing the return value instead of adding
a new parameter, but that would require updating all callsites. Settled
with the parameter to minimize the code changes.

Reviewers: gribozavr

Reviewed By: gribozavr

Subscribers: nridge, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66731

llvm-svn: 370033
2019-08-27 10:02:18 +00:00
Alex Lorenz 67d25fede9 Use FileEntryRef for PPCallbacks::FileSkipped
This fixes the issue where a filename dependendency was missing if the file that
was skipped was included through a symlink in an earlier run, if the file
manager was reused between runs.

llvm-svn: 369998
2019-08-27 01:03:25 +00:00
Duncan P. N. Exon Smith 9ef6c49baf FileManager: Use llvm::Expected in new getFileRef API
`FileManager::getFileRef` is a modern API which we expect to convert to
over time.  We should modernize the error handling as well, using
`llvm::Expected` instead of `llvm::ErrorOr`, to help clients that care
about errors to ensure nothing is missed.

However, not all clients care.  I've also added another path for those
that don't:

- `FileEntryRef` is now copy- and move-assignable (using a pointer
  instead of a reference).
- `FileManager::getOptionalFileRef` returns an `llvm::Optional` instead
  of `llvm::Expected`.
- Added an `llvm::expectedToOptional` utility in case this is useful
  elsewhere.

https://reviews.llvm.org/D66705

llvm-svn: 369943
2019-08-26 18:29:51 +00:00
Richard Smith 26a92d5852 Improve behavior in the case of stack exhaustion.
Summary:
Clang performs various recursive operations (such as template instantiation),
and may use non-trivial amounts of stack space in each recursive step (for
instance, due to recursive AST walks). While we try to keep the stack space
used by such steps to a minimum and we have explicit limits on the number of
such steps we perform, it's impractical to guarantee that we won't blow out the
stack on deeply recursive template instantiations on complex ASTs, even with
only a moderately high instantiation depth limit.

The user experience in these cases is generally terrible: we crash with
no hint of what went wrong. Under this patch, we attempt to do better:

 * Detect when the stack is nearly exhausted, and produce a warning with a
   nice template instantiation backtrace, telling the user that we might
   run slowly or crash.

 * For cases where we're forced to trigger recursive template
   instantiation in arbitrarily-deeply-nested contexts, check whether
   we're nearly out of stack space and allocate a new stack (by spawning
   a new thread) after producing the warning.

Reviewers: rnk, aaron.ballman

Subscribers: mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66361

llvm-svn: 369940
2019-08-26 18:18:07 +00:00
Csaba Dabis 0d7252b783 [analyzer] Analysis: Fix checker silencing
llvm-svn: 369845
2019-08-24 12:17:49 +00:00
Benjamin Kramer dc5f805d31 Do a sweep of symbol internalization. NFC.
llvm-svn: 369803
2019-08-23 19:59:23 +00:00
Puyan Lotfi 926f4f76c3 [clang][ifs] Dropping older experimental interface stub formats.
I've been working on a new tool, llvm-ifs, for merging interface stub files
generated by clang and I've iterated on my derivative format of TBE to a newer
format. llvm-ifs will only support the new format, so I am going to drop the
older experimental interface stubs formats in this commit to make things
simpler.

Differential Revision: https://reviews.llvm.org/D66573

llvm-svn: 369719
2019-08-22 23:44:34 +00:00
Puyan Lotfi d24184591f [clang][ifs] New interface stubs format (llvm triple based).
After posting llvm-ifs on phabricator, I made some progress in hardening up how
I think the format for Interface Stubs should look. There are a number of
things I think the TBE format was missing (no endianness, no info about the
Object Format because it assumes ELF), so I have added those and broken off
from being as similar to the TBE schema. In a subsequent commit I can drop the
other formats.

An example of how The format will look is as follows:

--- !experimental-ifs-v1
IfsVersion: 1.0
Triple: x86_64-unknown-linux-gnu
ObjectFileFormat: ELF
Symbols:
  _Z9nothiddenv: { Type: Func }
  _Z10cmdVisiblev: { Type: Func }
...

The format is still marked experimental.

Differential Revision: https://reviews.llvm.org/D66446

llvm-svn: 369715
2019-08-22 23:29:22 +00:00
Alex Lorenz 4dc5573acc Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations

This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.

The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.

Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.

Differential Revision: https://reviews.llvm.org/D65907

llvm-svn: 369680
2019-08-22 18:15:50 +00:00
Erich Keane 62b072d413 Implement P1668R1
Allow inline assembly statements in unexecuted branches of constexpr
functions.

llvm-svn: 369281
2019-08-19 17:39:59 +00:00
Csaba Dabis a079a42708 [analyzer] Analysis: Silence checkers
Summary:
This patch introduces a new `analyzer-config` configuration:
`-analyzer-config silence-checkers`
which could be used to silence the given checkers.

It accepts a semicolon separated list, packed into quotation marks, e.g:
`-analyzer-config silence-checkers="core.DivideZero;core.NullDereference"`

It could be used to "disable" core checkers, so they model the analysis as
before, just if some of them are too noisy it prevents to emit reports.

This patch also adds support for that new option to the scan-build.
Passing the option `-disable-checker core.DivideZero` to the scan-build
will be transferred to `-analyzer-config silence-checkers=core.DivideZero`.

Reviewed By: NoQ, Szelethus

Differential Revision: https://reviews.llvm.org/D66042

llvm-svn: 369078
2019-08-16 01:53:14 +00:00