Refactor ContentCache::IsSystemFile to IsFileVolatile, checking
SourceManager::userFilesAreVolatile at construction time. This is a
step toward lowering ContentCache down from SourceManager to
FileManager.
No functionality change intended.
https://reviews.llvm.org/D66713
llvm-svn: 369958
clang-offload-bundler currently uses partial linking for creating fat object files, but such technique cannot be used on Windows due to the absence of partial linking support in the linker. This patch changes implementation to use llvm-objcopy for merging device and host objects instead of doing partial linking. This is one step forward towards enabling OpenMP offload on Windows.
Differential Revision: https://reviews.llvm.org/D66485
llvm-svn: 369955
Summary:
Previously critical regions were emitted with the barrier making it a
worksharing construct though it is not. Also, it leads to incorrect
behavior in Cuda9+. Patch fixes this problem.
Reviewers: ABataev, jdoerfert
Subscribers: jholewinski, guansong, cfe-commits, grokos
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66673
llvm-svn: 369946
`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
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
a fragment of a compilation database for each compilation
This patch adds a new option called -gen-cdb-fragment-path to the driver,
which can be used to specify a directory path to which clang can emit a fragment
of a CDB for each compilation it needs to invoke.
This option emits the same CDB contents as -MJ, and will be ignored if -MJ is specified.
Differential Revision: https://reviews.llvm.org/D66555
llvm-svn: 369938
Refactor machinery for skipping inline function bodies that have already
been parsed in other frontend actions.
Preparations for moving this code to libIndex.
Differential Revision: https://reviews.llvm.org/D66694
llvm-svn: 369931
-dA was in the d_group, which is a preprocessor state dumping group.
However -dA is a debug flag to cause a verbose asm. It was already
implemented to do the same thing as -fverbose-asm, so make it just be an
alias.
llvm-svn: 369926
Summary:
TypeScript 3.4 supports casting into a const type using `as const`:
const x = {x: 1} as const;
Previously, clang-format would insert a space after the `const`. With
this patch, no space is inserted after the sequence `as const`.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66736
llvm-svn: 369916
Based on @davezarzycki remarks in D64696 improved the wording of the warning
message.
Differential Revision: https://reviews.llvm.org/D66700
Patch by Mark de Wever.
llvm-svn: 369873
default template argument expression.
We already did this for type template parameters and template template
parameters, but apparently forgot to do so for non-type template
parameters. This causes the substituted default argument expression to
be substituted in the proper context, and in particular to properly mark
its subexpressions as odr-used.
llvm-svn: 369834
non-ordered loops.
According to OpenMP 5.0, 2.9.2 Worksharing-Loop Construct, Desription, If the static schedule kind is specified or if the ordered clause is specified, and if the nonmonotonic modifier is not specified, the effect is as if the monotonic modifier is specified. Otherwise, unless the monotonic modifier is specified, the effect is as if the nonmonotonic modifier is specified.
The first part of this requirement is implemented in runtime. Patch adds
support for the second, nonmonotonic, part of this requirement.
llvm-svn: 369801
construct.
OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means
that the function must be emitted only for the host, nohost - only for
the device, and any - for both, device and the host.
llvm-svn: 369775
A couple of variables are being declared outside of the 'if' condition
that is their only actual use. Additionally, switch a few 'const TYPE
*' to 'const auto *' for consistency.
llvm-svn: 369773
Summary: EnumCastOutOfRangeChecker should not perform enum range checks on LValueToRValue casts, since this type of cast does not actually change the underlying type. Performing the unnecessary check actually triggered an assertion failure deeper in EnumCastOutOfRange for certain input (which is captured in the accompanying test code).
Reviewers: #clang, Szelethus, gamesh411, NoQ
Reviewed By: Szelethus, gamesh411, NoQ
Subscribers: NoQ, gamesh411, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Charusso, bjope, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66014
llvm-svn: 369760
PR43085.
Recognize .mjs files as JavaScript. .mjs is the extension for ECMAScript modules.
A specific extension (and associated content type javascript/esm) is
introduced to differentiate it from CommonJS modules and solve some
interoperability problems.
Differential Revision: https://reviews.llvm.org/D66584
Patch by Fergal Daly
llvm-svn: 369732
Our SVal hierarchy doesn't allow modeling pointer casts as no-op. The
pointer type is instead encoded into the pointer object. Defer to our
usual pointer casting facility, SValBuilder::evalBinOp().
Fixes a crash.
llvm-svn: 369729
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
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
Summary:
It seems that CodeGen was always using ExternalLinkage when emitting a
GlobalDecl with __attribute__((alias)). This leads to symbol
redefinitions (ODR) that cause failures at link time for static aliases.
This is readily attempting to link an ARM (32b) allyesconfig Linux
kernel built with Clang.
Reported-by: nathanchance
Suggested-by: ihalip
Link: https://bugs.llvm.org/show_bug.cgi?id=42377
Link: https://github.com/ClangBuiltLinux/linux/issues/631
Reviewers: rsmith, aaron.ballman, erichkeane
Reviewed By: aaron.ballman
Subscribers: javed.absar, kristof.beyls, cfe-commits, srhines, ihalip, nathanchance
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66492
llvm-svn: 369705
I noticed another instance of the issue where references to aliases were
being replaced with aliasees, this time in InstCombine. In the instance that
I saw it turned out to be only a QoI issue (a symbol ended up being missing
from the symbol table due to the last reference to the alias being removed,
preventing HWASAN from symbolizing a global reference), but it could easily
have manifested as incorrect behaviour.
Since this is the third such issue encountered (previously: D65118, D65314)
it seems to be time to address this common error/QoI issue once and for all
and make the strip* family of functions not look through aliases.
Includes a test for the specific issue that I saw, but no doubt there are
other similar bugs fixed here.
As with D65118 this has been tested to make sure that the optimization isn't
load bearing. I built Clang, Chromium for Linux, Android and Windows as well
as the test-suite and there were no size regressions.
Differential Revision: https://reviews.llvm.org/D66606
llvm-svn: 369697
This fixes some minor grammatical issues I noticed when reading the docs, and changes the recommended feature testing approach to use __has_attribute instead of __has_extension.
llvm-svn: 369687
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
This reverts commit r369591, because it causes the formerly-reliable
-Wreturn-stack-address warning to start issuing false positives.
Testcase provided on the commit thread.
llvm-svn: 369677
This broke compiling some ASan tests with never versions of MSVC/the Win
SDK, see https://crbug.com/996675
> MSVC 2017 update 3 (_MSC_VER 1911) enables /Zc:twoPhase by default, and
> so should clang-cl:
> https://docs.microsoft.com/en-us/cpp/build/reference/zc-twophase
>
> clang-cl takes the MSVC version it emulates from the -fmsc-version flag,
> or if that's not passed it tries to check what the installed version of
> MSVC is and uses that, and failing that it uses a default version that's
> currently 1911. So this changes the default if no -fmsc-version flag is
> passed and no installed MSVC is detected. (It also changes the default
> if -fmsc-version is passed or MSVC is detected, and either indicates
> _MSC_VER >= 1911.)
>
> As mentioned in the MSDN article, the Windows SDK header files in
> version 10.0.15063.0 (Creators Update or Redstone 2) and earlier
> versions do not work correctly with /Zc:twoPhase. If you need to use
> these old SDKs with a new clang-cl, explicitly pass /Zc:twoPhase- to get
> the old behavior.
>
> Fixes PR43032.
>
> Differential Revision: https://reviews.llvm.org/D66394
llvm-svn: 369647
It causes the build to fail with
"inlinable function call in a function with debug info must have a !dbg location"
in Chromium. See llvm-commits thread for more info.
(This also reverts the follow-up in r369474.)
> Fixes PR43012
>
> Differential Revision: https://reviews.llvm.org/D66328
llvm-svn: 369633
For `map`, the following restriction changed in OpenMP 5.0:
* OpenMP 4.5 [2.15.5.1, Restrictions]: "A list item cannot appear in
both a map clause and a data-sharing attribute clause on the same
construct.
* OpenMP 5.0 [2.19.7.1, Restrictions]: "A list item cannot appear in
both a map clause and a data-sharing attribute clause on the same
construct unless the construct is a combined construct."
This patch removes this restriction in the case of combined constructs
and OpenMP 5.0, and it updates Sema not to capture a scalar by copy in
the target region when `firstprivate` and `map` appear for that scalar
on a combined target construct.
This patch also adds a fixme to a test that now reveals that a
diagnostic about loop iteration variables is dropped in the case of
OpenMP 5.0. That bug exists regardless of this patch's changes.
Reviewed By: ABataev, jdoerfert, hfinkel, kkwli0
Differential Revision: https://reviews.llvm.org/D65835
llvm-svn: 369619
This patch concludes my GSoC'19 project by enabling track-conditions by default.
Differential Revision: https://reviews.llvm.org/D66381
llvm-svn: 369616
As discussed on the mailing list, notes originating from the tracking of foreach
loop conditions are always meaningless.
Differential Revision: https://reviews.llvm.org/D66131
llvm-svn: 369613
Summary:
This patch introduces `DynamicCastInfo` similar to `DynamicTypeInfo` which
is stored in `CastSets` which are storing the dynamic cast informations of
objects based on memory regions. It could be used to store and check the
casts and prevent infeasible paths.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D66325
llvm-svn: 369605
In D65724, I do a pretty thorough explanation about how I'm solving this
problem, I think that summary nails whats happening here ;)
Differential Revision: https://reviews.llvm.org/D65725
llvm-svn: 369596
Summary:
This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator
on the template is a DependentNameType - we can only put the gsl::Pointer attribute
on the underlaying record after instantiation)
inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared,
we added the gsl::Pointer on the canonical decl (the forward decl), and later when the
template was instantiated, there was no attribute on the definition so it was not instantiated).
and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to
a incomplete instantiation, and then another was copied from the template definition
when the instantiation was completed).
We now add the attributes to all redeclarations to fix thos issues and make their usage easier.
Reviewers: gribozavr
Subscribers: Szelethus, xazax.hun, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66179
llvm-svn: 369591
Exactly what it says on the tin! Note that we're talking about interestingness
in general, hence this isn't a control-dependency-tracking specific patch.
Differential Revision: https://reviews.llvm.org/D65724
llvm-svn: 369589
I noticed that SourceManager::translateFile has code that doesn't really make sense.
In particular, if it fails to find a FileID by comparing FileEntry * values, it tries to
look through files that have the same filename, to see if they have a matching inode to try to
find the right FileID. However, the inode comparison seem redundant, as Clang's FileManager
already deduplicates FileEntry * values by inode.
Thus the comparisons between inodes should never actually succeed, and the comparison between FileEntry * values should be sufficient here.
Differential Revision: https://reviews.llvm.org/D65481
llvm-svn: 369585
We defined (on the mailing list and here on phabricator) 2 different cases where
retrieving information about a control dependency condition is very important:
* When the condition's last write happened in a different stack frame
* When the collapse point of the condition (when we can constrain it to be
true/false) didn't happen in the actual condition.
It seems like we solved this problem with the help of expression value tracking,
and have started working on better diagnostics notes about this process.
Expression value tracking is nothing more than registering a variety of visitors
to construct reports about it. Each of the registered visitors (ReturnVisitor,
FindLastStoreVisitor, NoStoreFuncVisitor, etc) have something to go by: a
MemRegion, an SVal, an ExplodedNode, etc. For this reason, better explaining a
last write is super simple, we can always just pass on some more information to
the visitor in question (as seen in D65575).
ConditionBRVisitor is a different beast, as it was built for a different
purpose. It is responsible for constructing events at, well, conditions, and is
registered only once, and isn't a part of the "expression value tracking
family". Unfortunately, it is also the visitor to tinker with for constructing
better diagnostics about the collapse point problem.
This creates a need for alternative way to communicate with ConditionBRVisitor
that a specific condition is being tracked for for the reason of being a control
dependency. Since at almost all PathDiagnosticEventPiece construction the
visitor checks interestingness, it makes sense to pair interestingness with a
reason as to why we marked an entity as such.
Differential Revision: https://reviews.llvm.org/D65723
llvm-svn: 369583
Can't add much more to the title! This is part 1, the case where the collapse
point isn't in the condition point is the responsibility of ConditionBRVisitor,
which I'm addressing in part 2.
Differential Revision: https://reviews.llvm.org/D65575
llvm-svn: 369574
Match the behavior of D65009 under the new pass manager. This addresses
the test clang/test/CodeGen/split-lto-unit.c when running under the new
PM.
Differential Revision: https://reviews.llvm.org/D66488
llvm-svn: 369550
Add defensive check that prevents a crash when we try to evaluate a destructor
whose this-value is a concrete integer that isn't a null.
Differential Revision: https://reviews.llvm.org/D65349
llvm-svn: 369450
Calling a pure virtual method during construction or destruction
is undefined behavior. It's worth it to warn about it by default.
That part is now known as the cplusplus.PureVirtualCall checker.
Calling a normal virtual method during construction or destruction
may be fine, but does behave unexpectedly, as it skips virtual dispatch.
Do not warn about this by default, but let projects opt in into it
by enabling the optin.cplusplus.VirtualCall checker manually.
Give the two parts differentiated warning text:
Before:
Call to virtual function during construction or destruction:
Call to pure virtual function during construction
Call to virtual function during construction or destruction:
Call to virtual function during destruction
After:
Pure virtual method call:
Call to pure virtual method 'X::foo' during construction
has undefined behavior
Unexpected loss of virtual dispatch:
Call to virtual method 'Y::bar' during construction
bypasses virtual dispatch
Also fix checker names in consumers that support them (eg., clang-tidy)
because we now have different checker names for pure virtual calls and
regular virtual calls.
Also fix capitalization in the bug category.
Differential Revision: https://reviews.llvm.org/D64274
llvm-svn: 369449
If the function is marked as declare target in a standalone directive,
the delayed diagnostics is not emitted. Patch fixes this problem.
llvm-svn: 369432
Summary:
As Typo Resolution can create new TypoExprs while resolving typos,
it is necessary to recurse through the expression to search for more
typos.
This should fix the assertion failure in `clang::Sema::~Sema()`:
`DelayedTypos.empty() && "Uncorrected typos!"`
Notes:
- In case some TypoExprs are created but thrown away, Sema
now has a Vector that is used to keep track of newly created
typos.
- For expressions with multiple typos, we only give suggestions
if we are able to resolve all typos in the expression
- This patch is similar to D37521 except that it does not eagerly
commit to a correction for the first typo in the expression.
Instead, it will search for corrections which fix all of the
typos in the expression.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62648
llvm-svn: 369427
Vitaly Buka