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
While the next Visual Studio update (16.3) will fix this issue, that hasn't
shipped yet. Until then Clang wouldn't work with MSVC's headers which seems
unfortunate. Let's keep this in until VS 16.3 ships. (See also PR42843.)
> Fixes link errors with clang and the latest Visual C++ 14.21.27702
> headers, which was reported as PR42027.
>
> I chose to intentionally make these things linkonce_odr, i.e.
> discardable, so that we don't emit definitions of these things in every
> translation unit that includes STL headers.
>
> Note that this is *not* what MSVC does: MSVC has not yet implemented C++
> DR2387, so they emit fully specialized constexpr variable templates with
> static / internal linkage.
>
> Reviewers: rsmith
>
> Differential Revision: https://reviews.llvm.org/D63175
llvm-svn: 370850
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
There are some functions which can't be given a null pointer as parameter either
because it has a nonnull attribute or it is declared to have undefined behavior
(e.g. strcmp()). Sometimes it is hard to determine from the checker message
which parameter is null at the invocation, so now this information is included
in the message.
This commit fixes https://bugs.llvm.org/show_bug.cgi?id=39358
Reviewed By: NoQ, Szelethus, whisperity
Patch by Tibor Brunner!
Differential Revision: https://reviews.llvm.org/D66333
llvm-svn: 370798
vote.ballot instruction is gone in recent CUDA versions and
vote.sync.ballot can not be used because it needs a thread mask parameter.
Fortunately PTX 6.2 (introduced with CUDA-9.2) provides activemask.b32
instruction for this.
Differential Revision: https://reviews.llvm.org/D66665
llvm-svn: 370792
Older FreeBSD versions included GDB 6.1 and had other tools that were
unable to handle debug information newer than DWARF 2. Those tools have
since been updated. (An old version of GDB is still kept for kernel
crash handling, but the kernel is compiled with an explicit -gdwarf2.)
Reviewed by: dim
Differential Revision: https://reviews.llvm.org/D66760
llvm-svn: 370779
Enables the users to specify an optional flag which would warn for more dead
stores.
Previously it ignored if the dead store happened e.g. in an if condition.
if ((X = generate())) { // dead store to X
}
This patch introduces the `WarnForDeadNestedAssignments` option to the checker,
which is `false` by default - so this change would not affect any previous
users.
I have updated the code, tests and the docs as well. If I missed something, tell
me.
I also ran the analysis on Clang which generated 14 more reports compared to the
unmodified version. All of them seemed reasonable for me.
Related previous patches:
rGf224820b45c6847b91071da8d7ade59f373b96f3
Reviewers: NoQ, krememek, Szelethus, baloghadamsoftware
Reviewed By: Szelethus
Patch by Balázs Benics!
Differential Revision: https://reviews.llvm.org/D66733
llvm-svn: 370767
Summary:
The declaration of arm neon intrinsics that are
"big endian safe" print the same code for big
and small endian targets.
This patch avoids duplicates by checking if an
intrinsic is safe to have a single definition.
(decreases header 11k lines out of 73k).
Reviewers: t.p.northover, ostannard, labrinea
Reviewed By: ostannard
Subscribers: kristof.beyls, cfe-commits, olista01
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66588
llvm-svn: 370716
Summary:
GCC seperates the `__riscv_float_abi_*` macros and the
`__riscv_abi_rve` macro. If the chosen abi is ilp32e, `gcc -march=rv32i
-mabi=ilp32i -E -dM` shows that both `__riscv_float_abi_soft` and
`__riscv_abi_rve` are set.
This patch corrects the compiler logic around these defines.
At the moment, this patch will not change clang's behaviour, because we do not
accept the `ilp32e` abi yet.
Reviewers: luismarques, asb
Reviewed By: luismarques
Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66591
llvm-svn: 370709
Summary:
The assertion happens when compiling with -Wdocumentation with variable declaration to a typedefed function pointer. I not too familiar with the ObjC syntax but first two tests assert without this patch.
Fixes https://bugs.llvm.org/show_bug.cgi?id=42844
Reviewers: gribozavr
Reviewed By: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66706
llvm-svn: 370677
Summary:
The structural equivalence check stores now pairs of nodes in the
'from' and 'to' context instead of only the node in 'from' context
and a corresponding one in 'to' context. This is needed to handle
cases when a Decl in the 'from' context is to be compared with
multiple Decls in the 'to' context.
Reviewers: martong, a_sidorin
Reviewed By: martong, a_sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66538
llvm-svn: 370639
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
Summary:
Correct order of fields and indirect fields in imported RecordDecl
is needed for correct work of record layout calculations.
Reviewers: martong, a.sidorin, shafik, a_sidorin
Reviewed By: martong, a_sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66866
llvm-svn: 370621
A class with a destructor marked final cannot be derived from, so it should afford the same devirtualization opportunities as marking the entire class final.
Patch by logan-5 (Logan Smith)
Reviewed by rsmith
Differential Revision: https://reviews.llvm.org/D66621
llvm-svn: 370597
Marking a class' destructor final prevents the class from being inherited from. However, it is a subtle and awkward way to express that at best, and unintended at worst. It may also generate worse code (in other compilers) than marking the class itself final. For these reasons, this revision adds a warning for nonfinal classes with final destructors, with a note to suggest marking the class final to silence the warning.
See https://reviews.llvm.org/D66621 for more background.
Patch by logan-5 (Logan Smith)
Differential Revision: https://reviews.llvm.org/D66711
llvm-svn: 370594
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
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
Summary:
Adds clang builtins and LLVM intrinsics for these experimental
instructions. They are not implemented in engines yet, but that is ok
because the user must opt into using them by calling the builtins.
Reviewers: aheejin, dschuff
Reviewed By: aheejin
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D67020
llvm-svn: 370556
containing designators. The C++20 wording doesn't actually say what
happens in this case, but treating this as a non-deduced context seems
like the most natural behavior.
(We might want to consider deducing through array designators as an
extension in the future, but will need to be careful to deduce the array
bound properly if we do so. That's not permitted herein.)
llvm-svn: 370555
If contents of a file that is part of a PCM are overridden when reading
it, but weren't overridden when the PCM was being built, the ASTReader
will emit an error. Now it creates a separate FileEntry for recovery,
bypassing the overridden content instead of discarding it. The
pre-existing testcase clang/test/PCH/remap-file-from-pch.cpp confirms
that the new recovery method works correctly.
This resolves a long-standing FIXME to avoid hypothetically invalidating
another precompiled module that's already using the overridden contents.
This also removes ContentCache-related API that would be unsafe to use
across `CompilerInstance`s in an implicit modules build. This helps to
unblock us sinking it from SourceManager into FileManager in the future,
which would allow us to delete `InMemoryModuleCache`.
https://reviews.llvm.org/D66710
llvm-svn: 370546
initializers.
This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:
* We continue to permit the full breadth of C99 designated initializers
in C++, with the exception that we disallow a partial overwrite of an
initializer with a non-trivially-destructible type. (Full overwrite
is OK, because we won't run the first initializer at all.)
* The C99 extensions are disallowed in SFINAE contexts and during
overload resolution, where they could change the meaning of valid
programs.
* C++20 disallows reordering of initializers. We only check for that for
the simple cases that the C++20 rules permit (designators of the form
'.field_name =' and continue to allow reordering in other cases).
It would be nice to improve this behavior in future.
* All C99 designated initializer extensions produce a warning by
default in C++20 mode. People are going to learn the C++ rules based
on what Clang diagnoses, so it's important we diagnose these properly
by default.
* In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
so still diagnose C99 extensions as described above. We continue to
accept designated C++20-compatible initializers in C++ <= 17 silently
by default (but naturally still reject under -pedantic-errors).
This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.
This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.
Differential Revision: https://reviews.llvm.org/D59754
llvm-svn: 370544
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
There's no need to purge symlinked entries in the FileManager,
as the new FileEntryRef API allows us to compute dependencies more
accurately when the FileManager is reused.
llvm-svn: 370493
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
Summary:
Consider this code:
```
void f() {
auto L0 = [](){};
auto L1 = [](){};
}
```
First we import `L0` then `L1`. Currently we end up having only one
CXXRecordDecl for the two different lambdas. And that is a problem if
the body of their op() is different. This happens because when we import
`L1` then lookup finds the existing `L0` and since they are structurally
equivalent we just map the imported L0 to be the counterpart of L1.
We have the same problem in this case:
```
template <typename F0, typename F1>
void f(F0 L0 = [](){}, F1 L1 = [](){}) {}
```
In StructuralEquivalenceContext we could distinquish lambdas only by
their source location in these cases. But we the lambdas are actually
structrually equivalent they differn only by the source location.
Thus, the solution is to disable lookup completely if the decl in
the "from" context is a lambda.
However, that could have other problems: what if the lambda is defined
in a header file and included in several TUs? I think we'd have as many
duplicates as many includes we have. I think we could live with that,
because the lambda classes are TU local anyway, we cannot just access
them from another TU.
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66348
llvm-svn: 370461
Summary:
If importing overridden methods fails for a method it can be seen
incorrectly as non-virtual. To avoid this inconsistency the method
is marked with import error to avoid later use of it.
Reviewers: martong, a.sidorin, shafik, a_sidorin
Reviewed By: martong, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66933
llvm-svn: 370457
Summary:
Nico Weber reported that the following code:
char buf[9];
asm("" : "=r" (buf));
yields the "impossible constraint in asm: can't store struct into a register"
error message, although |buf| is not a struct (see
http://crbug.com/999160).
Make the error message more generic and add a test for it.
Also make sure other tests in x86_64-PR42672.c check for the full error
message.
Reviewers: eli.friedman, thakis
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66948
llvm-svn: 370444
Roman Lebedev