When generating the decorated name for a static variable inside a
BlockDecl, construct a scope for the block invocation function that
homes the parameter. This allows for arbitrary nesting of the blocks
even if the variables are shadowed. Furthermore, using this for the name
allows for undname to properly undecorated the name for us. It shows up
as the synthetic __block_invocation function that the compiler emitted
in the local scope.
llvm-svn: 306347
Also add testcases for a bunch of expression forms that cause our evaluator to
crash. See PR33140 and PR32864 for crashes that this was causing.
This reverts r305287, which reverted r305239, which reverted r301742. The
previous revert claimed that buildbots were broken, but did not add any
testcases and the buildbots have lost all memory of what was wrong here.
Changes to test/OpenMP are not reverted; another change has triggered those
tests to change their output in the same way that r301742 did.
llvm-svn: 306346
modules to preprocessing of nested .pcm files.
Making those module files available results in loading more .pcm files than
necessary, and potentially in misbehavior if a module makes itself visible
during its own compilation (as parts of that module that have not yet been
processed would then become visible).
llvm-svn: 306320
definition or non-reference class type.
The crash occurs when there is a template parameter list in a class that
is missing the closing angle bracket followed by a definition of a
struct. For example:
class C0 {
public:
template<typename T, typename T1 = T // missing closing angle bracket
struct S0 {};
C0() : m(new S0<int>) {}
S0<int> *m;
};
This happens because the parsed struct is added to the scope of the
enclosing class without having its access specifier set, which results
in an assertion failure in SemaAccess.cpp later.
This commit fixes the crash by adding the parsed struct to the enclosing
file scope and marking structs as invalid if they are defined in
template parameter lists.
rdar://problem/31783961
rdar://problem/19570630
Differential Revision: https://reviews.llvm.org/D33606
llvm-svn: 306317
IAS is already used for MIPS64 in majority of Android projects.
Android MIPS64 uses N64 ABI. Set IAS as a default now.
Differential Revision: https://reviews.llvm.org/D34514
llvm-svn: 306280
Ananas is a home-brew operating system, mainly for amd64 machines. After
using GCC for quite some time, it has switched to clang and never looked
back - yet, having to manually patch things is annoying, so it'd be much
nicer if this was in the official tree.
More information:
https://github.com/zhmu/ananas/https://rink.nu/projects/ananas.html
Submitted by: Rink Springer
Differential Revision: https://reviews.llvm.org/D32936
llvm-svn: 306239
This check currently isn't able to diagnose any issues at -O0, not is it
likely to [1]. Disabling the check at -O0 leads to substantial compile
time and binary size savings.
[1] [cfe-dev] Disabling ubsan's object size check at -O0
Differential Revision: https://reviews.llvm.org/D34563
llvm-svn: 306181
This reverts commit r306137. It has problems on code like this:
struct __declspec(dllimport) Foo {
int a;
int get_a() { return a; }
};
template <int (Foo::*Getter)()> struct HasValue {
int operator()(Foo *p) { return (p->*Getter)(); }
};
int main() {
Foo f;
f.a = 3;
int x = HasValue<&Foo::get_a>()(&f);
}
llvm-svn: 306175
This patch makes ubsan's nonnull return value diagnostics more precise,
which makes the diagnostics more useful when there are multiple return
statements in a function. Example:
1 |__attribute__((returns_nonnull)) char *foo() {
2 | if (...) {
3 | return expr_which_might_evaluate_to_null();
4 | } else {
5 | return another_expr_which_might_evaluate_to_null();
6 | }
7 |} // <- The current diagnostic always points here!
runtime error: Null returned from Line 7, Column 2!
With this patch, the diagnostic would point to either Line 3, Column 5
or Line 5, Column 5.
This is done by emitting source location metadata for each return
statement in a sanitized function. The runtime is passed a pointer to
the appropriate metadata so that it can prepare and deduplicate reports.
Compiler-rt patch (with more tests): https://reviews.llvm.org/D34298
Differential Revision: https://reviews.llvm.org/D34299
llvm-svn: 306163
Summary:
Change data layout string so it would be compatible with MSP430 EABI.
Depends on D34561
Reviewers: asl, awygle
Reviewed By: asl
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34562
llvm-svn: 306161
(possible implicit) noexcept specifier
Throwing in the destructor is not good (C++11 change try to not allow see below).
But in reality, those codes are exist.
C++11 [class.dtor]p3:
A declaration of a destructor that does not have an exception-specification is
implicitly considered to have the same exception specification as an implicit
declaration.
With this change, the application worked before may now run into runtime
termination. My goal here is to emit a warning to provide only possible info to
where the code may need to be changed.
First there is no way, in compile time to identify the “throw” really throw out
of the function. Things like the call which throw out… To keep this simple,
when “throw” is seen, checking its enclosing function(only destructor and
dealloc functions) with noexcept(true) specifier emit warning.
Here is implementation detail:
A new member function CheckCXXThrowInNonThrowingFunc is added for class Sema
in Sema.h. It is used in the call to both BuildCXXThrow and
TransformCXXThrowExpr.
The function basic check if the enclosing function with non-throwing noexcept
specifer, if so emit warning for it.
The example of warning message like:
k1.cpp:18:3: warning: ''~dependent_warn'' has a (possible implicit) non-throwing
noexcept specifier. Throwing exception may cause termination.
[-Wthrow-in-dtor]
throw 1;
^
k1.cpp:43:30: note: in instantiation of member function
'dependent_warn<noexcept_fun>::~dependent_warn' requested here
dependent_warn<noexcept_fun> f; // cause warning
Differential Revision: https://reviews.llvm.org/D33333
llvm-svn: 306149
We were already applying the same rules to dllimport function pointers.
David Majnemer added that logic back in r211677 to fix PR20130. We
failed to extend that logic to non-virtual member function pointers,
which are basically function pointers in a struct with some extra
offsets.
Fixes PR33570.
llvm-svn: 306137
Currently, autocompleted options are displayed in the same order as we
wrote them in .td files. This patch sort them out in clang so that they
are sorted alphabetically. This should improve usability.
Differential Revision: https://reviews.llvm.org/D34557
llvm-svn: 306116
Restore the `-gz` option to the driver with some minor tweaks to handle
the additional case for `-Wa,--compress-debug-sections`.
This intends to make the compression of the debug information
controllable from the driver. The following is the behaviour:
-gz enable compression (ambiguous for format, will default to zlib-gnu)
-gz=none disable compression
-gz=zlib-gnu enable compression (deprecated GNU style zlib compression)
-gz=zlib enable compression (zlib based compression)
Although -Wa,-compress-debug-sections works, it should be discouraged
when using the driver to invoke the assembler. However, we permit the
assembler to accept the GNU as style argument --compress-debug-sections
to maintain compatibility.
Note, -gz/-gz= does *NOT* imply -g. That is, you need to additionally
specific -g for debug information to be generated.
llvm-svn: 306115
This commit fixes incorrect source positions of dependent c'tor initializers
like in the following code:
template<typename MyBase>
struct Derived: MyBase::InnerIterator
{
Derived() : MyBase::InnerIterator() {} /// This line is problematic: all positions point to InnerIterator and nothing points to MyBase
};
Patch by Serge Preis!
Differential Revision: https://reviews.llvm.org/D32439
llvm-svn: 306103
Summary:
Prior to this change, using `-fdiagnostics-show-hotness` with a sampling
profile specified via `-fprofile-sample-use=` would result in the Clang
frontend emitting a warning: "argument '-fdiagnostics-show-hotness' requires
profile-guided optimization information". Of course, a sampling profile
*is* profile-guided optimization information, so the warning is misleading.
Furthermore, despite the warning, hotness was displayed based on the data in
the sampling profile.
Prevent the warning from being emitted when a sampling profile is used, and
add a test that verifies this.
Reviewers: anemet, davidxl
Reviewed By: davidxl
Subscribers: danielcdh, cfe-commits
Differential Revision: https://reviews.llvm.org/D34082
llvm-svn: 306079
declarations that are owned but unconditionally visible.
This allows us to set declarations as visible even if they have a local owning
module, without losing information. In turn, that means that our Objective-C
support can keep on incorrectly assuming the "hidden" bit on the declaration is
the whole story with regard to name visibility. This will also be useful once
we support the C++ Modules TS export semantics.
Objective-C name visibility is still incorrect in any case where the "hidden"
bit is not the complete story: for instance, in Objective-C++ the set of
visible categories will be wrong during template instantiation, and with local
submodule visibility enabled it will be wrong when building modules. Fixing that
will require a major overhaul of how visibility is handled for Objective-C (and
particularly for categories).
llvm-svn: 306075
Also, don't use the outdated lib32/lib64 naming of files
within the sysroot. The more modern/flexible approach
IIUC is to use seperate sysroots or /lib/<target-tripple>
and /include/<target-tripple>.
Differential Revision: https://reviews.llvm.org/D33565
llvm-svn: 306074
The new compiler warning -Wunguarded-availability-new is a subset of
-Wunguarded-availability. It is on by default. It only warns about uses of APIs
that have been introduced in macOS >= 10.13, iOS >= 11, watchOS >= 4 and
tvOS >= 11. We decided to use this kind of solution as we didn't want to turn
on -Wunguarded-availability by default, because we didn't want our users to get
warnings about uses of old APIs in their existing projects.
rdar://31054725
Differential Revision: https://reviews.llvm.org/D34264
llvm-svn: 306033
of class template specializations
This commit fixes an issue where a forward declaration of a class template
specialization was not related to the base template. We need to relate even
forward declarations because specializations don't have to be defined.
rdar://32869409
Differential Revision: https://reviews.llvm.org/D34462
llvm-svn: 305996
We need to take type alignment padding into account whe computing physical
layouts.
The layout must be compatible with the input layout, offsets are defined in
terms of offsets within a packed struct which are computed in terms of the alloc
size of a type.
Usingthe store size we would insert padding for the following type for example:
struct {
int3 v;
long long l;
} __attribute((packed))
On x86-64 int3 is padded to int4 alignment. The swiftcc type would be
<{ <3 x float>, [4 x i8], i64 }> which is not compatible with <{ <3 x float>,
i64 }>.
The latter has i64 at offset 16 and the former at offset 20.
rdar://32618125
llvm-svn: 305956
'HandleEndifDirective' asserts that 'WasSkipping' is false, so switch to using 'FoundNonSkip' as the hint for 'SingleFileParseMode' to keep going with parsing.
llvm-svn: 305940
In running some internal vectorcall tests in 32 bit mode, we discovered that the
behavior I'd previously implemented for x64 (and applied to x32) regarding the
assignment of SSE registers was incorrect. See spec here:
https://msdn.microsoft.com/en-us/library/dn375768.aspx
My previous implementation applied register argument position from the x64
version to both. This isn't correct for x86, so this removes and refactors that
section. Additionally, it corrects the integer/int-pointer assignments. Unlike
x64, x86 permits integers to be assigned independent of position.
Finally, the code for 32 bit was cleaned up a little to clarify the intent,
as well as given a descriptive comment.
Differential Revision: https://reviews.llvm.org/D34455
llvm-svn: 305928
Summary:
This is the same as Inline, except it does not imply all empty
functions are merged: with this style, empty functions are merged only
if they also match the 'inline' criteria (i.e. defined in a class).
This is helpful to avoid inlining functions in implementations files.
Reviewers: djasper, krasimir
Reviewed By: djasper
Subscribers: klimek, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D34399
llvm-svn: 305912
"specializationOf" relation if they pseudo-override a type in the base template
This commit fixes an issue where Xcode's renaming engine couldn't find the
reference to the second occurrence of "InnerClass" in this example:
template<typename T> struct Ts { template<typename U> struct InnerClass { }; };
template<> struct Ts<int> {
template<typename U> struct InnerClass; // This occurrence wasn't renamed
};
rdar://31884960
Differential Revision: https://reviews.llvm.org/D34392
llvm-svn: 305911
While a function body is being parsed, the function declaration is not considered
as a definition because it does not have a body yet. In some cases it leads to
incorrect interpretation, the case is presented in
https://bugs.llvm.org/show_bug.cgi?id=14785:
```
template<typename T> struct Somewhat {
void internal() const {}
friend void operator+(int const &, Somewhat<T> const &) {}
};
void operator+(int const &, Somewhat<char> const &x) { x.internal(); }
```
When statement `x.internal()` in the body of global `operator+` is parsed, the type
of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It
instantiates the declaration of `operator+` defined inline, and makes a check for
redefinition. The check does not detect another definition because the declaration
of `operator+` is still not defining as does not have a body yet.
To solves this problem the function `isThisDeclarationADefinition` considers
a function declaration as a definition if it has flag `WillHaveBody` set.
This change fixes PR14785.
Differential Revision: https://reviews.llvm.org/D30375
This is a recommit of 305379, reverted in 305381, with small changes.
llvm-svn: 305903
This makes the analyzer around 10% slower by default,
allowing it to find deeper bugs.
Default values for the following -analyzer-config change:
max-nodes: 150000 -> 225000;
max-inlinable-size: 50 -> 100.
rdar://problem/32539666
Differential Revision: https://reviews.llvm.org/D34277
llvm-svn: 305900
Add support for new methods that were added in macOS High Sierra & iOS 11
and require a localized string.
Patch by Kulpreet Chilana!
rdar://problem/32795210
Differential Revision: https://reviews.llvm.org/D34266
llvm-svn: 305896
deployment target if the SDK is newer than the system
This commit also reverts follow-up commits r305680 and r305685 that have
buildbot fixes.
The change in r305678 wasn't correct because it relied on
`llvm::sys::getProcessTriple`, which uses a pre-configured OS version. We should
lookup the actual macOS version of the system on which the compiler is running.
llvm-svn: 305891
This allows for -fms-extensions to work the same on LP64. For example,
_BitScanReverse is expected to be 32-bit, matching Windows/LLP64, even
though long is 64-bit on x86_64 Darwin or Linux (LP64).
Implement this by adding a new character code 'N', which is 'int' if
the target is LP64 and the same 'L' otherwise
Differential Revision: https://reviews.llvm.org/D34377
rdar://problem/32599746
llvm-svn: 305875
Summary:
The ASTImporter should import CXX method overrides from the source context
when it imports a method decl.
Reviewers: spyffe, rsmith, doug.gregor
Reviewed By: spyffe
Differential Revision: https://reviews.llvm.org/D34371
llvm-svn: 305850
ExpansionLoc was previously calculated incorrectly in the case of
nested macros expansions. In this diff we build the stack of expansions
where the last one is the actual expansion which should be used
for grouping together the edits.
The definition of MacroArgUse is adjusted accordingly.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D34268
llvm-svn: 305845
Richard Smith