Summary:
Currently clang doesn't do qualified lookup when building indirect field decl references. This causes ambiguity when the field is in a base class to which there are multiple valid paths even though a qualified name is used.
For example:
```
class B {
protected:
int i;
union { int j; };
};
class X : public B { };
class Y : public B { };
class Z : public X, public Y {
int a() { return X::i; } // works
int b() { return X::j; } // fails
};
```
Eric Fiselier [Sun, 8 Apr 2018 05:12:55 +0000 (05:12 +0000)]
[Sema] Remove dead code in BuildAnonymousStructUnionMemberReference. NFCI
Summary:
This patch cleans up a bunch of dead or unused code in BuildAnonymousStructUnionMemberReference.
The dead code was a branch that built a new CXXThisExpr when we weren't given a base object expression or base variable.
However, BuildAnonymousFoo has only two callers. One of which always builds a base object expression first, the second only calls when the IndirectFieldDecl is not a C++ class member. Even within C this branch seems entirely unused.
I tried diligently to write a test which hit it with no success.
This patch removes the branch and replaces it with an assertion that we were given either a base object expression or a base variable.
Fangrui Song [Sat, 7 Apr 2018 20:50:35 +0000 (20:50 +0000)]
[libclang] Add clang_File_tryGetRealPathName
Summary:
clang_getFileName() may return a path relative to WorkingDir.
On Arch Linux, during clang_indexTranslationUnit(), clang_getFileName() on
CXIdxIncludedIncludedFileInfo::file may return
"/../lib64/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/string",
for `#include <string>`.
I presume WorkingDir is somehow changed to /usr/lib or /usr/include and
clang_getFileName() returns a path relative to WorkingDir.
clang_File_tryGetRealPathName() returns "/usr/include/c++/7.3.0/string"
which is more useful for the indexer in this case.
Roman Lebedev [Sat, 7 Apr 2018 10:39:21 +0000 (10:39 +0000)]
[Sema] Extend -Wself-assign and -Wself-assign-field to warn on overloaded self-assignment (classes)
Summary:
This has just bit me, so i though it would be nice to avoid that next time :)
Motivational case:
https://godbolt.org/g/cq9UNk
Basically, it's likely to happen if you don't like shadowing issues,
and use `-Wshadow` and friends. And it won't be diagnosed by clang.
The reason is, these self-assign diagnostics only work for builtin assignment
operators. Which makes sense, one could have a very special operator=,
that does something unusual in case of self-assignment,
so it may make sense to not warn on that.
But while it may be intentional in some cases, it may be a bug in other cases,
so it would be really great to have some diagnostic about it...
Alex Lorenz [Sat, 7 Apr 2018 00:03:27 +0000 (00:03 +0000)]
Recommit r329442: Generate Libclang invocation reproducers using a new
-cc1gen-reproducer driver option
The recommit fixes:
- An MSAN failure (CCPrintOptions wasn't initialized in the Driver)
- Ensures that the strings in the libclang invocation files are escaped
Original message:
This commit is a follow up to the previous work that recorded Libclang invocations
into temporary files: r319702.
It adds a new -cc1 mode to clang: -cc1gen-reproducer. The goal of this mode is to generate
Clang reproducer files for Libclang tool invocation. The JSON format in the invocation
files is not really intended to be stable, so Libclang and Clang should be of the same version
when generating reproducers.
The new mode emits the information about the temporary files and Libclang-specific information
to stdout using JSON.
Alex Lorenz [Fri, 6 Apr 2018 18:30:14 +0000 (18:30 +0000)]
Generate Libclang invocation reproducers using a new -cc1gen-reproducer
driver option
This commit is a follow up to the previous work that recorded Libclang invocations
into temporary files: r319702.
It adds a new -cc1 mode to clang: -cc1gen-reproducer. The goal of this mode is to generate
Clang reproducer files for Libclang tool invocation. The JSON format in the invocation
files is not really intended to be stable, so Libclang and Clang should be of the same version
when generating reproducers.
The new mode emits the information about the temporary files and Libclang-specific information
to stdout using JSON.
Allow the creation of human-friendly ASTDumper to arbitrary output stream
Summary:
`ASTPrinter` allows setting the ouput to any O-Stream, but that printer creates source-code-like syntax (and is also marked with a `FIXME`). The nice, colourful, mostly human-readable `ASTDumper` only works on the standard output, which is not feasible in case a user wants to see the AST of a file through a code navigation/comprehension tool.
This small addition of an overload solves generating a nice colourful AST block for the users of a tool I'm working on, [[ http://github.com/Ericsson/CodeCompass | CodeCompass ]], as opposed to having to duplicate the behaviour of definitions that only exist in the anonymous namespace of implementation TUs related to this module.
[XRay][clang] Add a flag to enable/disable linking XRay deps explicitly
Summary:
This change introduces `-fxray-link-deps` and `-fnoxray-link-deps`. The
`-fnoxray-link-deps` allows for directly controlling which specific XRay
runtime to link. The default is for clang to link the XRay runtime that
is shipped with the compiler (if there are any), but users may want to
explicitly add the XRay dependencies from other locations or other
means.
[XRay][clang] Consolidate runtime and link-time flag processing (NFC)
Summary:
This change fixes http://llvm.org/PR36985 to define a single place in
CommonArgs.{h,cpp} where XRay runtime flags and link-time dependencies
are processed for all toolchains that support XRay instrumentation. This
is a refactoring of the same functionality spread across multiple
toolchain definitions.
Richard Smith [Thu, 5 Apr 2018 20:52:58 +0000 (20:52 +0000)]
PR36992: do not store beyond the dsize of a class object unless we know
the tail padding is not reused.
We track on the AggValueSlot (and through a couple of other
initialization actions) whether we're dealing with an object that might
share its tail padding with some other object, so that we can avoid
emitting stores into the tail padding if that's the case. We still
widen stores into tail padding when we can do so.
The new rules say that a standard-layout struct has its first non-static
data member and all base classes at offset 0, and consider a class to
not be standard-layout if that would result in multiple subobjects of a
single type having the same address.
We track "is C++11 standard-layout class" separately from "is
standard-layout class" so that the ABIs that need this information can
still use it.
Summary:
"-fmerge-all-constants" is a non-conforming optimization and should not
be the default. It is also causing miscompiles when building Linux
Kernel (https://lkml.org/lkml/2018/3/20/872).
The lightweight generic specifier list appears before the base
class, if present, but because it starts with < like the protocol
specifier list, `UnwrappedLineParser` was getting confused and
failed to parse interfaces with both generics and protocol lists:
Since the parsed line would be incomplete, the format result
would be very confused (e.g., https://bugs.llvm.org/show_bug.cgi?id=24381).
This fixes the issue by explicitly parsing the ObjC lightweight
generic conformance list, so the line is fully parsed.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=24381
Test Plan: New tests added. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
This caused us to incorrectly indent 0-argument wrapped selectors
when Style.IndentWrappedFunctionNames was false, as we thought
the 0-argument ObjC selector name was actually a trailing
annotation (which is always indented).
This diff fixes the issue and adds tests.
Test Plan: New tests added. Confirmed tests failed before diff.
After diff, tests passed. Ran tests with:
% make -j12 FormatTests &&
./tools/clang/unittests/Format/FormatTests
[ObjC] Make C++ triviality type traits available to non-trivial C
structs.
r326307 and r327870 made changes that allowed using non-trivial C
structs with fields qualified with __strong or __weak. This commit makes
the following C++ triviality type traits available to non-trivial C
structs:
This reapplies r328680. This commit fixes a bug where the copy/move
__has_trivial_* traits would return false when a volatile type was being
passed. Thanks to Richard Smith for pointing out the mistake.
Memory sanitizer compatibility are already done in
MemorySanitizer::doInitialization. It verifies whether the necessary offsets
exist and bails out if not. For this reason it is no good to duplicate two
checks in two projects. This patch removes clang check and postpones msan
compatibility validation till MemorySanitizer::doInitialization.
Another reason for this patch is to allow using msan with any CPU (given
compatible runtime) and custom mapping provided via the arguments added by
https://reviews.llvm.org/D44926.
AArch64: Implement support for the shadowcallstack attribute.
The implementation of shadow call stack on aarch64 is quite different to
the implementation on x86_64. Instead of reserving a segment register for
the shadow call stack, we reserve the platform register, x18. Any function
that spills lr to sp also spills it to the shadow call stack, a pointer to
which is stored in x18.
Mark Zeren [Wed, 4 Apr 2018 21:09:00 +0000 (21:09 +0000)]
[clang-format] In tests, expected code should be format-stable
Summary: Extend various verifyFormat helper functions to check that the
expected text is "stable". This provides some protection against bugs
where formatting results are ocilating between two forms, or continually
change in some other way.
Testing Done:
* Ran unit tests.
* Reproduced a known instability in preprocessor indentation which was
caught by this new check.
Max Moroz [Wed, 4 Apr 2018 19:47:25 +0000 (19:47 +0000)]
Fixes errors with FS iterators caused by https://reviews.llvm.org/D44960
Summary:
In https://reviews.llvm.org/D44960, file status check is executed every
time a real file system directory iterator is constructed or
incremented, and emits an error code. This change list fixes the errors
in VirtualFileSystem caused by https://reviews.llvm.org/D44960.
[XRay][clang] Allow clang to build XRay instrumented binaries in OpenBSD
Summary:
This patch was originally reviewed in D45126. It enables clang to add
the XRay runtime and the link-time dependencies for XRay instrumentation
in OpenBSD.
Eric Fiselier [Wed, 4 Apr 2018 06:31:21 +0000 (06:31 +0000)]
Fix typo in ASTStructuralEquivalence.cpp for UnaryTransform types.
Previously UnaryTransformType nodes were comparing the same node
for structural equivalence. This was due to a typo where T1 was
on both sides of the comparison. This patch corrects that typo.
Unfortunately I couldn't find a way to test this change. It seems
that currently UnaryTransform nodes are never actually checked
for equivalence, only their canonical types are.
None the less, this correction seemed appropriate.
Alex Lorenz [Wed, 4 Apr 2018 02:11:20 +0000 (02:11 +0000)]
Split test/Driver/darwin-sdkroot.c into two tests
The test additions in r329110 are Darwin-specific, as they rely
on a code path that is reachabled when driver is invoked without
-target. Instead of making the old test checks Darwin-specific too,
let's simply split it into two files to ensure that the old
checks are still platform-agnostic. Thanks Chandler for
suggesting this!
Summary:
Add support for the -fsanitize=shadow-call-stack flag which causes clang
to add ShadowCallStack attribute to functions compiled with that flag
enabled.
[analyzer] Fix diagnostics in callees of interesting callees.
removeUnneededCalls() is responsible for removing path diagnostic pieces within
functions that don't contain "interesting" events. It makes bug reports
much tidier.
When a stack frame is known to be interesting, the function doesn't descend
into it to prune anything within it, even other callees that are totally boring.
Fix the function to prune boring callees in interesting stack frames.
Ben Hamilton [Tue, 3 Apr 2018 14:07:11 +0000 (14:07 +0000)]
[clang-format/ObjC] Do not detect "[]" as ObjC method expression
Summary:
The following C++ code was being detected by
`guessLanguage()` as Objective-C:
#define FOO(...) auto bar = [] __VA_ARGS__;
This was because `[] __VA_ARGS__` is not currently detected as a C++
lambda expression (it has no parens or braces), so
`TokenAnnotator::parseSquare()` incorrectly treats the opening square
as an ObjC method expression.
We have two options to fix this:
1. Parse `[] __VA_ARGS__` explicitly as a C++ lambda
2. Make it so `[]` is never parsed as an Objective-C method expression
This diff implements option 2, which causes the `[` to be parsed
as `TT_ArraySubscriptLSquare` instead of `TT_ObjCMethodExpr`.
Note that when I fixed this, it caused one change in formatting
behavior, where the following was implicitly relying on the `[`
being parsed as `TT_ObjCMethodExpr`:
A<int * []> a;
becomes:
A<int *[]> a;
with `Style.PointerAlignment = Middle`.
I don't really know what the desired format is for this syntax; the
test was added by Janusz Sobczak and integrated by @djasper in
https://github.com/llvm-mirror/clang/commit/b511fe9818829d7ece0cc0b2ce1fbe04a1f0739a
.
I went ahead and changed the test for now.
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Ben Hamilton [Tue, 3 Apr 2018 14:07:09 +0000 (14:07 +0000)]
[clang-format/ObjC] Do not insert space after opening brace of ObjC dict literal
Summary:
D44816 attempted to fix a few cases where `clang-format` incorrectly
inserted a space before the closing brace of an Objective-C dictionary
literal.
This revealed there were still a few cases where we inserted a space
after the opening brace of an Objective-C dictionary literal.
This fixes the formatting to be consistent and adds more tests.
Test Plan: New tests added. Confirmed tests failed before
diff and passed after diff.
Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Petr Hosek [Mon, 2 Apr 2018 23:36:14 +0000 (23:36 +0000)]
[Driver] Wire up the -f[no-]rtlib-add-rpath flag and tests
D30700 added the -f[no-]rtlib-add-rpath flag, but that flag was never
wired up in the driver and tests were updated to check whether it
actually does anything. This patch wires up the flag and updates test.
Microsoft has reserved 'U' for the PreserveMostCC which is used in the
swift runtime. Add support for this. This allows the swift runtime to
be built for Windows again.
[MS] Emit vftable thunks for functions with incomplete prototypes
Summary:
The following class hierarchy requires that we be able to emit a
this-adjusting thunk for B::foo in C's vftable:
struct Incomplete;
struct A {
virtual A* foo(Incomplete p) = 0;
};
struct B : virtual A {
void foo(Incomplete p) override;
};
struct C : B { int c; };
This TU is valid, but lacks a definition of 'Incomplete', which makes it
hard to build a thunk for the final overrider, B::foo.
Before this change, Clang gives up attempting to emit the thunk, because
it assumes that if the parameter types are incomplete, it must be
emitting the thunk for optimization purposes. This is untrue for the MS
ABI, where the implementation of B::foo has no idea what thunks C's
vftable may require. Clang needs to emit the thunk without necessarily
having access to the complete prototype of foo.
This change makes Clang emit a musttail variadic call when it needs such
a thunk. I call these "unprototyped" thunks, because they only prototype
the "this" parameter, which must always come first in the MS C++ ABI.
These thunks work, but they create ugly LLVM IR. If the call to the
thunk is devirtualized, it will be a call to a bitcast of a function
pointer. Today, LLVM cannot inline through such a call, but I want to
address that soon, because we also use this pattern for virtual member
pointer thunks.
This change also implements an old FIXME in the code about reusing the
thunk's computed CGFunctionInfo as much as possible. Now we don't end up
computing the thunk's mangled name and arranging it's prototype up to
around three times.
Fix some DenseMap use-after-rehash bugs and hoist MethodVFTableLocation
This re-lands r328845 with fixes for crbug.com/827810.
The initial motiviation was to hoist MethodVFTableLocation to global
scope so it could be forward declared.
In this patch, I noticed that MicrosoftVTableContext uses some risky
patterns. It has methods that return references to data stored in
DenseMaps. I've made some of them return by value for trivial structs
and I've moved some things into separate allocations.
A recent addition to Coroutines TS (https://wg21.link/p0913) adds a pre-defined
coroutine noop_coroutine that does nothing. To implement this feature, we implemented
an llvm.coro.noop intrinsic that returns a coroutine handle to a coroutine that
does nothing when resumed or destroyed.
This patch adds a builtin __builtin_coro_noop() that maps to llvm.coro.noop intrinsic.
Related llvm change: https://reviews.llvm.org/D45114
Brian Gesiak [Sun, 1 Apr 2018 23:55:21 +0000 (23:55 +0000)]
[Coroutines] Schedule coro-split before asan
Summary:
The docs for the LLVM coroutines intrinsic `@llvm.coro.id` state that
"The second argument, if not null, designates a particular alloca instruction
to be a coroutine promise."
However, if the address sanitizer pass is run before the `@llvm.coro.id`
intrinsic is lowered, the `alloca` instruction passed to the intrinsic as its
second argument is converted, as per the
https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm docs, to
an `inttoptr` instruction that accesses the address of the promise.
On optimization levels `-O1` and above, the `-asan` pass is run after
`-coro-early`, `-coro-split`, and `-coro-elide`, and before
`-coro-cleanup`, and so there is no issue. At `-O0`, however, `-asan`
is run in between `-coro-early` and `-coro-split`, which causes an
assertion to be hit when the `inttoptr` instruction is forcibly cast to
an `alloca`.
Rearrange the passes such that the coroutine passes are registered
before the sanitizer passes.
Test Plan:
Compile a simple C++ program that uses coroutines in `-O0` with
`-fsanitize-address`, and confirm no assertion is hit:
`clang++ coro-example.cpp -fcoroutines-ts -g -fsanitize=address -fno-omit-frame-pointer`.
Brian Gesiak [Sun, 1 Apr 2018 22:59:22 +0000 (22:59 +0000)]
[Coroutines] Find custom allocators in class scope
Summary:
https://reviews.llvm.org/rL325291 implemented Coroutines TS N4723
section [dcl.fct.def.coroutine]/7, but it performed lookup of allocator
functions within both the global and class scope, whereas the specified
behavior is to perform lookup for custom allocators within just the
class scope.
To fix, add parameters to the `Sema::FindAllocationFunctions` function
such that it can be used to lookup allocators in global scope,
class scope, or both (instead of just being able to look up in just global
scope or in both global and class scope). Then, use those parameters
from within the coroutine Sema.
This incorrect behavior had the unfortunate side-effect of causing the
bug https://bugs.llvm.org/show_bug.cgi?id=36578 (or at least the reports
of that bug in C++ programs). That bug would occur for any C++ user with
a coroutine frame that took a single pointer argument, since it would
then find the global placement form `operator new`, described in the
C++ standard 18.6.1.3.1. This patch prevents Clang from generating code
that triggers the LLVM assert described in that bug report.
John McCall [Sun, 1 Apr 2018 21:04:30 +0000 (21:04 +0000)]
Fix a major swiftcall ABI bug with trivial C++ class types.
The problem with the previous logic was that there might not be any
explicit copy/move constructor declarations, e.g. if the type is
trivial and we've never type-checked a copy of it. Relying on Sema's
computation seems much more reliable.
Also, I believe Richard's recommendation is exactly the rule we use
now on the Itanium ABI, modulo the trivial_abi attribute (which this
change of course fixes our handling of in Swift).
This does mean that we have a less portable rule for deciding
indirectness for swiftcall. I would prefer it if we just applied the
Itanium rule universally under swiftcall, but in the meantime, I need
to fix this bug.
This only arises when defining functions with class-type arguments
in C++, as we do in the Swift runtime. It doesn't affect normal Swift
operation because we don't import code as C++.
Henry Wong [Sat, 31 Mar 2018 12:46:46 +0000 (12:46 +0000)]
[analyzer] Unroll the loop when it has a unsigned counter.
Summary:
The original implementation in the `LoopUnrolling.cpp` didn't consider the case where the counter is unsigned. This case is only handled in `simpleCondition()`, but this is not enough, we also need to deal with the unsinged counter with the counter initialization.
Since `IntegerLiteral` is `signed`, there is a `ImplicitCastExpr<IntegralCast>` in `unsigned counter = IntergerLiteral`. This patch add the `ignoringParenImpCasts()` in the `IntegerLiteral` matcher.
George Karpenkov [Sat, 31 Mar 2018 01:20:06 +0000 (01:20 +0000)]
[analyzer] Fix liveness calculation for C++17 structured bindings
C++ structured bindings for non-tuple-types are defined in a peculiar
way, where the resulting declaration is not a VarDecl, but a
BindingDecl.
That means a lot of existing machinery stops working.
Peter Szecsi [Fri, 30 Mar 2018 22:03:29 +0000 (22:03 +0000)]
[ASTImporter] Add test helper Fixture
Add a helper test Fixture, so we can add tests which can check internal
attributes of AST nodes like getPreviousDecl(), isVirtual(), etc.
This enables us to check if a redeclaration chain is correctly built during
import, if the virtual flag is preserved during import, etc. We cannot check
such attributes with the existing testImport.
Also, this fixture makes it possible to import from several "From" contexts.
We also added several test cases here, some of them are disabled.
We plan to pass the disabled tests in other patches.
Artem Dergachev [Fri, 30 Mar 2018 19:27:42 +0000 (19:27 +0000)]
[analyzer] Track null or undef values through pointer arithmetic.
Pointer arithmetic on null or undefined pointers results in null or undefined
pointers. This is obvious for undefined pointers; for null pointers it follows
from our incorrect-but-somehow-working approach that declares that 0 (Loc)
doesn't necessarily represent a pointer of numeric address value 0, but instead
it represents any pointer that will cause a valid "null pointer dereference"
issue when dereferenced.
For now we've been seeing through pointer arithmetic at the original dereference
expression, i.e. in bugreporter::getDerefExpr(), but not during further
investigation of the value's origins in bugreporter::trackNullOrUndefValue().
The patch fixes it.
Artem Dergachev [Fri, 30 Mar 2018 19:25:39 +0000 (19:25 +0000)]
[CFG] [analyzer] Work around a disappearing CXXBindTemporaryExpr.
Sometimes template instantiation causes CXXBindTemporaryExpr to be missing in
its usual spot. In CFG, temporary destructors work by relying on
CXXBindTemporaryExprs, so they won't work in this case.
Avoid the crash and notify the clients that we've encountered an unsupported AST
by failing to provide the ill-formed construction context for the temporary.
projects / clang / log