Summary:
In JavaScript, object literals can contain methods:
var x = {
a() { return 1; },
};
Previously, clang-format always parsed nested {} inside a braced list as
further braced lists. Special case this logic for JavaScript to try
parsing as a braced list, but fall back to parsing as a child block.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D29656
llvm-svn: 294315
Fix for bug 30217 - incorrect error given for logical
NOT operation with a pointer type: corrected sema check
and improved related tests.
Review: D29038
llvm-svn: 294313
Summary:
Regex detection would incorrectly classify a trailing `!` operator
(nullability cast) followed by a `/` as the start of a regular
expression literal. This fixes code such as:
var foo = x()! / 10;
Which would previously parse a regexp all the way to the end of the
source file (or next `/`).
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29634
llvm-svn: 294304
Summary:
In JavaScript, classes are expressions, so they can appear e.g. in
argument lists.
var C = foo(class {
bar() {
return 1;
}
};
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29635
llvm-svn: 294302
We model deduction-guides as functions with a new kind of name that identifies
the template whose deduction they guide; the bulk of this patch is adding the
new name kind. This gives us a clean way to attach an extensible list of guides
to a class template in a way that doesn't require any special handling in AST
files etc (and we're going to need these functions we come to performing
deduction).
llvm-svn: 294266
GCC 7 will predefine two new macros on s390x:
- __ARCH__ indicates the ISA architecture level
- __VX__ indicates that the vector facility is available
This adds those macros to clang as well to ensure continued
compatibility with GCC.
llvm-svn: 294197
https://reviews.llvm.org/D29501
It looks like I forgot to remove a FIXME comment with the associated statement. The test does not need it and it gives the wrong impression of being an incomplete test.
llvm-svn: 294195
Fix for the formatting options combination of
BreakBeforeBinaryOperators: All, AlignAfterOpenBracket: AlwaysBreak not
handling long templates correctly. This patch allows a break after an
opening left parenthesis, TemplateOpener, or bracket when both options
are enabled.
Patch by Daphne Pfister, thank you!
Fixes llvm.org/PR30304.
llvm-svn: 294179
Summary:
This tells clang about all of the different AVR microcontrollers.
It also adds code to define the correct preprocessor macros for each
device.
Reviewers: jroelofs, asl
Reviewed By: asl
Subscribers: asl, cfe-commits
Differential Revision: https://reviews.llvm.org/D28346
llvm-svn: 294177
Summary:
Previously the method would simply return false, causing every single
inline assembly constraint to trigger a compile error.
This adds inline assembly constraint support for the AVR target.
This patch is derived from the code in
AVRISelLowering::getConstraintType.
More details can be found on the AVR-GCC reference wiki
http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
Reviewers: jroelofs, asl
Reviewed By: asl
Subscribers: asl, ahatanak, saaadhu, cfe-commits
Differential Revision: https://reviews.llvm.org/D28344
llvm-svn: 294176
GCC does not generate `__unix` nor `unix` macros. The latter already
intrudes into the user's namespace and should be avoided. Use the
canonical spelling of `__unix__` across all the targets.
llvm-svn: 294148
While there is nothing to do at link time to get pthreads support on
darwin, specifying the argument is fine and we should not warn about
unused arguments.
llvm-svn: 294065
After r260016 and r260017 disabled typo correction for ivars and properties
clang didn't report errors about unresolved identifier in the base of ivar and
property ref expressions. This meant that clang invoked CodeGen on invalid AST
which then caused a crash.
This commit re-enables typo correction for ivars and properites, and fixes the
PR25113 & PR26486 (that were originally fixed in r260017 and r260016) in a
different manner by transforming the Objective-C ivar reference expression with
'IsFreeIvar' preserved.
rdar://30310772
llvm-svn: 294008
Summary:
The comment aligner was skipping over newly broken comment lines. This patch fixes that.
source:
```
int ab; // line
int a; // long long
```
format with column limit 15 before:
```
int ab; // line
int a; // long
// long
```
format with column limit 15 after:
```
int ab; // line
int a; // long
// long
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29486
llvm-svn: 293997
Summary:
The patch updates the MSVC ToolChain for the changes made in Visual
Studio 2017[1].
Other notable changes:
- Path handling code has been centralised to make potential future
changes less painful.
- A compiler error is emitted if the driver is unable to locate a
usable MSVC toolchain. (Previously it'd fail with a cryptic error
such as "link.exe is not executable")
- Support for the new Setup Config Server API[2] has been added,
albeit block commented out with a preprocessor conditional. This can
probably be re-evaluated when the API is officially released (it's
currently at the RC stage), but it's left in to make it easy for
anyone familiar with the API to give it a go with Clang.
Patch by Hamza Sood.
[1] https://blogs.msdn.microsoft.com/vcblog/2016/10/07/compiler-tools-layout-in-visual-studio-15/
[2] https://blogs.msdn.microsoft.com/heaths/2016/09/15/changes-to-visual-studio-15-setup/
Reviewers: ruiu, hans, rnk
Reviewed By: rnk
Subscribers: awson, RKSimon, amccarth, cfe-commits
Differential Revision: https://reviews.llvm.org/D28365
llvm-svn: 293923
Guard against a null pointer dereference that caused Clang to crash
when processing a class containing an _Atomic qualified data member,
and that is tagged with 'dllexport'.
Differential Revision: https://reviews.llvm.org/D29208
llvm-svn: 293911
Summary:
The comment reflower wasn't taking comment pragmas as reflow stoppers. This patch fixes that.
source:
```
// long long long long
// IWYU pragma:
```
format with column limit = 20 before:
```
// long long long
// long IWYU pragma:
```
format with column limit = 20 after:
```
// long long long
// long
// IWYU pragma:
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29450
llvm-svn: 293898
Summary:
The breaking of line comment sections was misaligning the case where the first comment line is on an unwrapped line containing newlines. In this case, the breaking column must be based on the source column of the last token that is preceded by a newline, not on the first token of the unwrapped line.
source:
```
enum A {
a, // line 1
// line 2
};
```
format before:
```
enum A {
a, // line 1
// line 2
};
```
format after:
```
enum A {
a, // line 1
// line 2
};
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29444
llvm-svn: 293891
Without alignment, there is no clean separation between the arguments, even if
there are only two.
Before:
aaaaaaaaaaaaaa(
aaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaaaaaaa(aaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 293875
Initialize fields directly in header. Note that the ModuleManager field is an
IntrusiveRefCntPtr, so there's no need for explicit initialization.
llvm-svn: 293863
name. If the dependent name happened to end in a template-id (X<T>::Y<U>), we
would fail to notice that the 'typename' keyword is missing when resolving it
to a type.
It turns out that GCC has a similar bug. If this shows up in much real code, we
can easily downgrade this to an ExtWarn.
llvm-svn: 293815
For non-template dllimport functions, MSVC allows providing an inline
definition without spelling out the attribute again. In the example below, f
remains a dllimport function.
__declspec(dllimport) int f();
inline int f() { return 42; }
int useit() {
return f();
}
However, for a function template, not putting dllimport on the redeclaration
causes it to be dropped. In the example below, f is not dllimport.
template <typename> __declspec(dllimport) int f();
template <typename> inline int f() { return 42; }
int useit() {
return f<int>();
}
This patch makes Clang match MSVC for the second example.
MSVC does not warn about the attribute being dropped in the example above, but
I think we should. (MSVC does warn if the inline keyword isn't used.)
Differential Revision: https://reviews.llvm.org/D29152
llvm-svn: 293800
This commit reverts "r293518 - [ASTMatchers] Sprinkle some constexpr on the
global matcher constructors" because after it a buildbot that builds clang
stage 2 with modules failed to link clang-reorder-fields.
llvm-svn: 293759
Summary:
Comment reflower was adding untouchable tokens in case two consecutive comment lines are aligned in the source code. This disallows the whitespace manager to re-indent them later.
source:
```
int i = f(abc, // line 1
d, // line 2
// line 3
b);
```
Since line 2 and line 3 are aligned, the reflower was marking line 3 as untouchable; however the three comment lines need to be re-aligned.
output before:
```
int i = f(abc, // line 1
d, // line 2
// line 3
b);
```
output after:
```
int i = f(abc, // line 1
d, // line 2
// line 3
b);
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: sammccall, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29383
llvm-svn: 293755
This rows back on r288120, r291801 and r292110. I apologize in advance
for the churn. All of those revisions where meant to make the wrapping
of RHS expressions more consistent. However, now that they are
consistent, we seem to be a bit too eager.
The reasoning here is that I think it is generally correct that we want
to line-wrap before multiline RHS expressions (or multiline arguments to
a function call). However, if there are only two of such operands or
arguments, there is always a clear vertical separation between them and
the additional line break seems much less desirable.
Somewhat good examples are expressions like:
EXPECT_EQ(2, someLongExpression(
orCall));
llvm-svn: 293752
Added doxygen comments to prfchwintrin.h's intrinsics.
Note: The doxygen comments are automatically generated based on Sony's intrinsic
s document.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.
llvm-svn: 293745
Contrary to the comment, DeclContext intends to guarantee that the lookup
results for a particular name will be stable across non-AST-mutating
operations, so a copy here should not be necessary. Further, if a copy *is*
necessary, the other four instances of this pattern within this file would also
be wrong, and we have no evidence of any problems with them; if this change
unearths problems, we should fix all the instances of this pattern.
llvm-svn: 293740
clang-cl would evaluate the arguments right-to-left (see PR), and for
non-Windows targets I suppose we only got it because we were already
emitting left-to-right in CodeGenFunction::EmitCallArgs.
Differential Revision: https://reviews.llvm.org/D29350
llvm-svn: 293732
The Module::WithCodegen flag was only being set when the module was
parsed from a ModuleMap. Instead set it late, in the ASTWriter to match
the layer where the MODULAR_CODEGEN_DECLs list is determined (the
WithCodegen flag essentially means "are this module's decls in
MODULAR_CODEGEN_DECLs").
When simultaneous emission of AST file and modular object is implemented
this may need to change - the Module::WithCodegen flag will need to be
set earlier, and ideally the MODULAR_CODEGEN_DECLs gathering will
consult this flag (that's not possible right now since Decls destined
for an AST File don't have a Module - only if they're /read/ from a
Module is that true - I expect that would need to change as well).
llvm-svn: 293692
FindInstantiatedDecl or passing it to RebuildMemberExpr.
This fixes PR30361.
rdar://problem/17341274
Differential Revision: https://reviews.llvm.org/D24969
llvm-svn: 293678
My original warning was very conservative and I never revisited the
heuristics that were used.
This would have caught http://crbug.com/687251 at compile time.
llvm-svn: 293677
In Windows, when the sanitizer is implemented as a static library, we use
auxiliary static library dll_thunk that will be linked to the dlls that have
instrumentation, so they can refer to the runtime in the main executable.
It uses interception to get a pointer the function in the main executable and
override its function with that pointer.
Because of that, we need to ensure that the main executable exports all the
sanitizers' interface, otherwise the initialization in dll_thunk will fail.
In this commit we add the flag -wholearchive to clang driver to ensure that
the linker does not omit any object files from asan library.
Differential Revision: https://reviews.llvm.org/D29334
llvm-svn: 293668
Summary:
The reflower didn't measure precisely the line column of a line in the middle of
a line comment section that has a prefix that needs to be adapted.
source:
```
/// a
//b
```
format before:
```
/// a
//b
```
format after:
```
/// a
// b
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: sammccall, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29329
llvm-svn: 293641
This only affects expressions inside ${} scopes of template strings.
Here, we want to indent relative to the surrounding template string and
not the surrounding expression. Otherwise, this can create quite a mess.
Before:
var f = `
aaaaaaaaaaaaaaaaaa: ${someFunction(
aaaaa + //
bbbb)}`;
After:
var f = `
aaaaaaaaaaaaaaaaaa: ${someFunction(
aaaaa + //
bbbb)}`;
llvm-svn: 293636
Summary:
The reflower was not taking into account the additional leading whitespace in block comment lines.
source:
```
{
/*
* long long long long
* long
* long long long long
*/
}
```
format (with column limit 20) before:
```
{
/*
* long long long
* long long long long
* long long
*/
}
```
format after:
```
{
/*
* long long long
* long long long
* long long long
*/
}
```
Reviewers: djasper, klimek
Reviewed By: djasper
Subscribers: cfe-commits, sammccall, klimek
Differential Revision: https://reviews.llvm.org/D29326
llvm-svn: 293633
Include a path hint for find_package() in ClangConfig.cmake to ensure
that CMake prefers LLVM installed alongside clang over the default
search path.
If two versions of LLVM are installed in the system, and one of them is
in PATH, CMake's find_package() magic prefers the CMake directory
alongside that install by default. Adding a relative hint makes it
possible to prioritize to the install from which find_package() is
called.
If you want to build e.g. LLDB against another install of LLVM, you can
pass LLVM_CONFIG override. In this case, LLDB queries the prefix from
llvm-config and uses the CMake files located there. However, when
including ClangConfig, the implicit find_package() nevertheless prefers
PATH-found LLVM over the one used previously by LLDB, and two versions
of LLVMConfig end up being loaded.
This could be fixed on LLDB end up by explicitly forcing custom package
search location. However, it seems simpler and safer to add a hint to
ClangConfig than to track every usage of ClangConfig.
Differential Revision: https://reviews.llvm.org/D29304
llvm-svn: 293632
Summary:
This fixes a regression that causes example:
```
enum A {
a, // line a
// line b
b
};
```
to be formatted as follows:
```
enum A {
a, // line a
// line b
b
};
```
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: cfe-commits, sammccall, djasper, klimek
Differential Revision: https://reviews.llvm.org/D29322
llvm-svn: 293624
Before:
var f = `aaaaaaaaaaaaa:${aaaaaaa
.aaaaa} aaaaaaaa
aaaaaaaaaaaaa:${aaaaaaa.aaaaa} aaaaaaaa`;
After:
var f = `aaaaaaaaaaaaa:${aaaaaaa.aaaaa} aaaaaaaa
aaaaaaaaaaaaa:${aaaaaaa.aaaaa} aaaaaaaa`;
llvm-svn: 293622
Summary:
This patch stops reflowing comment lines starting with '@', since they commonly
have a special meaning.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29323
llvm-svn: 293617
The main motivation behind this is to cleanup the WhitespaceManager and
make it more extensible for future alignment etc. features.
Specifically, WhitespaceManager has started to copy more and more code
that is already present in FormatToken. Instead, I think it makes more
sense to actually store a reference to each FormatToken for each change.
This has as a consequence led to a change in the calculation of indent
levels. Now, we actually compute them for each Token ahead of time,
which should be more efficient as it removes an unsigned value for the
ParenState, which is used during the combinatorial exploration of the
solution space.
No functional changes intended.
Review: https://reviews.llvm.org/D29300
llvm-svn: 293616
We're seeing what we believe are false positives. (It's hard to tell with the
available diagnostics, and I'm not sure how to reduce them yet).
I'll send Richard reproduction details offline.
djasper/chandlerc suggested this should be a warning for now, to make rolling it
out feasible.
llvm-svn: 293611
Summary:
In VirtualCallChecker, handle indirect calls.
getDirectCallee() can be nullptr, and dyn_cast(nullptr) is UB
Reviewers: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D29303
llvm-svn: 293604
This fixes an assertion failure that occurs later in the function when
an ObjCEncodeExpr is cast to StringLiteral.
rdar://problem/30111207
llvm-svn: 293596
Don't try to map an APSInt addend to an int64_t in pointer arithmetic before
bounds-checking it. This gives more consistent behavior (outside C++11, we
consistently use 2s complement semantics for both pointer and integer overflow
in constant expressions) and fixes some cases where in C++11 we would fail to
properly check for out-of-bounds pointer arithmetic (if the 2s complement
64-bit overflow landed us back in-bounds).
In passing, also fix some cases where we'd perform possibly-overflowing
arithmetic on CharUnits (which have a signed underlying type) during constant
expression evaluation.
llvm-svn: 293595
When objects are imported for modules, there is a chance that a name collision
will cause an ODR violation. Previously, only a small number of such
violations were detected. This patch provides a stronger check based on
AST nodes.
The information needed to uniquely identify an object is taked from the AST and
put into a one-dimensional byte stream. This stream is then hashed to give
a value to represent the object, which is stored with the other object data
in the module.
When modules are loaded, and Decl's are merged, the hash values of the two
Decl's are compared. Only Decl's with matched hash values will be merged.
Mismatch hashes will generate a module error, and if possible, point to the
first difference between the two objects.
The transform from AST to byte stream is a modified depth first algorithm.
Due to references between some AST nodes, a pure depth first algorithm could
generate loops. For Stmt nodes, a straight depth first processing occurs.
For Type and Decl nodes, they are replaced with an index number and only on
first visit will these nodes be processed. As an optimization, boolean
values are saved and stored together in reverse order at the end of the
byte stream to lower the ammount of data that needs to be hashed.
Compile time impact was measured at 1.5-2.0% during module building, and
negligible during builds without module building.
Differential Revision: https://reviews.llvm.org/D21675
llvm-svn: 293585
This re-applies r293343 (reverts commit r293475) with a fix for an
assertion failure caused by a missing integer cast. I tested this patch
by using the built compiler to compile X86FastISel.cpp.o with ubsan.
Original commit message:
Ubsan does not report UB shifts in some cases where the shift exponent
needs to be truncated to match the type of the shift base. We perform a
range check on the truncated shift amount, leading to false negatives.
Fix the issue (PR27271) by performing the range check on the original
shift amount.
Differential Revision: https://reviews.llvm.org/D29234
llvm-svn: 293572
This fixes various ways to tickle an assertion in constant expression
evaluation when using __int128. Longer term, we need to figure out what should
happen here: either any kind of overflow in offset calculation should result in
a non-constant value or we should truncate to 64 bits. In C++11 onwards, we're
effectively already checking for overflow because we strictly enforce array
bounds checks, but even there some forms of overflow can slip past undetected.
llvm-svn: 293568
Just a small clean up noticed when doing post-commit review of Duncan's
previous change for ModuleFile memory ownership semantics. NFC.
llvm-svn: 293556
Summary:
Consider formatting the following code fragment with column limit 20:
```
{
// line 1
// line 2\
// long long long line
}
```
Before this fix the output is:
```
{
// line 1
// line 2\
// long long
long line
}
```
This patch fixes a regression that breaks the last comment line without
adding the '//' prefix.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29298
llvm-svn: 293548
Summary:
The following two comment lines form a single comment section:
```
if (1) { // line 1
// line 2
}
```
This is because the break of a comment section was based on the original column
of the first token of the previous line (in this case, the 'if').
This patch splits these two comment lines into different sections by taking into
account the original column of the right brace preceding the first line comment
where applicable.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29291
llvm-svn: 293539
This had significant negative consequences and I don't have a good
solution for it yet.
Before:
var string =
[
'aaaaaa',
'bbbbbb',
]
.join('+');
After:
var string = [
'aaaaaa',
'bbbbbb',
].join('+');
llvm-svn: 293465
Accounts for a case that caused an assertion failure by attempting to
query for the vtable linkage of a non-dynamic type.t
This reverts commit r292801.
llvm-svn: 293462
First pass at generating weak definitions of inline functions from module files
(& skipping (-O0) or emitting available_externally (optimizations)
definitions where those modules are used).
External functions defined in modules are emitted into the modular
object file as well (this may turn an existing ODR violation (if that
module were imported into multiple translations) into valid/linkable
code).
Internal symbols (static functions, for example) are not correctly
supported yet. The symbol will be produced, internal, in the modular
object - unreferenceable from the users.
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D28845
llvm-svn: 293456
Support for CUDA printf is exploited to support printf for
an NVPTX OpenMP device.
To reflect the support of both programming models, the file
CGCUDABuiltin.cpp has been renamed to CGGPUBuiltin.cpp, and
the call EmitCUDADevicePrintfCallExpr has been renamed to
EmitGPUDevicePrintfCallExpr.
Reviewers: jlebar
Differential Revision: https://reviews.llvm.org/D17890
llvm-svn: 293444
I modify clang driver for windows to include:
"-wholearchive:asan_dynamic_runtime_thunk", so all object files in the
static library: asan_dynamic_runtime_thunk are considered by the linker.
This is necessary, because some object files only include linker pragmas,
and doesn't resolve any symbol. If we don't include that flag, the
linker will ignore them, and won't read the linker pragmas.
Differential Revision: https://reviews.llvm.org/D29159
llvm-svn: 293420
Oops... r293393 started calling ReadSignature in
ModuleManager::addModule even when there was no ExpectedSignature.
Whether or not this would have a measurable performance impact (I
spotted this by inspection, and ReadSignature should be fairly fast), we
might as well get what we can. Add an extra check against
ExpectedSignature to avoid the hit.
llvm-svn: 293415
Zero-initialize ModuleFile members directly in the class definition, and
move the (now uninteresting) constructor into the class definition.
There were a few members that weren't being initialized at all. I
zero-initialized them for consistency, but it's likely that they were
somehow initialized before their first use; i.e., there's likely no
functionality change here.
llvm-svn: 293404
Invert the main branch in ModuleManager::addModule to return early and
reduce indentation, and clean up a bunch of logic as a result. I split
out a function called updateModuleImports to avoid triggering code
duplication.
llvm-svn: 293400
I don't have a testcase for this (and I'm not sure if it's an observable
bug), but it seems obviously wrong that ModuleManager::removeModules is
failing to clean up deleted modules from ModuleFile::Imports. See the
code in ModuleManager::addModule that inserts into ModuleFile::Imports;
we need the inverse operation.
llvm-svn: 293399
ModuleManager::removeModules always deletes a tail of the
ModuleManager::Chain. Change the API to enforce that so that we can
simplify the code inside.
There's no real functionality change, although there's a slight
performance hack to loop to the First deleted module instead of the
final module in the chain (skipping the about-to-be-deleted tail).
Also document something suspicious: we fail to clean deleted modules out
of ModuleFile::Imports.
llvm-svn: 293398
Hide the pointer indirection in ModuleManager::begin, ModuleManager::end,
ModuleManager::rbegin, and ModuleManager::rend. Besides tidying up the call
sites, this is preparation for making ownership of ModuleFile explicit.
llvm-svn: 293394
The main point is to move the delete-the-new-module logic into the same block
that creates it, so I can simplify the memory management in a follow-up, but I
think it's clearer to use use a checkSignature helper here anyway.
There is a minor functionality change: we now scan ahead to pull the signature
out of the control block *only* if this is a new ModuleFile. For old ones,
ASTReader::ReadControlBlock will have already read the signature.
llvm-svn: 293393
r293360 broke some ARM bots, because size_t on those targets is
apparently `unsigned int`, not `unsigned long`. `sizeof(whatever)`
should to give us a `size_t`, so we can just use the type of that
instead.
llvm-svn: 293369
non-template function instantiated from a friend declaration in a class
template from TSK_ImplicitInstantiation to TSK_Undeclared.
It doesn't make sense for a non-template function to be flagged as being
instantiated from a template; that property really belongs to the entity
as a whole and not an individual declaration of it. There's some history
here:
* r137934 started marking these functions as instantiations in order to
work around an issue where we might instantiate a class template while
we're still parsing its member definitions, and would otherwise fail
to instantiate the friend definition
* r177003 fixed the same issue but for friend templates, but did so by
making the friends claim to be definitions even before we'd parsed
their actual bodies; this made the r137934 change redundant
* r293558 worked around a problem caused by the marking of a non-template
function as a template instantiation in r137934
This change reverts the code changes from r293358 and r137934 and retains
all the tests.
llvm-svn: 293367
This patch changes how we handle argument-dependent `diagnose_if`
attributes. In particular, we now check them in the same place that we
check for things like passing NULL to Nonnull args, etc. This is
basically better in every way than how we were handling them before. :)
This fixes PR31638, PR31639, and PR31640.
Differential Revision: https://reviews.llvm.org/D28889
llvm-svn: 293360
As Mehdi put it, entities should either be
available_externally+weak_odr, or linkonce_odr+linkonce_odr. While some
functions are emitted a_e/weak, their local variables were emitted
a_e/linkonce_odr.
While it might be nice to emit them a_e/weak, the Itanium ABI (& best
guess at MSVC's behavior as well) requires the local to be
linkonce/linkonce.
Reviewers: rsmith, mehdi_amini
Differential Revision: https://reviews.llvm.org/D29233
llvm-svn: 293344
Ubsan does not report UB shifts in some cases where the shift exponent
needs to be truncated to match the type of the shift base. We perform a
range check on the truncated shift amount, leading to false negatives.
Fix the issue (PR27271) by performing the range check on the original
shift amount.
Differential Revision: https://reviews.llvm.org/D29234
llvm-svn: 293343
In r279546 I disabled all frame pointer elimination at the front-end on
ARM-Darwin (and warned about it) because before that the backend had been
silently ignoring these options. It turns out we didn't ignore
-momit-leaf-frame-pointer though, just the more general -fomit-frame-pointer.
So this re-enables passing that down to CodeGen so that everything really does
continue working as before (with better diagnostics).
llvm-svn: 293311
Both on Mac and Windows, it's common to have a 'Users' directory in the
root of the filesystem, so one might specify a filename as
'/Users/me/myfile.c'. clang-cl (as well as MSVC's cl.exe) will interpret
that as invoking the '/U' option, which is probably not what the user
wanted. Add a warning about this.
Differential Revision: https://reviews.llvm.org/D29198
llvm-svn: 293305
Modify ObjC blocks impl wrt address spaces as follows:
- keep default private address space for blocks generated
as local variables (with captures);
- add global address space for global block literals (no captures);
- make the block invoke function and enqueue_kernel prototype with
the generic AS block pointer parameter to accommodate both
private and global AS cases from above;
- add block handling into default AS because it's implemented as
a special pointer type (BlockPointer) in the frontend and therefore
it is used as a pointer everywhere. This is also needed to accommodate
both private and global AS blocks for the two cases above.
- removes ObjC RT specific symbols (NSConcreteStackBlock and
NSConcreteGlobalBlock) in the OpenCL mode.
Review: https://reviews.llvm.org/D28814
llvm-svn: 293286
The patch teaches the Clang driver how to handle the N64 static
relocation model properly. It enforces the correct target feature
(+noabicalls) when -fno-pic is used. This is required as non-pic
N64 code as the abi extension to call PIC code (CPIC) is unsupported.
Make PIC the default for mips64 and mips64el, this affects both N32
& N64 ABIs, to better match GCC.
As part of this effort, clean up the assembler invocation command
builder, so the correct flags are used.
This and r293279 in LLVM resolves PR/23485.
Thanks to Brooks Davis for reporting the issue!
Reviewers: slthakur, seanbruno
Differential Revision: https://reviews.llvm.org/D29031
llvm-svn: 293285
Function call can appear in the arguments of another function call, eg.:
foo(bar());
This patch adds support for such cases.
Patch by Ivan Sidorenko!
Differential revision: https://reviews.llvm.org/D28905
llvm-svn: 293280
Summary:
The MPEG transport stream file format also uses ".ts" as its file extension.
This change detects its specific framing format (0x47 every 189 bytes) and
simply ignores MPEG TS files.
Reviewers: djasper, sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D29186
llvm-svn: 293270
another declaration, ensure we actually serialize / deserialize that
declaration.
Before this patch, if another copy of the typedef were merged with the parsed
version, we would emit type information referring to the merged version and
consequently emit nothing about the parsed anonymous struct. This resulted in
us losing information, particularly the visible merged module set for the
parsed definition. Force that information to be emitted and to be loaded when
the typedef is used.
llvm-svn: 293219
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
llvm-svn: 293207
Turning on the warning by default helps the users as it's a common
mistake to capture out-parameters in a block without ensuring the object
assigned doesn't get released.
rdar://problem/30200058
llvm-svn: 293199
even in the presence of nullability qualifiers.
This commit fixes bugs in r285031 where -Wblock-capture-autoreleasing
wouldn't issue warnings when the function parameters were annotated
with nullability qualifiers. Specifically, look through the sugar and
see if there is an AttributedType of kind attr_objc_ownership to
determine whether __autoreleasing was explicitly specified or implicitly
added by the compiler.
rdar://problem/30193488
llvm-svn: 293194
This is a simple patch to teach OpenMP codegen to emit the construct
in Generic mode.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29143
llvm-svn: 293183
The handler that deals with IR passed/missed/analysis remarks is extended to
also handle the corresponding MIR remarks.
The more thorough testing in done via llc (rL293113, rL293121). Here we just
make sure that the functionality is accessible through clang.
llvm-svn: 293146
Instead of using the location of the beginning '-'/'+'.
This is consistent with location used for function decls and ObjC method calls where we use the base name as the location as well.
llvm-svn: 293134
Rather than storing a single flat list of SourceLocations where the diagnostic
state changes (in source order), we now store a separate list for each FileID
in which there is a diagnostic state transition. (State for other files is
built and cached lazily, on demand.) This has two consequences:
1) We can now sensibly support modules, and properly track the diagnostic state
for modular headers (this matters when, for instance, triggering instantiation
of a template defined within a module triggers diagnostics).
2) It's much faster than the old approach, since we can now just do a binary
search on the offsets within the FileID rather than needing to call
isBeforeInTranslationUnit to determine source order (which is surprisingly
slow). For some pathological (but real world) files, this reduces total
compilation time by more than 10%.
For now, the diagnostic state points for modules are loaded eagerly. It seems
feasible to defer this until diagnostic state information for one of the
module's files is needed, but that's not part of this patch.
llvm-svn: 293123
in the current lexical scope.
clang currently emits the lifetime.start marker of a variable when the
variable comes into scope even though a variable's lifetime starts at
the entry of the block with which it is associated, according to the C
standard. This normally doesn't cause any problems, but in the rare case
where a goto jumps backwards past the variable declaration to an earlier
point in the block (see the test case added to lifetime2.c), it can
cause mis-compilation.
To prevent such mis-compiles, this commit conservatively disables
emitting lifetime variables when a label has been seen in the current
block.
This problem was discussed on cfe-dev here:
http://lists.llvm.org/pipermail/cfe-dev/2016-July/050066.html
rdar://problem/30153946
Differential Revision: https://reviews.llvm.org/D27680
llvm-svn: 293106
Summary:
Now when you ask clang to link in a bitcode module, you can tell it to
set attributes on that module's functions to match what we would have
set if we'd emitted those functions ourselves.
This is particularly important for fast-math attributes in CUDA
compilations.
Each CUDA compilation links in libdevice, a bitcode library provided by
nvidia as part of the CUDA distribution. Without this patch, if we have
a user-function F that is compiled with -ffast-math that calls a
function G from libdevice, F will have the unsafe-fp-math=true (etc.)
attributes, but G will have no attributes.
Since F calls G, the inliner will merge G's attributes into F's. It
considers the lack of an unsafe-fp-math=true attribute on G to be
tantamount to unsafe-fp-math=false, so it "merges" these by setting
unsafe-fp-math=false on F.
This then continues up the call graph, until every function that
(transitively) calls something in libdevice gets unsafe-fp-math=false
set, thus disabling fastmath in almost all CUDA code.
Reviewers: echristo
Subscribers: hfinkel, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D28538
llvm-svn: 293097
This patch adds support for the proc_bind clause on the Spmd construct
'target parallel' on the NVPTX device. Since the parallel region is created
upon kernel launch, this clause can be safely ignored on the NVPTX device at
codegen time for level 0 parallelism.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29128
llvm-svn: 293069
Summary:
This presents a version of the comment reflowing with less mutable state inside
the comment breakable token subclasses. The state has been pushed into the
driving breakProtrudingToken method. For this, the API of BreakableToken is enriched
by the methods getSplitBefore and getLineLengthAfterSplitBefore.
Reviewers: klimek
Reviewed By: klimek
Subscribers: djasper, klimek, mgorny, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D28764
llvm-svn: 293055
Use the new llvm_canonicalize_cmake_booleans() function to canonicalize
booleans for lit tests. Replace the duplicate ENABLE_CLANG* variables
used to hold canonicalized values with in-place canonicalization. Use
implicit logic in Python code to avoid overrelying on exact 0/1 values.
Differential Revision: https://reviews.llvm.org/D28529
llvm-svn: 293052
Summary: This enables the test to run on systems where output cannot be written.
Reviewers: compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D29123
llvm-svn: 293051
Prior to OpenCL 2.0, image3d_t can only be used with the write_only
access qualifier when the cl_khr_3d_image_writes extension is enabled,
see e.g. OpenCL 1.1 s6.8b.
Require the extension for write_only image3d_t types and guard uses of
write_only image3d_t in the OpenCL header.
Patch by Sven van Haastregt!
Review: https://reviews.llvm.org/D28860
llvm-svn: 293050
The thread_limit-clause on the combined directive applies to the
'teams' region of this construct. We modify the ThreadLimitClause
class to capture the clause expression within the 'target' region.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29087
llvm-svn: 293049
The num_teams-clause on the combined directive applies to the
'teams' region of this construct. We modify the NumTeamsClause
class to capture the clause expression within the 'target' region.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29085
llvm-svn: 293048
This is an attempt to avoid new false positives caused by the reverted r292800,
however the scope of the fix is significantly reduced - some variables are still
in incorrect memory spaces.
Relevant test cases added.
rdar://problem/30105546
rdar://problem/30156693
Differential revision: https://reviews.llvm.org/D28946
llvm-svn: 293043
This reverts commit r293004 because it broke the buildbots with "unknown CPU"
errors. I tried to fix it in r293026, but that broke on Green Dragon with this
kind of error:
error: expected string not found in input
// CHECK: l{{ +}}df{{ +}}*ABS*{{ +}}{{0+}}{{.+}}preprocessed-input.c{{$}}
^
<stdin>:2:1: note: scanning from here
/Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o: file format Mach-O 64-bit x86-64
^
<stdin>:2:67: note: possible intended match here
/Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o: file format Mach-O 64-bit x86-64
I suppose this means that llvm-objdump doesn't support Mach-O, so the test
should indeed check for linux (but not for x86). I'll leave it to someone that
knows better.
llvm-svn: 293032
This test broke on a lot of non-x86 buildbots with "unknowm CPU" errors. I don't
see anything platform-specific about this test, and it seems to work fine on ARM
if we just remove the -triple i686 flags from the run line.
llvm-svn: 293026
Sometime clang would be supplied -fobjc-arc -f(no)objc-arc-exceptions
and then later disable ARC with -fno-objc-arc, which only negate first
option, but not the latter, resulting usused argument warning. Silence
this warning only when -fno-objc-arc option is present.
Patch by Onha Choe!
llvm-svn: 293014
This patch adds support for codegen of 'target teams' on the host.
This combined directive has two captured statements, one for the
'teams' region, and the other for the 'parallel'.
This target teams region is offloaded using the __tgt_target_teams()
call. The patch sets the number of teams as an argument to
this call.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29084
llvm-svn: 293005
Summary:
Clang appears to always use name as specified on the command
line, whereas gcc uses the name as specified in the linemarker at the
first line when compiling a preprocessed source. This results mismatch
between two compilers in FILE symbol table entry. This patch makes clang
to resemble gcc's behavior in finding the original source file name and
use it as an input file name.
Even with this patch, values of FILE symbol table entry may still be
different because clang uses dirname+basename for the entry whlie gcc
uses basename only. I'll write a patch for that once this patch is
committed.
Reviewers: dblaikie, inglorion
Reviewed By: inglorion
Subscribers: inglorion, aprantl, bruno
Differential Revision: https://reviews.llvm.org/D28796
llvm-svn: 293004
This patch adds support for codegen of 'target teams' on the host.
This combined directive has two captured statements, one for the
'teams' region, and the other for the 'parallel'.
This target teams region is offloaded using the __tgt_target_teams()
call. The patch sets the number of teams as an argument to
this call.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29084
llvm-svn: 293001
This patch adds support for the Spmd construct 'target parallel' on the
NVPTX device. This involves ignoring the num_threads clause on the device
since the number of threads in this combined construct is already set on
the host through the call to __tgt_target_teams().
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29083
llvm-svn: 292999
The num_threads-clause on the combined directive applies to the
'parallel' region of this construct. We modify the NumThreadsClause
class to capture the clause expression within the 'target' region.
The offload runtime call for 'target parallel' is changed to
__tgt_target_teams() with 1 team and the number of threads set by
this clause or a default if none.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29082
llvm-svn: 292997
Summary: These accessors maps directly to the command line option.
Reviewers: steven_wu
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D29065
llvm-svn: 292960
methods from protocols and categories as well
Code completion results for class methods already include instance methods
from Objective-C root classes. This commit ensures that the results also include
instance methods from protocols that the root class implements and root class
categories as well.
rdar://28012953
Differential Revision: https://reviews.llvm.org/D27257
llvm-svn: 292932
This reverts commit r292800.
It is causing null pointer dereference false positives when a block that
captures a static local is evaluated at the top level.
llvm-svn: 292874
Summary:
This patch changes TableGen-generated code in AttrPCHRead to call functions on
ASTRecordReader, instead of passing separate parameters to ASTReader. This is a
follow-up to r290217.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28007
llvm-svn: 292868
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LF_". (Unfortunately, a scoped enum is not sufficient to override macros.)
These changes are for clang. See https://reviews.llvm.org/D28476 for LLVM.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28477
llvm-svn: 292849
Summary:
This patch changes the layout of DoubleAPFloat, and adjust all
operations to do either:
1) (IEEEdouble, IEEEdouble) -> (uint64_t, uint64_t) -> PPCDoubleDoubleImpl,
then run the old algorithm.
2) Do the right thing directly.
1) includes multiply, divide, remainder, mod, fusedMultiplyAdd, roundToIntegral,
convertFromString, next, convertToInteger, convertFromAPInt,
convertFromSignExtendedInteger, convertFromZeroExtendedInteger,
convertToHexString, toString, getExactInverse.
2) includes makeZero, makeLargest, makeSmallest, makeSmallestNormalized,
compare, bitwiseIsEqual, bitcastToAPInt, isDenormal, isSmallest,
isLargest, isInteger, ilogb, scalbn, frexp, hash_value, Profile.
I could split this into two patches, e.g. use
1) for all operatoins first, then incrementally change some of them to
2). I didn't do that, because 1) involves code that converts data between
PPCDoubleDoubleImpl and (IEEEdouble, IEEEdouble) back and forth, and may
pessimize the compiler. Instead, I find easy functions and use
approach 2) for them directly.
Next step is to implement move multiply and divide from 1) to 2). I don't
have plans for other functions in 1).
Differential Revision: https://reviews.llvm.org/D27872
llvm-svn: 292839
Vassil Vassilev