| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
Adding a test separately (tools/extra/test/clang-tidy/misc-use-after-move.cpp).
llvm-svn: 302889
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
merged template.
When looking for the template instantiation pattern of a templated entity,
consistently select the definition of the pattern if there is one. This means
we'll pick the same owning module when we start instantiating a template that
we'll later pick when determining which modules are visible during that
instantiation.
This reinstates r300650, reverted in r300659, with a fix for a regression
reported by Chandler after commit.
llvm-svn: 300938
|
| |
|
|
|
|
|
|
|
|
| |
modules but exposes much more widespread issues. Example and more
information is on the review thread for r300650.
Original commit summary:
[modules] Properly look up the owning module for an instantiation of a merged template.
llvm-svn: 300659
|
| |
|
|
|
|
|
|
|
|
|
|
| |
merged template.
When looking for the template instantiation pattern of a templated entity,
consistently select the definition of the pattern if there is one. This means
we'll pick the same owning module when we start instantiating a template that
we'll later pick when determining which modules are visible during that
instantiation.
llvm-svn: 300650
|
| |
|
|
|
|
|
|
|
|
|
| |
Calculating the hash in Sema::ActOnTagFinishDefinition could happen before
all sub-Decls were parsed or processed, which would produce the wrong hash
value. Change to calculating the hash on the first use and storing the value
instead. Also, avoid using the macros that were only for Boolean fields and
use an explicit checker during the DefintionData merge. No functional change,
but was this blocking other ODRHash patches.
llvm-svn: 299989
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fobjc-weak
Summary: When adding an Objective-C retainable type member to a C++ class, also check the LangOpts.ObjCWeak flag and the lifetime qualifier so __weak qualified Objective-C pointer members cause the class to be a non-POD type with non-trivial special members, so the compiler always emits the necessary runtime calls for copying, moving, and destroying the weak member. Otherwise, Objective-C++ classes with weak Objective-C pointer members compiled with -fobjc-weak exhibit undefined behavior if the C++ class is classified as a POD type.
Reviewers: rsmith, benlangmuir, doug.gregor, rjmccall
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31003
llvm-svn: 299008
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for special member functions.
Essentially, as a base class constructor does not construct virtual bases, such
a constructor for an abstract class does not need the corresponding base class
construction to be valid, and likewise for destructors.
This creates an awkward situation: clang will sometimes generate references to
the complete object and deleting destructors for an abstract class (it puts
them in the construction vtable for a derived class). But we can't generate a
"correct" version of these because we can't generate references to base class
constructors any more (if they're template specializations, say, we might not
have instantiated them and can't assume any other TU will emit a copy).
Fortunately, we don't need to, since no correct program can ever invoke them,
so instead emit symbols that just trap.
We should stop emitting references to these symbols, but still need to emit
definitions for compatibility.
llvm-svn: 296275
|
| |
|
|
|
|
|
|
|
|
| |
Add the basics for the ODRHash class, which will only process Decl's from
a whitelist, which currently only has AccessSpecDecl. Different access
specifiers in merged classes can now be detected.
Differential Revision: https://reviews.llvm.org/D21675
llvm-svn: 295800
|
| |
|
|
|
|
|
|
|
| |
Reserve a spot for ODR hash in CXXRecordDecl and in its modules storage.
Default the hash value to 0 for all classes.
Differential Revision: https://reviews.llvm.org/D21675
llvm-svn: 295533
|
| |
|
|
|
|
|
|
| |
than just treating them as FunctionDecls with a funny name.
No functionality change intended.
llvm-svn: 295491
|
| |
|
|
| |
llvm-svn: 295427
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A slightly weaker form of ODR checking than previous attempts, but hopefully
won't break the modules build bot. Future work will be needed to catch all
cases.
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 taken 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: 295421
|
| |
|
|
|
|
| |
Fix modules build bot.
llvm-svn: 295293
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recommit r293585 that was reverted in r293611 with new fixes. The previous
issue was determined to be an overly aggressive AST visitor from forward
declared objects. The visitor will now only deeply visit certain Decl's and
only do a shallow information extraction from all other Decl's.
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 taken 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: 295284
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
effect they would have in C++11. In particular, they do not prevent
value-initialization from performing zero-initialization, nor do they prevent a
struct from being an aggregate.
llvm-svn: 290229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
This is a re-commit of r290080 (reverted in r290092) with a fix for a
use-after-lifetime bug.
llvm-svn: 290203
|
| |
|
|
|
|
|
| |
This reverts commit r290080 as it leads to many Clang crashes, e.g.:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814
llvm-svn: 290092
|
| |
|
|
|
|
|
|
|
|
|
| |
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
llvm-svn: 290080
|
| |
|
|
|
|
|
|
|
|
|
| |
copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.
This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.
llvm-svn: 289618
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructors
Summary:
The C++17 rules for aggregate initialization changed to disallow types with explicit constructors [dcl.init.aggr]p1. This patch implements that new rule.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25654
llvm-svn: 288565
|
| |
|
|
|
|
|
|
| |
based arrays. Patch by Ian Tessier!
Differential Review: https://reviews.llvm.org/D25974
llvm-svn: 285430
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 284730
|
| |
|
|
|
|
|
|
|
|
|
| |
past-the-end iterator.
Original commit message:
P0035R4: Semantic analysis and code generation for C++17 overaligned
allocation.
llvm-svn: 283789
|
| |
|
|
|
|
|
|
|
|
|
|
| |
allocation."
This reverts commit r283722. Breaks:
Clang.SemaCUDA.device-var-init.cu
Clang.CodeGenCUDA.device-var-init.cu
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/884/
llvm-svn: 283750
|
| |
|
|
|
|
| |
allocation.
llvm-svn: 283722
|
| |
|
|
| |
llvm-svn: 282800
|
| |
|
|
|
|
|
| |
deserialization cycle caused by the ContextDecl recursively importing members
of the lambda's closure type.
llvm-svn: 279694
|
| |
|
|
|
|
|
|
| |
anonymous union member of a class, we need overload resolution for the move
constructor of the class itself too; we can't rely on Sema to do the right
thing for us for anonymous union types.
llvm-svn: 278763
|
| |
|
|
|
|
|
|
| |
tuple-like decomposition declaration. This significantly simplifies the
semantics of BindingDecls for AST consumers (they can now always be evalated
at the point of use).
llvm-svn: 278640
|
| |
|
|
|
|
| |
declarations.
llvm-svn: 278460
|
| |
|
|
| |
llvm-svn: 278448
|
| |
|
|
| |
llvm-svn: 278447
|
| |
|
|
|
|
|
| |
decomposition declaration for arrays, aggregate-like structs, tuple-like
types, and (as an extension) for complex and vector types.
llvm-svn: 278435
|
| |
|
|
|
|
|
|
|
|
|
| |
decomposition declarations.
There are a couple of things in the wording that seem strange here:
decomposition declarations are permitted at namespace scope (which we partially
support here) and they are permitted as the declaration in a template (which we
reject).
llvm-svn: 276492
|
| |
|
|
|
|
| |
Matches methods overridden by the given method.
llvm-svn: 274531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
|
| |
|
|
|
|
|
| |
This reverts commit r272386. It doesn't compile with MSVC and those bots
have been red the entire day as a consequence.
llvm-svn: 272453
|
| |
|
|
|
|
| |
Matches methods overridden by the given method.
llvm-svn: 272386
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements support for MS-specific __unaligned qualifier in functions and
makes the following test case both compile and mangle correctly:
struct S {
void f() __unaligned;
};
void S::f() __unaligned {
}
Differential Revision: http://reviews.llvm.org/D20437
llvm-svn: 270834
|
| |
|
|
|
|
|
|
|
| |
We were missing references to the standard, some of our home-grown
verbiage didn't make any sense.
No functional change is intended.
llvm-svn: 270353
|
| |
|
|
|
|
| |
on a declaration that already knows the location of the DefinitionData object.
llvm-svn: 269858
|
| |
|
|
|
|
|
|
|
| |
a base class via a using-declaration. If a class has a using-declaration
declaring either a constructor or an assignment operator, eagerly declare its
special members in case they need to displace a shadow declaration from a
using-declaration.
llvm-svn: 269398
|
| |
|
|
|
|
| |
classes; these are initialized as if they were data members.
llvm-svn: 262963
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r261297 called hasUserProvidedDefaultConstructor() to check if defining a
const object is ok. This is incorrect for this example:
struct X { template<typename ...T> X(T...); int n; };
const X x; // formerly OK, now bogus error
Instead, track if a class has a defaulted default constructor, and disallow
a const object for classes that either have defaulted default constructors or
if they need an implicit constructor.
Bug report and fix approach by Richard Smith, thanks!
llvm-svn: 261770
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For templates, fields can have incomplete types:
template <class T>
struct A2 {
struct B;
B b;
};
Don't try to touch the DefinitionData of those fields.
llvm-svn: 261301
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++11 requires const objects to have a user-provided constructor, even for
classes without any fields. DR 253 relaxes this to say "If the implicit default
constructor initializes all subobjects, no initializer should be required."
clang is currently the only compiler that implements this C++11 rule, and e.g.
libstdc++ relies on something like DR 253 to compile in newer versions. This
change makes it possible to build code that says `const vector<int> v;' again
when using libstdc++5.2 and _GLIBCXX_DEBUG
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284).
Fixes PR23381.
http://reviews.llvm.org/D16552
llvm-svn: 261297
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
keys, and PointerIntPairs where the pointee types are incomplete
out-of-line to where we have the complete type.
This is the standard pattern used throughout the AST library to address
the inherently mutually cross referenced nature of the AST.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
llvm-svn: 256612
|
| |
|
|
|
|
|
|
| |
Also remove now-redundant explicit alignment specification on some of
the classes converted prior to TrailingObjects automatically ensuring
proper alignment.
llvm-svn: 256585
|