In addition to the formal linkage rules, the Modules TS includes cases where
internal-linkage symbols within a module interface unit can be referenced from
outside the module via exported inline functions / templates. We give such
declarations "module-internal linkage", which is formally internal linkage, but
results in an externally-visible symbol.
llvm-svn: 307434
requirements in protocol/class/category declarations
The unguarded availability warnings in the protocol requirements of a protocol
/class/category declaration can be avoided. This matches the behaviour of
Swift's diagnostics. The warnings for deprecated/unavailable protocols are
preserved.
rdar://33156429
Differential Revision: https://reviews.llvm.org/D35061
llvm-svn: 307368
Summary:
Most clang tools should ignore the -M
family of options because one wouldn't want them
to generate a new dependency (.d) file. However,
some tools may want this dependency file. This
patch creates a mechanism for them to do this.
This implementation just plumbs a boolean down
several layers of calls. Each of the modified calls
has several call sites, and so a single member
variable or new API entry point won't work.
An alternative would be to write a function to filter
the -M family of arguments out of CC1Args, and have
each caller call that function by hand before calling
newInvocation, Invocation::run, or buildAstFromCodeWithArgs.
This is a more complicated and error-prone solution.
Why burden all the callers to remember to use
this function?
But I could rewrite this patch to use that method if
that is deemed more appropriate.
Reviewers: klimek
Reviewed By: klimek
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34304
llvm-svn: 307315
problems in testing, see comments in D34161 for some more details.
A fix is in progres in D35011, but a revert seems better now as the fix will
probably take some more time to land.
llvm-svn: 307277
Summary: Pass the type of the device offloading when building the tool chain for a particular target architecture. This is required when supporting multiple tool chains that target a single device type. In our particular use case, the OpenMP and CUDA tool chains will use the same ```addClangTargetOptions ``` method. This enables the reuse of common options and ensures control over options only supported by a particular tool chain.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar, Hahnfeld
Reviewed By: hfinkel
Subscribers: jgravelle-google, aheejin, rengolin, jfb, dschuff, sbc100, cfe-commits
Differential Revision: https://reviews.llvm.org/D29647
llvm-svn: 307272
When enable_if disables a particular overload resolution candidate,
rummage through the enable_if condition to find the specific condition
that caused the failure. For example, if we have something like:
template<
typename Iter,
typename = std::enable_if_t<Random_access_iterator<Iter> &&
Comparable<Iterator_value_type<Iter>>>>
void mysort(Iter first, Iter last) {}
and we call "mysort" with "std::list<int>" iterators, we'll get a
diagnostic saying that the "Random_access_iterator<Iter>" requirement
failed. If we call "mysort" with
"std::vector<something_not_comparable>", we'll get a diagnostic saying
that the "Comparable<...>" requirement failed.
llvm-svn: 307196
These cases occur frequently for declarations in the global module (above the
module-declaration) in a Modules TS module interface. When we merge a
definition from another module into such a module-private definition, ensure
that we transitively make everything lexically within that definition visible
to that translation unit.
llvm-svn: 307129
-fslp-vectorize-aggressive and -fno-slp-vectorize-aggressive flags back
under this group and test for the warning. Document the future removal
in the ReleaseNotes.
Differential Revision: https://reviews.llvm.org/D34926
llvm-svn: 306965
Summary:
Changed EABIVersion type from string to llvm::EABI.
It seems it was just a typo and this is intended implementation.
Differential Revision: https://reviews.llvm.org/D34595
llvm-svn: 306953
Summary:
Un-revert https://reviews.llvm.org/D34868, but with a slight tweak to the
documentation to fix an error -- I had used the wrong syntax for a link.
llvm-svn: 306948
Summary:
Depends on https://reviews.llvm.org/D34867.
Add a Clang frontend option to enable optimization remark hotness
thresholds, which were added to LLVM in https://reviews.llvm.org/D34867.
This prevents diagnostics that do not meet a minimum hotness
threshold from being output. When generating optimization remarks for large
codebases with a ton of cold code paths, this option can be used
to limit the optimization remark output at a reasonable size.
Discussion of this change can be read here:
http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html
Reviewers: anemet, davidxl, hfinkel
Reviewed By: anemet
Subscribers: fhahn, cfe-commits
Differential Revision: https://reviews.llvm.org/D34868
llvm-svn: 306945
the target is 32-bit.
The following changes are made to the driver since 32-bit apps do not
run on iOS 11 or later:
- If the deployment target is set explicitly, either with a command-line
option or an environment variable, the driver should report an error
if the version is greater than iOS 10.
- In the case where the deployment target is not set explicitly and the
default is inferred from the target triple or SDK version, it should
use a maximum default of iOS 10.99.99.
rdar://problem/32230613
Differential Revision: https://reviews.llvm.org/D34529
llvm-svn: 306922
Allow ODR for ObjC/C in the sense that we won't keep more that
one definition around (merge them). However, ensure the decl
pass the structural compatibility check in C11 6.2.7/1, for that,
reuse the structural equivalence checks used by the ASTImporter.
Few other considerations:
- Create error diagnostics for tag types mismatches and thread
them into the structural equivalence checks.
- Note that by doing this we only support redefinition between types
that are considered "compatible types" by C.
This is mixed approach of the suggestions discussed in
http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html
Differential Revision: https://reviews.llvm.org/D31778
rdar://problem/31909368
llvm-svn: 306918
Redeclaration lookup should never find hidden enumerators in C, because
they do not have linkage (C11 6.2.2/6)
The linkage of an enumerator should be VisibleNoLinkage, and
isHiddenDeclarationVisible should be checking hasExternalFormalLinkage.
This is was reviewed as part of D31778, but splitted into a different
commit for clarity.
rdar://problem/31909368
llvm-svn: 306917
Summary:
This patch introduces a few extra BraceWrapping options, similar to
`SplitEmptyFunction`, to allow merging empty 'record' bodies (e.g.
class, struct, union and namespace):
* SplitEmptyClass
* SplitEmptyStruct
* SplitEmptyUnion
* SplitEmptyNamespace
The `SplitEmptyFunction` option name has also been simplified/
shortened (from `SplitEmptyFunctionBody`).
These options are helpful when the correspond AfterXXX option is
enabled, to allow merging the empty record:
class Foo
{};
In addition, this fixes an unexpected merging of short records, when
the AfterXXXX options are used, which caused to be formatted like
this:
class Foo
{ void Foo(); };
This is now properly formatted as:
class Foo
{
void Foo();
};
Reviewers: djasper, krasimir
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34395
llvm-svn: 306874
This is a more principled version of r303756. That change was both very
brittle about the state of the Diags object going into the driver and
also broke tooling in funny ways.
In particular it prevented tools from capturing diagnostics properly and
made the compilation database logic fail to provide arguments to the
tool, falling back to scanning directories for JSON files.
llvm-svn: 306822
basic block vectorizer. This vectorizer has had no known users for many,
many years and is completely surpassed by the normal
'-fvectorize-slp'-controlled SLP vectorizer in LLVM.
Hal proposed this back in 2014 to no objections:
http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html
While this patch completely removes the flag, Joerg is working on
a patch that will add it back in a way that warns users and ignores the
flag in a clear and well factored way (so that we can keep doing this
going forward).
Differential Revision: https://reviews.llvm.org/D34846
llvm-svn: 306786
We use this when running a preprocessor-only action on an AST file in order to
avoid paying the runtime cost of loading the extra information.
llvm-svn: 306760
improve support for LLVM-style include sorting.
This really is a collection of improvements to the rules for LLVM
include sorting:
- We have gmock headers now, so it adds support for those to one of the
categories.
- LLVM does use 'FooTest.cpp' files to test 'Foo.h' so it adds that
suffix for finding a main header.
- At times the test file's case may not match the header file's case, so
switch to case-insensitive regex matching of header names.
With this set of changes, I can't spot any misbehaviors when re-sorting
all of LLVM's unittest '#include' lines.
Thanks to Eric and Daniel for help testing and refining the patch during
review!
Differential Revision: https://reviews.llvm.org/D33932
llvm-svn: 306759
a c++17 aligned allocation/deallocation function that is unavailable in
the standard library on Apple platforms.
The aligned functions are implemented only in the following versions or
later versions of the OSes, so clang issues diagnostics if the deployment
target being targeted is older than these:
macosx: 10.13
ios: 11.0
tvos: 11.0
watchos: 4.0
The diagnostics are issued whenever the aligned functions are selected
except when the selected function has a definition in the same file.
If there is a user-defined function available somewhere else, option
-Wno-aligned-allocation-unavailable can be used to silence the
diagnostics.
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D34574
llvm-svn: 306722
The first user of this API will be the cross translation unit
functionality of the Static Analyzer which will be committed in a
follow-up patch.
Differential Revision: https://reviews.llvm.org/D34506
llvm-svn: 306648
Summary:
In change 2ba19793512, the ASTReader logic for ObjC interfaces was modified to
preserve the first definition-data read, "merging" later definitions into it
rather than overwriting it (though this "merging" is, in practice, a no-op that
discards the later definition-data).
Unfortunately this change was only made to ObjC interfaces, not protocols; this
means that when (for example) loading a protocol that references an interface,
if both the protocol and interface are multiply defined (as can easily happen
if the same header is read from multiple contexts), an _inconsistent_ pair of
definitions is loaded: first-read for the interface and last-read for the
protocol.
This in turn causes very subtle downstream bugs in the Swift ClangImporter,
which filters the results of name lookups based on the owning module of a
definition; inconsistency between a pair of related definitions causes name
lookup failures at various stages of compilation.
To fix these downstream issues, this change replicates the logic applied to
interfaces in change 2ba19793512, but for ObjC protocols.
rdar://30851899
Reviewers: doug.gregor, rsmith
Reviewed By: doug.gregor
Subscribers: jordan_rose, cfe-commits
Differential Revision: https://reviews.llvm.org/D34741
llvm-svn: 306583
Summary: It used to always call into the RealFileSystem before.
Reviewers: bkramer, krasimir, klimek, bruno
Reviewed By: klimek
Subscribers: bruno, cfe-commits
Differential Revision: https://reviews.llvm.org/D34469
llvm-svn: 306549
Summary: This patch exposes the exception specification type (noexcept,
etc.) of a C++ function through libclang and Python clang.cindex.
Reviewers: rsmith, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: jbcoe, cfe-commits
Differential Revision: https://reviews.llvm.org/D34091
Patch by Andrew Bennieston
llvm-svn: 306483
This patch extends the `overloadable` attribute to allow for one
function with a given name to not be marked with the `overloadable`
attribute. The overload without the `overloadable` attribute will not
have its name mangled.
So, the following code is now legal:
void foo(void) __attribute__((overloadable));
void foo(int);
void foo(float) __attribute__((overloadable));
In addition, this patch fixes a bug where we'd accept code with
`__attribute__((overloadable))` inconsistently applied. In other words,
we used to accept:
void foo(void);
void foo(void) __attribute__((overloadable));
But we will do this no longer, since it defeats the original purpose of
requiring `__attribute__((overloadable))` on all redeclarations of a
function.
This breakage seems to not be an issue in practice, since the only code
I could find that had this pattern often looked like:
void foo(void);
void foo(void) __attribute__((overloadable)) __asm__("foo");
void foo(int) __attribute__((overloadable));
...Which can now be simplified by simply removing the asm label and
overloadable attribute from the redeclaration of `void foo(void);`
Differential Revision: https://reviews.llvm.org/D32332
llvm-svn: 306467
This is a new checker package. It contains checkers that highlight
well-documented implementation-defined behavior. Such checkers are only useful
to developers that intend to write portable code. Code that is only compiled for
a single platform should be allowed to rely on this platform's specific
documented behavior.
rdar://problem/30545046
Differential Revision: https://reviews.llvm.org/D34102
llvm-svn: 306396
This reverts commit r305688 meaning it reintroduces r305684. To repeat:
[NFC] Refactor DiagnosticRenderer to use FullSourceLoc
Move the DiagnosticRenderer and its dependents to using FullSourceLocs
instead of a SourceLocation and SourceManager pointer. The changeset is
rather large but entirely mechanical.
This is step one to allow DiagnosticRenderer to take either
llvm::SMLocs or clang::SourceLocations.
This breaks clang-tidy and clng-query which will be fixed in a commit
soon after.
Patch by Sanne Wouda
Differential Revision: https://reviews.llvm.org/D31709
llvm-svn: 306384
... once each for the syntactic and semantic form. Without this fix, behavior
of the newly added tests would have been
InitListExprIsPreOrderVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderVisitedTwice:
syntactic: 0
semantic: 1
InitListExprIsPreOrderNoQueueVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderNoQueueVisitedTwice:
syntactic: 0
semantic: 2
llvm-svn: 306374
According to the documentation, when encoding a bit-field, GNU runtime
needs its starting position in addition to its type and size.
https://gcc.gnu.org/onlinedocs/gcc/Type-encoding.html
Prior to r297702, the starting position information was not being
encoded, which is incorrect, and after r297702, an assertion started to
fail because an ObjCIvarDecl was being passed to a function expecting a
FieldDecl.
This commit moves LookupFieldBitOffset to ASTContext and uses the
function to encode the starting position of bit-fields.
llvm-svn: 306364
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
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
Add warn_drv_object_size_disabled_O0 to the invalid command line
argument group. This should fix some bot failures:
lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/13241/steps/test/logs/stdio
llvm-svn: 306183
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
(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
Summary:
Add value completion support for options which are defined in
CC1Options.td, because we only handled options in Options.td.
Reviewers: ruiu, v.g.vassilev, teemperor
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34558
llvm-svn: 306127
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
Summary: Style documentation is generated automatically by `docs/tools/dump_format_style.py`. This hasn't been ran for a while.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34457
llvm-svn: 306089
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
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
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
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 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
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
This is patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
In this patch, Options.td was mainly changed in order to add value class
in Options.inc.
llvm-svn: 305805
Produce an error if variables qualified with a local or
a constant address space are not declared in the outermost
scope of a kernel.
Patch by Simon Perretta.
Differential Revision: https://reviews.llvm.org/D34024
llvm-svn: 305798
This is useful for being able to parse the preprocessor directive blocks even if the header, that defined the macro that is checked, hasn't been included.
Differential Revision: https://reviews.llvm.org/D34263
llvm-svn: 305797
Move the DiagnosticRenderer and its dependents to using FullSourceLocs
instead of a SourceLocation and SourceManager pointer. The changeset is
rather large but entirely mechanical.
This is step one to allow DiagnosticRenderer to take either
llvm::SMLocs or clang::SourceLocations.
Patch by Sanne Wouda
Review: https://reviews.llvm.org/D31709
Change-Id: If351a112cdf6718e2d3ef6721b8da9c6376b32dd
llvm-svn: 305684
for preprocessing
r300667 added support for editor placeholder to Clang. That commit didn’t take
into account that users who use Clang for preprocessing only (-E) will get the
"editor placeholder in source file" error when preprocessing their source
(PR33394). This commit ensures that Clang doesn't lex editor placeholders when
running a preprocessor only action.
rdar://32718000
Differential Revision: https://reviews.llvm.org/D34256
llvm-svn: 305576
These VarDecl's are static data members of classes. Since the initializers are
also hashed, this also provides checking for default arguments to methods.
llvm-svn: 305543
correct getNumArguments
StringifiedArguments is allocated (resized) based on the size the
getNumArguments function. However, this function ACTUALLY currently
returns the amount of total UnexpArgTokens which is minimum the same as
the new implementation of getNumMacroArguments, since empty/omitted arguments
result in 1 UnexpArgToken, and included ones at minimum include 2
(1 for the arg itself, 1 for eof).
This patch renames the otherwise unused getNumArguments to be more clear
that it is the number of arguments that the Macro expects, and thus the maximum
number that can be stringified. This patch also replaces the explicit memset
(which results in value instantiation of the new tokens, PLUS clearing the
memory) with brace initialization.
Differential Revision: https://reviews.llvm.org/D32046
llvm-svn: 305425
Add checking for the second parameter of altivec conversion builtin to make sure
it is compile-time constant int.
This patch fixes PR33212: PPC vec_cst useless at -O0
Differential Revision: https://reviews.llvm.org/D34092
llvm-svn: 305401
Summary:
Add CompactNamespaces option, to pack namespace declarations on the
same line (somewhat similar to C++17 nested namespace definition).
With this option, consecutive namespace declarations are kept on the
same line:
namespace foo { namespace bar {
...
}} // namespace foo::bar
Reviewers: krasimir, djasper, klimek
Reviewed By: djasper
Subscribers: kimgr, cfe-commits, klimek
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D32480
llvm-svn: 305384
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
llvm-svn: 305379
Summary:
Currently we build the co_await expressions on the wrong implicit statements of the implicit ranged for; Specifically we build the co_await expression wrapping the range declaration, but it should wrap the begin expression.
This patch fixes co_await on range for.
Reviewers: rsmith, GorNishanov
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34021
llvm-svn: 305363
Summary:
This option supplements the AllowShortFunctionsOnASingleLine flag, to
merge empty function body at the beginning of the line: e.g. when the
function is not short-enough and breaking braces after function.
int f()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33447
llvm-svn: 305272
cc1as does not currently access the "--" version of this flag. At the
very least this needs to be fixed and proper test cases need to be
added.
Simple reproducer:
clang -Wa,--compress-debug-sections /tmp/test.cc
Result:
error: unknown argument: '--compress-debug-sections'
llvm-svn: 305182
These options control the behaviour of the compression of debug info
sections on ELF targets. Our behaviour slightly diverges from the
behaviour of GCC. `-gz` maps to the `-compress-debug-sections` rather
than `-compress-debug-sections=zlib` or
`-compress-debug-sections=zlib-gnu`. This small divergence allows us to
be compatible across versions of binutils (=zlib support was introduced
in 2.26, while earlier versions only support =zlib-gnu). This also
allows users to not have to worry about the version of the assembler
they may be using if they are not using the IAS. Previously, users
would have had to go through the internal option
`-compress-debug-sectionss` and pass that through to the assembler,
which is no longer needed.
llvm-svn: 305165
If specified, when preprocessing, the contents of imported .pcm files will be
included in preprocessed output. The resulting preprocessed file can then be
compiled standalone without the module sources or .pcm files.
llvm-svn: 305116
as part of a compilation.
This is intended for two purposes:
1) Writing self-contained test cases for modules: we can now write a single
source file test that builds some number of module files on the side and
imports them.
2) Debugging / test case reduction. A single-source testcase is much more
amenable to reduction, compared to a VFS tarball or .pcm files.
llvm-svn: 305101
Summary:
If the first parameter of the function is the ImplicitParamDecl, codegen
automatically marks it as an implicit argument with `this` or `self`
pointer. Added internal kind of the ImplicitParamDecl to separate
'this', 'self', 'vtt' and other implicit parameters from other kind of
parameters.
Reviewers: rjmccall, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33735
llvm-svn: 305075
Cache filename - SourceLocation pairs to speed up preamble loading and
global completion. This is especially relevant for windows, where
preamble loading takes a while.
Patch by Ivan Donchevskii!
Differential Revision: http://reviews.llvm.org/D33493
llvm-svn: 305061
No-one was using this, and it's not meaningful in general -- FrontendActions
can be run on inputs that don't have a corresponding source file. The current
frontend input can be obtained by asking the FrontendAction if any future
action actually needs it.
llvm-svn: 305045
This is useful for parsing a single file, as a fast/inaccurate 'mode' that can still provide declarations from the file, like the classes and their methods.
llvm-svn: 305044
This is tied with the LLVM side of the change to expose the debug
information compression types to clang. We now track the compression
type as an enumeration rather than a boolean. We still use the same
value (GNU) that we did previously. This is in preparation to support
passing down the compression type and switch it based on the command
line.
llvm-svn: 305039
Summary:
This allows the clang-query tool to use matchers like
"integerLiteral(equals(32))". For this to work, an overloaded function
is added for each possible parameter type.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D33094
llvm-svn: 305022
Summary:
Needed to support something like "floatLiteral(equals(1.0))". The
parser for floating point numbers is kept simple, so instead of ".1" you
have to use "0.1".
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D33135
llvm-svn: 305021
Summary:
Recognize boolean literals for future extensions ("equals(true)").
Note that a specific VariantValue constructor is added to resolve
ambiguity (like "Value = 5") between unsigned and bool.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D33093
llvm-svn: 305020
This diff fixes printf "fixits" in the case when there is
a wrapping macro and the format string needs multiple replacements.
In the presence of a macro there is an extra logic in EditedSource.cpp
to handle multiple uses of the same macro argument
(see the old comment inside EditedSource::canInsertInOffset)
which was mistriggerred when the argument was used only once
but required multiple adjustments), as a result the "fixit"
was breaking down the format string
by dropping the second format specifier, i.e.
Log1("test 4: %s %s", getNSInteger(), getNSInteger())
was getting replaced with
Log1("test 4: %ld ", (long)getNSInteger(), (long)getNSInteger())
(if one removed the macro and used printf directly it would work fine).
In this diff we track the location where the macro argument is used and
(as it was before) the modifications originating from all the locations
except the first one are rejected, but multiple changes are allowed.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D33976
llvm-svn: 305018
The only use in-tree I can find for BuiltinTypes.ResultTy is a single
store to it. We otherwise just recompute what it should be later on (and
sometimes do things like argument conversions in the process of
recomputing it).
Since it's impossible to test if the value stored there is sane, and we
don't use it anyway, we should probably just drop the field.
I'll do a follow-up patch to rename BuiltinTypes.ParamTypes ->
BuiltinParamTypes in a bit. Wanted to keep this patch relatively
minimal.
Thanks to Petr Kudryavtsev for bringing this up!
llvm-svn: 304996
Expose the following functions:
- clang_getTypedefName
- clang_getAddressSpace
Patch by Simon Perretta.
Differential Revision: https://reviews.llvm.org/D33598
llvm-svn: 304978
The test in r304929 broke multiple buildbots as it expected mips target to
be registered and available (which is not necessarily true). Updating the
test with this condition.
Original commit:
[mips] Add runtime options to enable/disable madd.fmt and msub.fmt
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
llvm-svn: 304953
This is not required by the standard (yet), but there seems to be reasonable
support for this being a defect according to CWG discussion, and libstdc++ 7.1
relies on it working.
llvm-svn: 304946
Revert r304929 since the test broke buildbots.
Original commit:
[mips] Add runtime options to enable/disable madd.fmt and msub.fmt
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
llvm-svn: 304935
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D33401
llvm-svn: 304929
RecursiveASTVisitor was not properly recursing through a
SubstTemplateTypeParmTypes, resulting in crashes in pack expansion where we
couldn't always find an unexpanded pack within a pack expansion.
We also have an issue where substitution of deduced template arguments for an
implicit deduction guide creates the "impossible" case of naming a
non-dependent member of the current instantiation, but within a specialization
that is actually instantiated from a different (partial/explicit)
specialization of the template. We resolve this by declaring that constructors
that do so can only be used to deduce specializations of the primary template.
I'm running this past CWG to see if people agree this is the right thing to do.
llvm-svn: 304862
replay the steps taken to create the AST file with the preprocessor-only action
installed to produce preprocessed output.
This can be used to produce the preprocessed text for an existing .pch or .pcm
file.
llvm-svn: 304726
Nullable-to-nonnull checks used to crash when the custom bug visitor was trying
to add its notes to autosynthesized accessors of Objective-C properties.
Now we avoid this, mostly automatically outside of checker control, by
moving the diagnostic to the parent stack frame where the accessor has been
called.
Differential revision: https://reviews.llvm.org/D32437
llvm-svn: 304710
This patch provides a means to specify section-names for global variables,
functions and static variables, using #pragma directives.
This feature is only defined to work sensibly for ELF targets.
One can specify section names as:
#pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText"
One can "unspecify" a section name with empty string e.g.
#pragma clang section bss="" data="" text="" rodata=""
Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner
Differential Revision: https://reviews.llvm.org/D33412
llvm-svn: 304705
Modifies FunctionDecl::isThisDeclarationADefinition so that it covers
all the cases checked by FunctionDecl::isDefined. Implements the latter
method by call to isThisDeclarationADefinition.
This change is a part of the patch D30170.
llvm-svn: 304684
This patch adds support for a `header` declaration in a module map to specify
certain `stat` information (currently, size and mtime) about that header file.
This has two purposes:
- It removes the need to eagerly `stat` every file referenced by a module map.
Instead, we track a list of unresolved header files with each size / mtime
(actually, for simplicity, we track submodules with such headers), and when
attempting to look up a header file based on a `FileEntry`, we check if there
are any unresolved header directives with that `FileEntry`'s size / mtime and
perform deferred `stat`s if so.
- It permits a preprocessed module to be compiled without the original files
being present on disk. The only reason we used to need those files was to get
the `stat` information in order to do header -> module lookups when using the
module. If we're provided with the `stat` information in the preprocessed
module, we can avoid requiring the files to exist.
Unlike most `header` directives, if a `header` directive with `stat`
information has no corresponding on-disk file the enclosing module is *not*
marked unavailable (so that behavior is consistent regardless of whether we've
resolved a header directive, and so that preprocessed modules don't get marked
unavailable). We could actually do this for all `header` directives: the only
reason we mark the module unavailable if headers are missing is to give a
diagnostic slightly earlier (rather than waiting until we actually try to build
the module / load and validate its .pcm file).
Differential Revision: https://reviews.llvm.org/D33703
llvm-svn: 304515
Print "this block declaration is not a prototype" for non-prototype
declarations of blocks instead of "this function declaration ...".
rdar://problem/32461723
Differential Revision: https://reviews.llvm.org/D33739
llvm-svn: 304507
This patch makes it an error to have a mismatch between the enabled
sanitizers in a CU, and in any module being imported into the CU. Only
mismatches between non-modular sanitizers are treated as errors.
This patch also includes non-modular sanitizers in module hashes, in
order to ensure module rebuilds occur when -fsanitize=X is toggled on
and off for non-modular sanitizers, and to cut down on module rebuilds
when the option is toggled for modular sanitizers.
This fixes a longstanding issue with implicit modules and sanitizers,
which Duncan originally diagnosed.
When building with implicit modules it's possible to hit a scenario
where modules are built without -fsanitize=address, and are subsequently
imported into CUs with -fsanitize=address enabled. This causes strange
failures at runtime. The case Duncan found affects libcxx, since its
vector implementation behaves differently when ASan is enabled.
Implicit module builds should "just work" when -fsanitize=X is toggled
on and off across multiple compiler invocations, which is what this
patch does.
Differential Revision: https://reviews.llvm.org/D32724
llvm-svn: 304463
Check pointer arithmetic for overflow.
For some more background on this check, see:
https://wdtz.org/catching-pointer-overflow-bugs.htmlhttps://reviews.llvm.org/D20322
Patch by Will Dietz and John Regehr!
This version of the patch is different from the original in a few ways:
- It introduces the EmitCheckedInBoundsGEP utility which inserts
checks when the pointer overflow check is enabled.
- It does some constant-folding to reduce instrumentation overhead.
- It does not check some GEPs in CGExprCXX. I'm not sure that
inserting checks here, or in CGClass, would catch many bugs.
Possible future directions for this check:
- Introduce CGF.EmitCheckedStructGEP, to detect overflows when
accessing structures.
Testing: Apart from the added lit test, I ran check-llvm and check-clang
with a stage2, ubsan-instrumented clang. Will and John have also done
extensive testing on numerous open source projects.
Differential Revision: https://reviews.llvm.org/D33305
llvm-svn: 304459
Summary:
We can emit vtable definition having inline function
if they are all emitted.
Reviewers: rjmccall, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33437
llvm-svn: 304394
Unlike the GCC-compatible __has_trivial_destructor trait, this one computes the
right answer rather than performing the quirky set of checks described in GCC's
documentation (https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html).
MSVC also has a __has_trivial_destructor trait which is the same as its (and
now Clang's) __is_trivially_destructible trait; we might want to consider
changing the behavior of __has_trivial_destructor if we're targeting an MSVC
platform, but I'm not doing so for now.
While implementing this I found that we were incorrectly rejecting
__is_destructible queries on arrays of unknown bound of incomplete types; that
too is fixed, and I've added similar tests for other traits for good measure.
llvm-svn: 304376
to the original module map.
Also use the path and name of the original module map when emitting that
information into the .pcm file. The upshot of this is that the produced .pcm
file will track information for headers in their original locations (where the
module was preprocessed), not relative to whatever directory the preprocessed
module map was in when it was built.
llvm-svn: 304346
These are already wired up to work in the MSVC toolchain header search
code. However, they were unreachable from clang-cl. A user attempted to
use them in https://bugs.llvm.org/show_bug.cgi?id=33205, so let's expose
them.
llvm-svn: 304345
According to OpenMP 5.0 at least one 'map' or 'use_device_ptr' clause
must be specified for 'target data' construct. Patch adds support for
this feature.
llvm-svn: 304216
A suspended translation unit uses significantly less memory but on the
other side does not support any other calls than
clang_reparseTranslationUnit to resume it or
clang_disposeTranslationUnit to dispose it completely.
This helps IDEs to reduce the memory footprint. The data that is freed
by a call to clang_suspendTranslationUnit will be re-generated on the
next (re)parse anyway. Used with a preamble, this allows pretty fast
resumption of the translation unit for further use (compared to disposal
of the translation unit and a parse from scratch).
Patch by Nikolai Kosjar!
llvm-svn: 304212
Previously, a preamble only included #if blocks (and friends like
ifdef) if there was a corresponding #endif before any declaration or
definition. The problem is that any header file that uses include guards
will not have a preamble generated, which can make code-completion very
slow.
To prevent errors about unbalanced preprocessor conditionals in the
preamble, and unbalanced preprocessor conditionals after a preamble
containing unfinished conditionals, the conditional stack is stored
in the pch file.
This fixes PR26045.
Differential Revision: http://reviews.llvm.org/D15994
llvm-svn: 304207
Summary:
This is the fix for patch https://reviews.llvm.org/D33353
@uweigand, could you please verify that everything will be good on SystemZ?
I added triple spir-unknown-unknown.
Thank you in advance!
Reviewers: uweigand
Reviewed By: uweigand
Subscribers: yaxunl, cfe-commits, bader, Anastasia, uweigand
Differential Revision: https://reviews.llvm.org/D33648
llvm-svn: 304191
This should fix the leaks found by asan buildbot in r304162.
Also don't store a reference to the factory with every map value,
which is the only difference between ImmutableMap and ImmutableMapRef.
llvm-svn: 304170
The analyzer's taint analysis can now reason about structures or arrays
originating from taint sources in which only certain sections are tainted.
In particular, it also benefits modeling functions like read(), which may
read tainted data into a section of a structure, but RegionStore is incapable of
expressing the fact that the rest of the structure remains intact, even if we
try to model read() directly.
Patch by Vlad Tsyrklevich!
Differential revision: https://reviews.llvm.org/D28445
llvm-svn: 304162
The new checker currently contains the very core infrastructure for tracking
the state of iterator-type objects in the analyzer: relating iterators to
their containers, tracking symbolic begin and end iterator values for
containers, and solving simple equality-type constraints over iterators.
A single specific check over this infrastructure is capable of finding usage of
out-of-range iterators in some simple cases.
Patch by Ádám Balogh!
Differential revision: https://reviews.llvm.org/D32592
llvm-svn: 304160
Amongst other, this will help LTO to correctly handle/honor files
compiled with O0, helping debugging failures.
It also seems in line with how we handle other options, like how
-fnoinline adds the appropriate attribute as well.
Differential Revision: https://reviews.llvm.org/D28404
llvm-svn: 304127
Summary:
The expression `await_ready` is required to be contextually convertible to bool and `await_suspend` must be a prvalue of either `void` or `bool`.
This patch adds diagnostics for when those requirements are violated.
It also correctly performs the contextual conversion to bool on the result of `await_ready`
Reviewers: GorNishanov, rsmith
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33625
llvm-svn: 304094
member function" context notes to registering an entry on the context stack.
Also reorder the steps within defining special members to be consistent.
This has a few benefits: if multiple diagnostics are produced while checking
such a member, the note is now attached to the first such diagnostic rather
than the last, this prepares us for persisting these diagnostics between the
point at which we require the implicit instantiation of a template and the
point at which that instantiation is actually performed, and this fixes some
cases where we would fail to produce a full note stack leading back to user
code in the case of such a diagnostic.
The reordering exposed a case where we could recursively attempt to define a
defaulted destructor while we're already defining one (and other such cases
also appear to be possible, with or without this change), so this change also
reuses the "willHaveBody" flag on function declarations to track that we're in
the middle of synthesizing a body for the function and bails out if we try to
define a function that we're already defining.
llvm-svn: 303930
Summary:
According to the PDTS it's perfectly legal to have a promise type that defines neither `return_value` nor `return_void`. However a coroutine that uses such a promise type will almost always have UB, because it can never `co_return`.
This patch changes Clang to diagnose such cases as an error. It also cleans up some of the diagnostic messages relating to member lookup in the promise type.
Reviewers: GorNishanov, rsmith
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33534
llvm-svn: 303868
AVX512_VPOPCNTDQ is a new feature set that was published by Intel.
The patch represents the Clang side of the addition of six intrinsics for two new machine instructions (vpopcntd and vpopcntq).
It also includes the addition of the new feature set.
Differential Revision: https://reviews.llvm.org/D33170
llvm-svn: 303857
Summary:
This patch fixes a number of issues with the analysis warnings emitted when a coroutine may reach the end of the function w/o returning.
* Fix bug where coroutines with `return_value` are incorrectly diagnosed as missing `co_return`'s.
* Rework diagnostic message to no longer say "non-void coroutine", because that implies the coroutine doesn't have a void return type, which it might. In this case a non-void coroutine is one who's promise type does not contain `return_void()`
As a side-effect of this patch, coroutine bodies that contain an invalid coroutine promise objects are marked as invalid.
Reviewers: GorNishanov, rsmith, aaron.ballman, majnemer
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33532
llvm-svn: 303831
Now FixedCompilationDatabase::loadFromCommandLine has no means to report
which error occurred if it fails to create compilation object. This is
a block for implementing D33013, because after that change driver will
refuse to create compilation if command line contains erroneous options.
This change adds additional argument to loadFromCommandLine, which is
assigned error message text if compilation object was not created. This is
the same way as other methods of CompilationDatabase report failure.
Differential Revision: https://reviews.llvm.org/D33272
llvm-svn: 303741
Summary:
This option replaces the BreakConstructorInitializersBeforeComma option with an enum, thus introducing a mode where the colon stays on the same line as constructor declaration:
// When it fits on line:
Constructor() : initializer1(), initializer2() {}
// When it does not fit:
Constructor() :
initializer1(), initializer2()
{}
// When ConstructorInitializerAllOnOneLineOrOnePerLine = true:
Constructor() :
initializer1(),
initializer2()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32479
llvm-svn: 303739
Summary:
This change allows us to add arg1 logging support to functions through
the special case list provided through -fxray-always-instrument=. This
is useful for adding arg1 logging to functions that are either in
headers that users don't have control over (i.e. cannot change the
source) or would rather not do.
It only takes effect when the pattern is matched through the "fun:"
special case, as a category. As in:
fun:*pattern=arg1
Reviewers: pelikan, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33392
llvm-svn: 303719
This is an initial commit to allow using it with constant expressions, a follow-up commit will enable full support for it in ObjC methods.
llvm-svn: 303712
C++14 added user-defined literal support for complex numbers so that you can
write something like "complex<double> val = 2i". However, there is an existing
GNU extension supporting this syntax and interpreting the result as a _Complex
type.
This changes parsing so that such literals are interpreted in terms of C++14's
operators if an overload is present but otherwise falls back to the original
GNU extension.
llvm-svn: 303694
Summary:
This is a first patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
Simple flag completion and path completion is available in this patch.
Reviewers: teemperor, v.g.vassilev, ruiu, Bigcheese, efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33237
llvm-svn: 303670
Summary:
This field is never assigned to and it's only ever read from libclang.
This patch removes it and adapts libclang to return constants.
Reviewers: klimek, bkramer
Reviewed By: klimek
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32351
llvm-svn: 303635
Expose pipe, sampler_t, clk_event_t, queue_t, reserve_id_t, and all
image types.
Update the opencl-types.cl test RUN line such that we can test the
OpenCL 2.0 types.
Patch by Simon Perretta.
Differential Revision: https://reviews.llvm.org/D33197
llvm-svn: 303626
A refactoring of TemplateIdAnnotation that uses TrailingObjects to create a variably-sized object on the heap.
https://reviews.llvm.org/D31414
Thanks to Aaron B for the review!
llvm-svn: 303594
When a diagnostic includes a highlighted range spanning multiple lines, clang
now supports printing out multiple lines of context if necessary to show the
highlighted ranges. This is not yet exposed in the driver, but can be enabled
by "-Xclang -fcaret-diagnostics-max-lines -Xclang N".
This is experimental until we can find out whether it works well in practice,
and if so, what a good default for the maximum number of lines is.
llvm-svn: 303589
Summary:
If unhandled_exception member function is present in the coroutine promise,
wrap the body of the coroutine in:
```
try {
body
} catch(...) { promise.unhandled_exception(); }
```
Reviewers: EricWF, rnk, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31692
llvm-svn: 303583
This allows #line directives to appear in system headers that have code
that clang would normally warn on. This is compatible with GCC, which is
easy to test by running `gcc -E`.
Fixes PR30752
llvm-svn: 303582
Summary:
1. build declaration of the gro local variable that keeps the result of get_return_object.
2. build return statement returning the gro variable
3. emit them during CodeGen
4. sema and CodeGen tests updated
Reviewers: EricWF, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31646
llvm-svn: 303573
This patch adds support for the `micromips` and `nomicromips` attributes
for MIPS targets.
Differential revision: https://reviews.llvm.org/D33363
llvm-svn: 303546
Summary:
Add option to customize the penalty for breaking assignment
This allows increasing the priority of the assignment, to prefer spliting
an operation instead of splitting the assignment, e.g. :
int a = bbbbbbbbbbbbbbbb +
cccccccccccccccc;
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32477
llvm-svn: 303534
This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments as constant-expressions by installing the ConstantEvaluated ExpressionEvaluationContext just before attempting the disambiguation - and then making sure that Context carries through into ParseConstantExpression (by refactoring it out into a function that does not create its own EvaluationContext: ParseConstantExpressionInExprEvalContext)
Note, prior to this patch, trunk would correctly disambiguate and identify the expression as an expression - and while it would annotate the token with the expression - it would fail to complete the odr-use processing (specifically, failing to trigger Sema::UpdateMarkingForLValueToRValue as is done for all Constant Expressions, which would remove it from being considered odr-used). By installing the ConstantExpression Evaluation Context prior to disambiguation, and making sure it carries though, we ensure correct processing of the expression-node.
For e.g:
template<int> struct X { };
void f() {
const int N = 10;
X<N> x; // should be OK.
[] { return X<N>{}; }; // Should be OK - no capture - but clang errors!
}
See a related bug: https://bugs.llvm.org//show_bug.cgi?id=25627
In summary (and reiteration), the fix is as follows:
- Remove the EnteredConstantEvaluatedContext action from ParseTemplateArgumentList (relying on ParseTemplateArgument getting it right)
- Add the EnteredConstantEvaluatedContext action just prior to undergoing the disambiguating parse, and if the parse succeeds for an expression, carry the context though into a refactored version of ParseConstantExpression that does not create its own ExpressionEvaluationContext.
See https://reviews.llvm.org/D31588 for additional context regarding some of the more fragile and complicated approaches attempted, and Richard's feedback that eventually shaped the simpler and more robust rendition that is being committed.
Thanks Richard!
llvm-svn: 303492
remove the mechanism for doing so.
This mechanism was incorrect in the presence of preprocessed modules (and
#pragma clang module begin/end).
llvm-svn: 303469
As discussed in D30793, we have some unsafe calls to isConsumerInterestedIn().
This patch implements Richard's suggestion (from the inline comment) that we
should track if we just deserialized an declaration. If we just deserialized,
we can skip the unsafe call because we know it's interesting. If we didn't just
deserialize the declaration, calling isConsumerInterestedIn() should be safe.
We tried to create a test case for this but we were not successful.
Patch by Raphael Isemann (D32499)!
llvm-svn: 303432
We were incorrectly setting PrevTokLocation to the first token in the
annotation token instead of the last when consuming it. To fix this without
adding a complex switch to the hot path through ConsumeToken, we now have a
ConsumeAnnotationToken function for consuming annotation tokens in addition
to the other Consume*Token special case functions.
llvm-svn: 303372
Alloca always returns a pointer in alloca address space, which may
be different from the type defined by the language. For example,
in C++ the auto variables are in the default address space. Therefore
cast alloca to the expected address space when necessary.
Differential Revision: https://reviews.llvm.org/D32248
llvm-svn: 303370
looking up a dependent name in a record that derives from itself
rdar://32273000
Differential Revision: https://reviews.llvm.org/D33324
llvm-svn: 303366
inferring based on the current module at the point of creation.
This should result in no functional change except when building a preprocessed
module (or more generally when using #pragma clang module begin/end to switch
module in the middle of a file), in which case it allows us to correctly track
the owning module for declarations. We can't map from FileID to module in the
preprocessed module case, since all modules would have the same FileID.
There are still a couple of remaining places that try to infer a module from a
source location; I'll clean those up in follow-up changes.
llvm-svn: 303322
Summary:
OnDiskData.TemporaryFiles is filled only by ASTUnit::addTemporaryFile, which is
dead. Also these files are used nowhere in the frontend nor in libclang.
Reviewers: bkramer, ilya-biryukov
Reviewed By: bkramer, ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33270
llvm-svn: 303265
rather than waiting until it's queried.
Currently this is only applied to local submodule visibility mode, as we don't
yet allocate storage for the owning module in non-local-visibility modules
compilations.
This reinstates r302965, reverted in r303037, with a fix for the reported
crash, which occurred when reparenting a local declaration to be a child of
a hidden imported declaration (specifically during template instantiation).
llvm-svn: 303224
This commit fixes a bug that's tracked by PR 10758 and duplicates like PR 30343.
The bug causes clang to crash with a stack overflow while recursing infinitely
trying to perform copy-initialization on a type without a copy constructor but
with a constructor that accepts another type that can be constructed using the
original type.
The commit fixes this bug by detecting the recursive behavior and failing
correctly with an appropriate error message. It also tries to provide a
meaningful diagnostic note about the constructor which leads to this behavior.
rdar://28483944
Differential Revision: https://reviews.llvm.org/D25051
llvm-svn: 303156
module immediately
Also revert dependent r302969. This is leading to crashes.
Will provide more details reproduction instructions to Richard.
llvm-svn: 303037
ASTImporter has some bugs when it's importing types
that themselves come from an ExternalASTSource. This
is exposed particularly in the behavior when
comparing complete TagDecls with forward
declarations. This patch does several things:
- Adds a test case making sure that conflicting
forward-declarations are resolved correctly;
- Extends the clang-import-test harness to test
two-level importing, so that we make sure we
complete types when necessary; and
- Fixes a few bugs I found this way. Failure to
complete types was one; however, I also discovered
that complete RecordDecls aren't properly added to
the redecls chain for existing forward
declarations.
llvm-svn: 302975
rather than waiting until it's queried.
Currently this is only applied to local submodule visibility mode, as we don't
yet allocate storage for the owning module in non-local-visibility modules
compilations.
llvm-svn: 302965
This patch teaches clang to perform implicit scalar to vector conversions
when one of the operands of a binary vector expression is a scalar which
can be converted to the element type of the vector without truncation
following GCC's implementation.
If the (constant) scalar is can be casted safely, it is implicitly casted to the
vector elements type and splatted to produce a vector of the same type.
Contributions from: Petar Jovanovic
Reviewers: bruno, vkalintiris
Differential Revision: https://reviews.llvm.org/D25866
llvm-svn: 302935
This diff
1. adds missing "explicit" for single argument constructors
2. adds missing std::move in ReplaceNodeWithTemplate constructor
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D33061
llvm-svn: 302855
When we parse a redefinition of an entity for which we have a hidden existing
declaration, make it visible in the current module instead of mapping the
current source location to its containing module.
llvm-svn: 302842
type is a TemplateSpecializationType or InjectedClassNameType
Fixes PR30847. Partially fixes PR20973 (first position only).
PR17614 is still not working, its expression has the dependent
builtin type. We'll have to teach the completion engine how to "resolve"
dependent expressions to fix it.
rdar://29818301
llvm-svn: 302797
Diagnostics related to redefinition errors that point to the same header
file do not provide much information that helps users fixing the issue.
- In the modules context, it usually happens because of non modular
includes.
- When modules aren't involved it might happen because of the lack of
header guards.
Enhance diagnostics in these scenarios.
Differential Revision: https://reviews.llvm.org/D28832
rdar://problem/31669175
llvm-svn: 302765
When an undeclared identifier in a context that requires a type is followed by
'<', only look for type templates when typo-correcting, tweak the diagnostic
text to say that a template name (not a type name) was undeclared, and parse
the template arguments when recovering from the error.
llvm-svn: 302732
This commit implements basic support for indexing of dependent declaration
references. Now the indexer tries to find a suitable match in the base template
for a dependent member ref/decl ref/dependent type.
rdar://29158210
Differential Revision: https://reviews.llvm.org/D32972
llvm-svn: 302632
Summary: This is the first change as part of developing a clang-query based search and replace tool.
Reviewers: klimek, bkramer, ioeric, sbenza, jbangert
Reviewed By: ioeric, jbangert
Subscribers: sbenza, ioeric, cfe-commits
Patch by Julian Bangert!
Differential Revision: https://reviews.llvm.org/D29621
llvm-svn: 302624
The heuristic that we use here is:
* the left-hand side must be a simple identifier or a class member access
* the right-hand side must be '<' followed by either a '>' or by a type-id that
cannot be an expression (in particular, not followed by '(' or '{')
* there is a '>' token matching the '<' token
The second condition guarantees the expression would otherwise be ill-formed.
If we're confident that the user intended the name before the '<' to be
interpreted as a template, diagnose the fact that we didn't interpret it
that way, rather than diagnosing that the template arguments are not valid
expressions.
llvm-svn: 302615
This improves our behavior in a few ways:
* We now guarantee that if a member is marked as being a member
specialization, there will actually be a member specialization declaration
somewhere on its redeclaration chain. This fixes a crash in modules builds
where we would try to check that there was a visible declaration of the
member specialization and be surprised to not find any declaration of it at
all.
* We don't set the source location of the in-class declaration of the member
specialization to the out-of-line declaration's location until we have
actually finished merging them. This fixes some very silly looking
diagnostics, where we'd point a "previous declaration is here" note at the
same declaration we're complaining about. Ideally we wouldn't mess with the
prior declaration's location at all, but too much code assumes that the
first declaration of an entity is a reasonable thing to use as an indication
of where it was declared, and that's not really true for a member
specialization unless we fake it like this.
llvm-svn: 302596
This feature is subtly broken when the linker is gold 2.26 or
earlier. See the following bug for details:
https://sourceware.org/bugzilla/show_bug.cgi?id=19002
Since the decision needs to be made at compilation time, we can not
test the linker version. The flag is off by default on ELF targets,
and on otherwise.
llvm-svn: 302591
`__builtin_available`
This commit allows us to use the macOS/iOS/tvOS/watchOS platform names in
`@available`/`__builtin_available`.
rdar://32067795
Differential Revision: https://reviews.llvm.org/D33000
llvm-svn: 302540
We were sometimes doing a function->pointer conversion in
Sema::CheckPlaceholderExpr, which isn't the job of CheckPlaceholderExpr.
So, when we saw typeof(OverloadedFunctionName), where
OverloadedFunctionName referenced a name with only one function that
could have its address taken, we'd give back a function pointer type
instead of a function type. This is incorrect.
I kept the logic for doing the function pointer conversion in
resolveAndFixAddressOfOnlyViableOverloadCandidate because it was more
consistent with existing ResolveAndFix* methods.
llvm-svn: 302506
Summary:
We define the `__xray_customeevent` builtin that gets translated to
IR calls to the correct intrinsic. The default implementation of this is
a no-op function. The codegen side of this follows the following logic:
- When `-fxray-instrument` is not provided in the driver, we elide all
calls to `__xray_customevent`.
- When `-fxray-instrument` is enabled and a function is marked as "never
instrumented", we elide all calls to `__xray_customevent` in that
function; if either marked as "always instrumented" or subject to
threshold-based instrumentation, we emit a call to the
`llvm.xray.customevent` intrinsic from LLVM for each
`__xray_customevent` occurrence in the function.
This change depends on D27503 (to land in LLVM first).
Reviewers: echristo, rsmith
Subscribers: mehdi_amini, pelikan, lrl, cfe-commits
Differential Revision: https://reviews.llvm.org/D30018
llvm-svn: 302492
DontAlign
This converts the clang-format option AlignEscapedNewlinesLeft from a
boolean to an enum, named AlignEscapedNewlines, with options Left (prev.
true), Right (prev. false), and a new option DontAlign.
When set to DontAlign, the backslashes are placed just after the last token in each line:
#define EXAMPLE \
do { \
int x = aaaaa; \
int b; \
int dddddddddd; \
} while (0)
Patch by jtbandes. Thank you!
llvm-svn: 302428
This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4).
Differential Revision: https://reviews.llvm.org/D32770
llvm-svn: 302418
To support this, an optional marker "#pragma clang module contents" is
recognized in module map files, and the rest of the module map file from that
point onwards is treated as the source of the module. Preprocessing a module
map produces the input module followed by the marker and then the preprocessed
contents of the module.
Ignoring line markers, a preprocessed module might look like this:
module A {
header "a.h"
}
#pragma clang module contents
#pragma clang module begin A
// ... a.h ...
#pragma clang module end
The preprocessed output generates line markers, which are not accepted by the
module map parser, so -x c++-module-map-cpp-output should be used to compile
such outputs.
A couple of major parts do not work yet:
1) The files that are listed in the module map must exist on disk, in order to
build the on-disk header -> module lookup table in the PCM file. To fix
this, we need the preprocessed output to track the file size and other stat
information we might use to build the lookup table.
2) Declaration ownership semantics don't work properly yet, since mapping from
a source location to a module relies on mapping from FileIDs to modules,
which we can't do if module transitions can occur in the middle of a file.
llvm-svn: 302309
Richard Smith