summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTWriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [modules] If we reach a definition of a class for which we already have aRichard Smith2015-03-261-0/+13
| | | | | | | | non-visible definition, skip the new definition and make the old one visible instead of trying to parse it again and failing horribly. C++'s ODR allows us to assume that the two definitions are identical. llvm-svn: 233250
* [Modules] A second attempt at writing out on-disk hash tables for theChandler Carruth2015-03-261-56/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | decl context lookup tables. The first attepmt at this caused problems. We had significantly more sources of non-determinism that I realized at first, and my change essentially turned them from non-deterministic output into use-after-free. Except that they weren't necessarily caught by tools because the data wasn't really freed. The new approach is much simpler. The first big simplification is to inline the "visit" code and handle this directly. That works much better, and I'll try to go and clean up the other caller of the visit logic similarly. The second key to the entire approach is that we need to *only* collect names into a stable order at first. We then need to issue all of the actual 'lookup()' calls in the stable order of the names so that we load external results in a stable order. Once we have loaded all the results, the table of results will stop being invalidated and we can walk all of the names again and use the cheap 'noload_lookup()' method to quickly get the results and serialize them. To handle constructors and conversion functions (whose names can't be stably ordered) in this approach, what we do is record only the visible constructor and conversion function names at first. Then, if we have any, we walk the decls of the class and add those names in the order they occur in the AST. The rest falls out naturally. This actually ends up simpler than the previous approach and seems much more robust. It uncovered a latent issue where we were building on-disk hash tables for lookup results when the context was a linkage spec! This happened to dodge all of the assert by some miracle. Instead, add a proper predicate to the DeclContext class and use that which tests both for function contexts and linkage specs. It also uncovered PR23030 where we are forming somewhat bizarre negative lookup results. I've just worked around this with a FIXME in place because fixing this particular Clang bug seems quite hard. I've flipped the first part of the test case I added for stability back on in this commit. I'm taking it gradually to try and make sure the build bots are happy this time. llvm-svn: 233249
* Revert "[Modules] When writing out the on-disk hash table for the decl ↵Rafael Espindola2015-03-251-90/+15
| | | | | | | | context lookup tables, we need to establish a stable ordering for constructing the hash table. This is trickier than it might seem." This reverts commit r233156. It broke the bots. llvm-svn: 233172
* [Modules] When writing out the on-disk hash table for the decl contextChandler Carruth2015-03-251-15/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lookup tables, we need to establish a stable ordering for constructing the hash table. This is trickier than it might seem. Most of these cases are easily handled by sorting the lookup results associated with a specific name that has an identifier. However for constructors and conversion functions, the story is more complicated. Here we need to merge all of the constructors or conversion functions together and this merge needs to be stable. We don't have any stable ordering for either constructors or conversion functions as both would require a stable ordering across types. Instead, when we have constructors or conversion functions in the results, we reconstruct a stable order by walking the decl context in lexical order and merging them in the order their particular declaration names are encountered. This doesn't generalize as there might be found declaration names which don't actually occur within the lexical context, but for constructors and conversion functions it is safe. It does require loading the entire decl context if necessary to establish the ordering but there doesn't seem to be a meaningful way around that. Many thanks to Richard for talking through all of the design choices here. While I wrote the code, he guided all the actual decisions about how to establish the order of things. No test case yet because the test case I have doesn't pass yet -- there are still more sources of non-determinism. However, this is complex enough that I wanted it to go into its own commit in case it causes some unforseen issue or needs to be reverted. llvm-svn: 233156
* [Modules] Start making explicit modules produce deterministic output.Chandler Carruth2015-03-241-13/+16
| | | | | | | | | | | | | | | | | | | | | There are two aspects of non-determinism fixed here, which was the minimum required to cause at least an empty module to be deterministic. First, the random number signature is only inserted into the module when we are building modules implicitly. The use case for these random signatures is to work around the very fact that modules are not deterministic in their output when working with the implicitly built and populated module cache. Eventually this should go away entirely when we're confident that Clang is producing deterministic output. Second, the on-disk hash table is populated based on the order of iteration over a DenseMap. Instead, use a MapVector so that we can walk it in insertion order. I've added a test that an empty module, when built twice, produces the same binary PCM file. llvm-svn: 233115
* Silence unused warning in non-assert builds.Daniel Jasper2015-03-241-0/+1
| | | | llvm-svn: 233053
* [modules] Deserialize CXXCtorInitializer list for a constructor lazily.Richard Smith2015-03-241-8/+69
| | | | | | | | | | | | | Previously we'd deserialize the list of mem-initializers for a constructor when we deserialized the declaration of the constructor. That could trigger a significant amount of unnecessary work (pulling in all base classes recursively, for a start) and was causing problems for the modules buildbot due to cyclic deserializations. We now deserialize these on demand. This creates a certain amount of duplication with the handling of CXXBaseSpecifiers; I'll look into reducing that next. llvm-svn: 233052
* [modules] Remove redundant import of lexical decls when building a lookup tableRichard Smith2015-03-231-24/+24
| | | | | | | | | | | | | | | for a DeclContext, and fix propagation of exception specifications along redeclaration chains. This reverts r232905, r232907, and r232907, which reverted r232793, r232853, and r232853. One additional change is present here to resolve issues with LLDB: distinguish between whether lexical decls missing from the lookup table are local or are provided by the external AST source, and still look in the external source if that's where they came from. llvm-svn: 232928
* Reverting 232853 and 232870 because they depend on 232793,Vince Harron2015-03-221-21/+23
| | | | | | which was reverted because it was causing LLDB test failures llvm-svn: 232907
* [modules] When either redecl chain merging or an update record causes us toRichard Smith2015-03-211-23/+21
| | | | | | | | | give an exception specification to a declaration that didn't have an exception specification in any of our imported modules, emit an update record ourselves. Without this, code importing the current module would not see an exception specification that we could see and might have relied on. llvm-svn: 232870
* Remove many superfluous SmallString::str() calls.Yaron Keren2015-03-181-6/+6
| | | | | | | | | | | | | | | Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more. There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity. llvm-svn: 232622
* Make module files passed to a module build via -fmodule-file= available toRichard Smith2015-03-181-9/+20
| | | | | | | | | consumers of that module. Previously, such a file would only be available if the module happened to actually import something from that module. llvm-svn: 232583
* Lambdaify some helper functions. No functionality change.Richard Smith2015-03-161-33/+27
| | | | llvm-svn: 232407
* Deduplicate #undef directives imported from multiple modules.Richard Smith2015-03-131-1/+2
| | | | | | | No functionality change, but deeply-importing module files are smaller and faster now. llvm-svn: 232140
* [modules] Fix iterator invalidation issue with names being added to a moduleRichard Smith2015-03-111-6/+9
| | | | | | while we're writing out the identifier table. llvm-svn: 231890
* [modules] Don't clobber a destructor's operator delete when adding another one;Richard Smith2015-03-101-2/+20
| | | | | | | move the operator delete updating into a separate update record so we can cope with updating another module's destructor's operator delete. llvm-svn: 231735
* Replace Sema's map of locally-scoped extern "C" declarations with a DeclContextRichard Smith2015-03-071-20/+6
| | | | | | | | | | of extern "C" declarations. This is simpler and vastly more efficient for modules builds (we no longer need to load *all* extern "C" declarations to determine if we have a redeclaration). No functionality change intended. llvm-svn: 231538
* Removing code that is unused after r231424; NFC.Aaron Ballman2015-03-061-8/+0
| | | | llvm-svn: 231477
* [modules] Rework merging of redeclaration chains on module import.Richard Smith2015-03-051-32/+17
| | | | | | | | | | | | | | | | | | | | | | We used to save out and eagerly load a (potentially huge) table of merged formerly-canonical declarations when we loaded each module. This was extremely inefficient in the presence of large amounts of merging, and didn't actually save any merging lookup work, because we still needed to perform name lookup to check that our merged declaration lists were complete. This also resulted in a loss of laziness -- even if we only needed an early declaration of an entity, we would eagerly pull in all declarations that had been merged into it regardless. We now store the relevant fragments of the table within the declarations themselves. In detail: * The first declaration of each entity within a module stores a list of first declarations from imported modules that are merged into it. * Loading that declaration pre-loads those other entities, so that they appear earlier within the redeclaration chain. * The name lookup tables list the most recent local lookup result, if there is one, or all directly-imported lookup results if not. llvm-svn: 231424
* Rework our handling of key functions. We used to track a complete list of allRichard Smith2015-02-281-8/+0
| | | | | | | | | | | | | | dynamic classes in the translation unit and check whether each one's key function is defined when we got to the end of the TU (and when we got to the end of each module). This is really terrible for modules performance, since it causes unnecessary deserialization of every dynamic class in every compilation. We now use a much simpler (and, in a modules build, vastly more efficient) system: when we see an out-of-line definition of a virtual function, we check whether that function was in fact its class's key function. (If so, we need to emit the vtable.) llvm-svn: 230830
* [modules] Don't write out name lookup table entries merely because the moduleRichard Smith2015-02-271-10/+13
| | | | | | happened to query them; only write them out if something new was added. llvm-svn: 230727
* Remove slow and apparently pointless updating of all identifiers at the startRichard Smith2015-02-251-17/+0
| | | | | | of writing out an AST file. llvm-svn: 230428
* Cleanup: remove artificial division between lookup results and const lookupRichard Smith2015-02-211-1/+1
| | | | | | | results. No-one was ever modifying a lookup result, and it would not be reasonable to do so. llvm-svn: 230123
* Revert r167816 and replace it with a proper fix for the issue: do notRichard Smith2015-02-211-4/+2
| | | | | | | invalidate lookup_iterators and lookup_results for some name within a DeclContext if the lookup results for a *different* name change. llvm-svn: 230121
* Revert "Mangle the IsSystem bit into the .pcm file name"Ben Langmuir2015-02-191-1/+0
| | | | | | | | While I investigate some possible problems with this patch. This reverts commit r228966 llvm-svn: 229910
* [PCH/Modules] Check that the specific module cache path the PCH was built ↵Argyrios Kyrtzidis2015-02-191-0/+2
| | | | | | | | | | | | with, is the same as the one in the current compiler invocation. If they differ reject the PCH. This protects against the badness occurring from getting modules loaded from different module caches (see crashes). rdar://19889860 llvm-svn: 229909
* Prefer SmallVector::append/insert over push_back loops. Clang edition.Benjamin Kramer2015-02-171-2/+1
| | | | | | Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229508
* [modules] Improve llvm-bcanalyzer output on AST files a little. No ↵Richard Smith2015-02-131-2/+3
| | | | | | functionality change. llvm-svn: 229145
* Mangle the IsSystem bit into the .pcm file nameBen Langmuir2015-02-121-0/+1
| | | | | | | | | When mangling the module map path into a .pcm file name, also mangle the IsSystem bit, which can also depend on the header search paths. For example, the user may change from -I to -isystem. This can affect diagnostics in the importing TU. llvm-svn: 228966
* [modules] Treat friend declarations that are lexically within a dependentRichard Smith2015-02-071-7/+4
| | | | | | | context as anonymous for merging purposes. They can't be found by their names, so we merge them based on their position within the surrounding context. llvm-svn: 228485
* ASTUnit: Use range-based for loops.Benjamin Kramer2015-02-061-1/+2
| | | | llvm-svn: 228420
* [modules] Refactor: unify the code that picks which declaration goes into aRichard Smith2015-02-051-55/+46
| | | | | | name lookup table. llvm-svn: 228354
* Objective-C: Serialize "more than one decl" state of ObjCMethodList.Nico Weber2014-12-271-5/+12
| | | | | | | | | | | | | | | | | This fixes PR21587, what r221933 fixed for regular programs is now also fixed for decls coming from PCH files. Use another bit from the count/bits uint16_t for storing the "more than one decl" bit. This reduces the number of bits for the count from 14 to 13. The selector with the most overloads in Cocoa.h has ~55 overloads, so 13 bits should still be plenty. Since this changes the meaning of a serialized bit pattern, also increase clang::serialization::VERSION_MAJOR. Storing the "more than one decl" state of only the first overload isn't quite correct, but Sema::AreMultipleMethodsInGlobalPool() currently only looks at the state of the first overload so it's good enough for now. llvm-svn: 224892
* Address review feedback on r221933.Nico Weber2014-12-271-14/+14
| | | | | | | | | | | Remove ObjCMethodList::Count, instead store a "has more than one decl" bit in the low bit of the ObjCMethodDecl pointer, using a PointerIntPair. Most of this patch is replacing ".Method" with ".getMethod()". No intended behavior change. llvm-svn: 224876
* [modules] When constructing paths relative to a module, strip out /./ directoryRichard Smith2014-12-111-15/+19
| | | | | | | components. These sometimes get synthetically added, and we don't want -Ifoo and -I./foo to be treated fundamentally differently here. llvm-svn: 224055
* [modules] Instead of storing absolute paths in a .pcm file, store the path toRichard Smith2014-12-051-73/+113
| | | | | | | | | | | | | | | the root of the module and use paths relative to that directory wherever possible. This is a step towards allowing explicit modules to be relocated without being rebuilt, which is important for some kinds of distributed builds, for good paths in diagnostics, and for appropriate .d output. This is a recommit of r223443, reverted in r223465; when joining together imported file paths, we now use the system's separator rather than always using '/'. This avoids path mismatches between the original module build and the module user on Windows (at least, in some cases). A more comprehensive fix will follow. llvm-svn: 223539
* Temporarily reverting r223443 due to bot breakage.Aaron Ballman2014-12-051-113/+73
| | | | llvm-svn: 223465
* [modules] Instead of storing absolute paths in a .pcm file, store the path toRichard Smith2014-12-051-73/+113
| | | | | | | | | the root of the module and use paths relative to that directory wherever possible. This is a step towards allowing explicit modules to be relocated without being rebuilt, which is important for some kinds of distributed builds, for good paths in diagnostics, and for appropriate .d output. llvm-svn: 223443
* [modules] Track how 'header' directives were written in module map files,Richard Smith2014-12-021-12/+19
| | | | | | | | | | | | | rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
* Update for LLVM API change to make Small(Ptr)Set::insert return ↵David Blaikie2014-11-191-1/+1
| | | | | | pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
* [OPENMP] Codegen for threadprivate variablesAlexey Bataev2014-11-111-0/+12
| | | | | | | | | For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
* Introduce a SanitizerKind enum to LangOptions.Alexey Samsonov2014-11-071-2/+3
| | | | | | | | | | | | | Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
* [modules] Support combining 'textual' with 'private'.Richard Smith2014-10-241-34/+24
| | | | llvm-svn: 220589
* Add a "signature" to AST files to verify that they haven't changedBen Langmuir2014-10-231-0/+16
| | | | | | | | | | | | | | | | | | | | | Since the order of the IDs in the AST file (e.g. DeclIDs, SelectorIDs) is not stable, it is not safe to load an AST file that depends on another AST file that has been rebuilt since the importer was built, even if "nothing changed". We previously used size and modtime to check this, but I've seen cases where a module rebuilt quickly enough to foil this check and caused very hard to debug build errors. To save cycles when we're loading the AST, we just generate a random nonce value and check that it hasn't changed when we load an imported module, rather than actually hash the whole file. This is slightly complicated by the fact that we need to verify the signature inside addModule, since we might otherwise consider that a mdoule is "OutOfDate" when really it is the importer that is out of date. I didn't see any regressions in module load time after this change. llvm-svn: 220493
* [modules] Add support for 'textual header' directives.Richard Smith2014-10-221-1/+13
| | | | | | | | This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
* Don't add ID mappings for offsets with no entities in a moduleBen Langmuir2014-10-201-12/+23
| | | | | | | | | | | This is a better fix for 'duplicate key' problems in module continuous range maps (vs what I added in r215810) by not adding any mappings at all when there are no local entities. Now it also covers selectors, which were not always being bumped because the record SELECTOR_OFFSET is not always emitted. I'll back out most of r215810 in a future commit, since it should no longer be needed. llvm-svn: 220207
* Rename TemplateArgument::getTypeForDecl to getParamTypeForDecl for clarityDavid Blaikie2014-10-171-1/+1
| | | | | | Code review feedback from Richard Smith on r219900. llvm-svn: 220060
* PR21246: DebugInfo: Emit the appropriate type (cv qualifiers, ↵David Blaikie2014-10-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | reference-ness, etc) for non-type template parameters Plumb through the full QualType of the TemplateArgument::Declaration, as it's insufficient to only know whether the type is a reference or pointer (that was necessary for mangling, but insufficient for debug info). This shouldn't increase the size of TemplateArgument as TemplateArgument::Integer is still longer by another 32 bits. Several bits of code were testing that the reference-ness of the parameters matched, but this seemed to be insufficient (various other features of the type could've mismatched and wouldn't've been caught) and unnecessary, at least insofar as removing those tests didn't cause anything to fail. (Richard - perchaps you can hypothesize why any of these checks might need to test reference-ness of the parameters (& explain why reference-ness is part of the mangling - I would've figured that for the reference-ness to be different, a prior template argument would have to be different). I'd be happy to add them in/beef them up and add test cases if there's a reason for them) llvm-svn: 219900
* PR20399: Do not assert when adding an implicit member coming from a module atRichard Smith2014-09-301-6/+5
| | | | | | | | writing time. Patch by Vassil Vassilev! llvm-svn: 218651
* -ms-extensions: Implement __super scope specifier (PR13236).Nikola Smiljanic2014-09-261-0/+9
| | | | | | | | | We build a NestedNameSpecifier that records the CXXRecordDecl in which __super appeared. Name lookup is performed in all base classes of the recorded CXXRecordDecl. Use of __super is allowed only inside class and member function scope. llvm-svn: 218484
OpenPOWER on IntegriCloud