summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTReaderDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Generalize "static data member instantiated" notification to cover variable ↵Richard Smith2017-12-051-3/+20
| | | | | | | | | templates too. While here, split the "point of instantiation changed" notification out from it; these two really are orthogonal changes. llvm-svn: 319727
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-1/+1
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* PR35456: Track definedness of variable template specializations separately fromRichard Smith2017-12-021-0/+1
| | | | | | | | | | whether they have an initializer. We cannot distinguish between a declaration of a variable template specialization and a definition of one that lacks an initializer without this, and would previously mistake the latter for the former. llvm-svn: 319605
* Adjust r316292 - remove the anonymous union for sharing a bitfield in ↵Faisal Vali2017-11-111-2/+1
| | | | | | | | | | | | | | FunctionDecl. The anonymous union did NOT save us storage, but instead behaved as if we added an additional integer data member to FunctionDecl. For additional context, the anonymous union renders the bit fields as non-adjacent and prevents them from sharing the same 'memory location' (i.e. bit-storage) by requiring the anonymous union object to be appropriately aligned. This was confirmed through discussion with Richard Smith in Albuquerque (ISO C++ Meeting) https://reviews.llvm.org/rL316292 llvm-svn: 317984
* PR33746: Store the 'inline'ness of a static data member with the update recordRichard Smith2017-11-021-0/+2
| | | | | | | | | for instantiating its definition. We model the 'inline'ness as being instantiated with the static data member in order to track whether the declaration has become a definition yet. llvm-svn: 317147
* [C++17] Fix PR34970 - tweak overload resolution for class template ↵Faisal Vali2017-10-221-0/+2
| | | | | | | | | | | | | | | | | | | deduction-guides in line with WG21's p0620r0. In order to identify the copy deduction candidate, I considered two approaches: - attempt to determine whether an implicit guide is a copy deduction candidate by checking certain properties of its subsituted parameter during overload-resolution. - using one of the many bits (WillHaveBody) from FunctionDecl (that CXXDeductionGuideDecl inherits from) that are otherwise irrelevant for deduction guides After some brittle gymnastics w the first strategy, I settled on the second, although to avoid confusion and to give that bit a better name, i turned it into a member of an anonymous union. Given this identification 'bit', the tweak to overload resolution was a simple reordering of the deduction guide checks (in SemaOverload.cpp::isBetterOverloadCandidate), in-line with Jason Merrill's p0620r0 drafting which made it into the working paper. Concordant with that, I made sure the copy deduction candidate is always added. References: See https://bugs.llvm.org/show_bug.cgi?id=34970 See http://wg21.link/p0620r0 llvm-svn: 316292
* Support for destroying operator delete, per C++2a proposal P0722.Richard Smith2017-10-131-2/+8
| | | | | | | | | | This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
* Revert r314955: "Remove PendingBody mechanism for function and ObjC method ↵Daniel Jasper2017-10-111-73/+33
| | | | | | | | | | | deserialization." This is breaking a build of https://github.com/abseil/abseil-cpp and so likely not really NFC. Also reverted subsequent r314956/7. I'll forward reproduction instructions to Richard. llvm-svn: 315439
* PR33924: Merge block-scope anonymous declarations if there are multiple ↵Richard Smith2017-10-051-0/+1
| | | | | | definitions of the enclosing function. llvm-svn: 314956
* Remove PendingBody mechanism for function and ObjC method deserialization.Richard Smith2017-10-051-33/+72
| | | | | | | | | | | | In its place, track on the canonical function declaration whether there is a declaration with a body (and if so, which one). This brings function definition handling in line with what we do in all other contexts, and is necessary to allow us to merge declarations within multiple definitions of the same function (eg, PR33924). No functionality change intended. llvm-svn: 314955
* [ODRHash] Add base classes to hashing CXXRecordDecl.Richard Trieu2017-09-301-1/+2
| | | | llvm-svn: 314581
* [modules ts] Ensure that module linkage variables are always emitted and ↵Richard Smith2017-09-071-10/+10
| | | | | | always have their name mangled. llvm-svn: 312684
* [modules ts] Emit global variables in a module interface unit as part of ↵Richard Smith2017-09-061-4/+7
| | | | | | that unit, not in importers. llvm-svn: 312665
* [OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime inAlexey Bataev2017-09-061-1/+3
| | | | | | | | | | move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
* [c++2a] P0683R1: Permit default member initializers for bit-fields.Richard Smith2017-08-281-9/+10
| | | | | | | This would be trivial, except that our in-memory and serialized representations for FieldDecls assumed that this can't happen. llvm-svn: 311867
* PR19668, PR23034: Fix handling of move constructors and deleted copyRichard Smith2017-08-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
* Revert "PR19668, PR23034: Fix handling of move constructors and deleted copy ↵Diana Picus2017-08-091-6/+0
| | | | | | | | | constructors when deciding whether classes should be passed indirectly." This reverts commit r310401 because it seems to have broken some ARM bot(s). llvm-svn: 310464
* PR19668, PR23034: Fix handling of move constructors and deleted copyRichard Smith2017-08-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. llvm-svn: 310401
* [modules ts] Improve merging of module-private declarations.Richard Smith2017-07-051-0/+2
| | | | | | | | | | 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
* Reinstate "Load lazily the template specialization in multi-module setups."Vassil Vassilev2017-06-301-38/+47
| | | | | | | | It was reverted in r305460 but the issue appears to only break our self-host libcxx modules bot. Reapplying it will give us a chance to get a reproducer and fix the issue. llvm-svn: 306903
* Teach ASTReader how to read only the Preprocessor state from an AST file, ↵Richard Smith2017-06-291-16/+21
| | | | | | | | | not the ASTContext state. 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
* [ASTReader] Treat multiple defns of ObjC protocols the same as interfaces.Graydon Hoare2017-06-281-14/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PR33552: Distinguish between declarations that are owned by no module andRichard Smith2017-06-231-15/+13
| | | | | | | | | | | | | | | | | | | 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
* PR33002: When we instantiate the definition of a static data member, we mightRichard Smith2017-06-221-2/+13
| | | | | | | have attached an initializer to the in-class declaration. If so, include the initializer in the update record for the instantiation. llvm-svn: 306065
* Revert "Load lazily the template specialization in multi-module setups."Vassil Vassilev2017-06-151-47/+38
| | | | | | This broke our libcxx modules builds. llvm-svn: 305460
* [modules] D29951: Load lazily the template specialization in multi-module ↵Vassil Vassilev2017-06-091-38/+47
| | | | | | | | | | | | setups. Currently, we load all template specialization if we have more than one module attached and we touch anything around the template definition. This patch registers the template specializations as lazily-loadable entities. In some TUs it reduces the amount of deserializations by 1%. llvm-svn: 305120
* [DebugInfo] Add kind of ImplicitParamDecl for emission of FlagObjectPointer.Alexey Bataev2017-06-091-0/+1
| | | | | | | | | | | | | | | | | 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
* [modules] Further delay calling DeclMustBeEmitted until it's safe.Vassil Vassilev2017-05-191-6/+11
| | | | | | | | | | | | | | 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
* [modules] Delay calling DeclMustBeEmitted until it's safe.Vassil Vassilev2017-04-121-3/+32
| | | | | | | | | | | | | This patch implements the suggestion in D29753 that calling DeclMustBeEmitted in the middle of deserialization should be avoided and that the actual check should be deferred until it's safe to do so. This patch fixes a crash when accessing the invalid redecl chains while trying to evaluate the value of a const VarDecl that contains a function call. Patch by Raphael Isemann (D30793)! llvm-svn: 300110
* [ODRHash] Improve handling of hash valuesRichard Trieu2017-04-111-1/+5
| | | | | | | | | | | 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
* Modular Codegen: Support homing debug info for types in modular objectsDavid Blaikie2017-04-111-4/+15
| | | | | | | | | Matching the function-homing support for modular codegen. Any type implicitly (implicit template specializations) or explicitly defined in a module is attached to that module's object file and omitted elsewhere (only a declaration used if necessary for references). llvm-svn: 299987
* Modular Codegen: Add/use a bit in serialized function definitions to track ↵David Blaikie2017-04-111-0/+2
| | | | | | | | | | | | | | | | | | | | | whether they are the subject of modular codegen Some decls are created not where they are written, but in other module files/users (implicit special members and function template implicit specializations). To correctly identify them, use a bit next to the definition to track the modular codegen property. Discussed whether the module file bit could be omitted in favor of reconstituting from the modular codegen decls list - best guess today is that the efficiency improvement of not having to deserialize the whole list whenever any function is queried by a module user is worth it for the small size increase of this redundant (list + bit-on-def) representation. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D29901 llvm-svn: 299982
* [Serialization] Follow-up to r297972, deserialize name/loc in separate ↵Argyrios Kyrtzidis2017-03-171-4/+6
| | | | | | | | statements to make sure they deserialize in defined order. This should fix the windows bots. llvm-svn: 298027
* [index/AST] Add references for ObjC getter=/setter= property attributes and ↵Argyrios Kyrtzidis2017-03-161-2/+4
| | | | | | | | | | | related property getter/setter role fixes This enhances the AST to keep track of locations of the names in those ObjC property attributes, and reports them for indexing. Patch by Nathan Hawes! https://reviews.llvm.org/D30907 llvm-svn: 297972
* Take into account C++17's noexcept function types during merging -- it shouldRichard Smith2017-03-081-2/+16
| | | | | | | be possible to merge a declaration with an unresolved function type against one with a resolved function type. llvm-svn: 297316
* [AST/ObjC] Make ObjCCategoryImplDecl consistent with ObjCCategoryDecl and ↵Argyrios Kyrtzidis2017-03-071-1/+0
| | | | | | | | use the category name as its DeclName This also addresses the badness in ObjCCategoryImplDecl's API, which was hiding NamedDecl's APIs with different meaning. llvm-svn: 297131
* [PCH] Avoid VarDecl emission attempt if no owning module avaiableBruno Cardoso Lopes2017-03-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a stopgap fix for PR31863, a regression introduced in r276159. Consider this snippet: struct FVector; struct FVector {}; struct FBox { FVector Min; FBox(int); }; namespace { FBox InvalidBoundingBox(0); } While parsing the DECL_VAR for 'struct FBox', clang recursively read all the dep decls until it finds the DECL_CXX_RECORD forward declaration for 'struct FVector'. Then, it resumes all the way up back to DECL_VAR handling in `ReadDeclRecord`, where it checks if `isConsumerInterestedIn` for the decl. One of the condition for `isConsumerInterestedIn` to return false is if the VarDecl is imported from a module `D->getImportedOwningModule()`, because it will get emitted when we import the relevant module. However, before checking if it comes from a module, clang checks if `Ctx.DeclMustBeEmitted(D)`, which triggers the emission of 'struct FBox'. Since one of its fields is still incomplete, it crashes. Instead, check if `D->getImportedOwningModule()` is true before calling `Ctx.DeclMustBeEmitted(D)`. Differential Revision: https://reviews.llvm.org/D29753 rdar://problem/30173654 llvm-svn: 296656
* C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules ↵Richard Smith2017-02-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | 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
* Represent pass_object_size attrs in ExtParameterInfoGeorge Burgess IV2017-02-241-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal of this is to fix a bug in modules where we'd merge FunctionDecls that differed in their pass_object_size attributes. Since we can overload on the presence of pass_object_size attributes, this behavior is incorrect. We don't represent `N` in `pass_object_size(N)` as part of ExtParameterInfo, since it's an error to overload solely on the value of N. This means that we have a bug if we have two modules that declare functions that differ only in their pass_object_size attrs, like so: // In module A, from a.h void foo(char *__attribute__((pass_object_size(0)))); // In module B, from b.h void foo(char *__attribute__((pass_object_size(1)))); // In module C, in main.c #include "a.h" #include "b.h" At the moment, we'll merge the foo decls, when we should instead emit a diagnostic about an invalid overload. We seem to have similar (silent) behavior if we overload only on the return type of `foo` instead; I'll try to find a good place to put a FIXME (or I'll just file a bug) soon. This patch also fixes a bug where we'd not output the proper extended parameter info for declarations with pass_object_size attrs. llvm-svn: 296076
* Part of adding an improved ODR checker.Richard Trieu2017-02-181-0/+2
| | | | | | | | | 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
* Add an explicit derived class of FunctionDecl to model deduction guides ratherRichard Smith2017-02-171-0/+8
| | | | | | | | than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
* Revert r295421, new ODR checker for modules, to fix build bot.Richard Trieu2017-02-171-2/+0
| | | | llvm-svn: 295427
* Add better ODR checking for modules.Richard Trieu2017-02-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r295284: Add better ODR checking for modules.Richard Trieu2017-02-161-2/+0
| | | | | | Fix modules build bot. llvm-svn: 295293
* Add better ODR checking for modules.Richard Trieu2017-02-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Modules] Consider enable_if attrs in isSameEntity.George Burgess IV2017-02-151-2/+42
| | | | | | | | | | | | | | Two functions that differ only in their enable_if attributes are considered overloads, so we should check for those when we're trying to figure out if two functions are mergeable. We need to do the same thing for pass_object_size, as well. Looks like that'll be a bit less trivial, since we sometimes do these merging checks before we have pass_object_size attributes available (see the merge checks in ASTDeclReader::VisitFunctionDecl that happen before we read parameters, and merge checks in calls to ReadDeclAs<>()). llvm-svn: 295252
* ASTReader: Refactor common code for writing function definitions, to match ↵David Blaikie2017-02-121-17/+15
| | | | | | the writing code llvm-svn: 294904
* [Concepts] Class template associated constraintsHubert Tong2017-02-101-0/+1
| | | | | | | | | | | | | | | | Summary: This adds associated constraints as a property of class templates. An error is produced if redeclarations are not similarly constrained. Reviewers: rsmith, faisalv, aaron.ballman Reviewed By: rsmith Subscribers: cfe-commits, nwilson Differential Revision: https://reviews.llvm.org/D25674 llvm-svn: 294697
* Sink IsExplicitSpecified flag from CXXConstructorDecl and CXXConversionDeclRichard Smith2017-02-101-3/+1
| | | | | | | into FunctionDecl. Makes CXXConversionDecl 8 bytes smaller. No functionality change intended. llvm-svn: 294684
* Revert r293585 "Add better ODR checking for modules."Sam McCall2017-01-311-2/+0
| | | | | | | | | | | 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
OpenPOWER on IntegriCloud