summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTWriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [PCH/Modules] De/Serialize MacroInfos separately than MacroDirectives.Argyrios Kyrtzidis2013-03-221-144/+275
| | | | | | | | | -Serialize the macro directives history into its own section -Get rid of the macro updates section -When de/serializing an identifier from a module, associate only one macro per submodule that defined+exported it. llvm-svn: 177761
* <rdar://problem/12368093> Extend module maps with a 'conflict' declaration, ↵Douglas Gregor2013-03-201-0/+17
| | | | | | and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
* Only introduce the SDKSettings.plist dependency in modules/PCH files that ↵Douglas Gregor2013-03-201-1/+1
| | | | | | don't depend on any other modules or PCH files. llvm-svn: 177542
* <rdar://problem/10796651> Introduce configuration macros into module maps.Douglas Gregor2013-03-201-0/+15
| | | | | | | | | | | | | | | | | | | | | | Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
* <rdar://problem/13363214> Eliminate race condition between module rebuild ↵Douglas Gregor2013-03-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | and the global module index. The global module index was querying the file manager for each of the module files it knows about at load time, to prune out any out-of-date information. The file manager would then cache the results of the stat() falls used to find that module file. Later, the same translation unit could end up trying to import one of the module files that had previously been ignored by the module cache, but after some other Clang instance rebuilt the module file to bring it up-to-date. The stale stat() results in the file manager would trigger a second rebuild of the already-up-to-date module, causing failures down the line. The global module index now lazily resolves its module file references to actual AST reader module files only after the module file has been loaded, eliminating the stat-caching race. Moreover, the AST reader can communicate to its caller that a module file is missing (rather than simply being out-of-date), allowing us to simplify the module-loading logic and allowing the compiler to recover if a dependent module file ends up getting deleted. llvm-svn: 177367
* [modules] Don't record the macros from the predefines buffer.Argyrios Kyrtzidis2013-03-151-1/+24
| | | | | | | These will be available in the current translation unit anyway, for modules they only waste space and deserialization time. llvm-svn: 177197
* <rdar://problem/13426257> Introduce SDKSettings.plist as an input file ↵Douglas Gregor2013-03-151-15/+46
| | | | | | | | | | | | | | | dependency for PCH/modules. When we're building a precompiled header or module against an SDK on Darwin, there will be a file SDKSettings.plist in the sysroot. Since stat()'ing every system header on which a module or PCH file depends is performance suicide, we instead stat() just SDKSettings.plist. This hack works well on Darwin; it's unclear how we want to handle this on other platforms. If there is a canonical file, we should use it; if not, we either have to take the performance hit of stat()'ing system headers repeatedly or roll the dice by not checking anything. llvm-svn: 177194
* [modules] Don't write the UnusedFileScopedDecls vector to the module file.Argyrios Kyrtzidis2013-03-141-2/+3
| | | | llvm-svn: 177001
* [modules] Check for delegating constructor cycles when building a module and ↵Argyrios Kyrtzidis2013-03-141-3/+6
| | | | | | don't write them out to the module file. llvm-svn: 177000
* [Modules] Don't eagerly load and associate all the module header files.Argyrios Kyrtzidis2013-03-131-5/+25
| | | | | | | | | | | | | | In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers in order to associate the FileEntries with their modules and support implicit module import. Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about the module that a header belongs to, and associate it with its module only when there is a request for loading the header info for a particular file. Part of rdar://13391765 llvm-svn: 176976
* [Modules] Resolve top-headers of modules lazily.Argyrios Kyrtzidis2013-03-131-2/+4
| | | | | | | | | | | This allows resolving top-header filenames of modules to FileEntries when we need them, not eagerly. Note that that this breaks ABI for libclang functions clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders but this is fine because they are experimental and not widely used yet. llvm-svn: 176975
* [PCH] When pre-validating the headers from the PCH, only validate non-system ↵Argyrios Kyrtzidis2013-03-061-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | headers. Stat'ing all the headers from the PCH to make sure they are up-to-date takes significant time. In a particular source file (whose PCH file included Cocoa.h) from total -fsyntax-only time 12% was just stat calls. Change pre-validation to only check non-system headers. There are some notable disadvantages: -If a system header, that is not include-guarded, changes after the PCH was created, we will not find it in the header info table and we will #import it, effectively #importing it twice, thus we will emit some error due to a multiple definition and after that the "header was modified" error will likely be emitted, for example something like: NSDictionary.h:12:1: error: duplicate interface definition for class 'NSDictionary' @interface NSDictionary : NSObject <NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration> ^ NSDictionary.h:12:12: note: previous definition is here @interface NSDictionary : NSObject <NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration> ^ fatal error: file 'NSDictionary.h' has been modified since the precompiled header was built Though we get the "header was modified" error, this is a bit confusing. -Theoretically it is possible that such a system header will cause no errors but it will just cause an unfortunate semantic change, though I find this rather unlikely. The advantages: -Reduces compilation time when using a huge PCH like the Cocoa ones -System headers change very infrequent and when they do, users/build systems should be able to know that re-building from scratch is needed. Addresses rdar://13056262 llvm-svn: 176567
* [PCH] For HeaderFileInfoTrait, hash the key using size & time of the file.Argyrios Kyrtzidis2013-03-061-16/+24
| | | | | | | | | | | | Previously the hash would be the filename portion of the path, which could be different for a filename with different case or a symbolic link with a different name completely. This did not actually create any issue so far because by validating all headers in the PCH we created uniqued FileEntries based on inodes, so an #include of a symbolic link (refering to a file from the PCH) would end up with a FileEntry with filename same as the one recorded in the PCH. llvm-svn: 176566
* [PCH] Remove building a SmallPtrSet that is not actually used for anything.Argyrios Kyrtzidis2013-03-011-2/+0
| | | | llvm-svn: 176354
* Comment parsing: add CommentOptions to allow specifying custom comment block ↵Dmitri Gribenko2013-02-221-0/+10
| | | | | | | | | | | | | | | | commands Add an ability to specify custom documentation block comment commands via a new class CommentOptions. The intention is that this class will hold future customizations for comment parsing, including defining documentation comments with specific numbers of parameters, etc. CommentOptions instance is a member of LangOptions. CommentOptions is controlled by a new command-line parameter -fcomment-block-commands=Foo,Bar,Baz. llvm-svn: 175892
* Include llvm::Optional in clang/Basic/LLVM.hDavid Blaikie2013-02-201-4/+4
| | | | | | Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
* [preprocessor] Split the MacroInfo class into two separate concepts, ↵Argyrios Kyrtzidis2013-02-201-27/+29
| | | | | | | | | | | | | | | | | | | | | | | | | MacroInfo class for the data specific to a macro definition (e.g. what the tokens are), and MacroDirective class which encapsulates the changes to the "macro namespace" (e.g. the location where the macro name became active, the location where it was undefined, etc.) (A MacroDirective always points to a MacroInfo object.) Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but splitting the concepts allows us to better model the effect of modules to the macro namespace (also as a bonus it allows better modeling of push_macro/pop_macro #pragmas). Modules can have their own macro history, separate from the local (current translation unit) macro history; MacroDirectives will be used to model the macro history (changes to macro namespace). For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created to indicate that "FOO" became active at the import location. Module "A" itself will contain another MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives will point to the same MacroInfo object. Introducing the separation of macro concepts is the first part towards better modeling of module macros. llvm-svn: 175585
* Ensure that the identifier chains have the most recent declaration after ↵Douglas Gregor2013-02-181-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | module deserialization. This commit introduces a set of related changes to ensure that the declaration that shows up in the identifier chain after deserializing declarations with a given identifier is, in fact, the most recent declaration. The primary change involves waiting until after we deserialize and wire up redeclaration chains before updating the identifier chains. There is a minor optimization in here to avoid recursively deserializing names as part of looking to see whether top-level declarations for a given name exist. A related change that became suddenly more urgent is to property record a merged declaration when an entity first declared in the current translation unit is later deserialized from a module (that had not been loaded at the time of the original declaration). Since we key off the canonical declaration (which is parsed, not from an AST file) for emitted redeclarations, we simply record this as a merged declaration during AST writing and let the readers merge them. Re-fixes <rdar://problem/13189985>, presumably for good this time. llvm-svn: 175447
* Always keep highest identifier, selector, and macro IDs when we'veDouglas Gregor2013-02-081-5/+21
| | | | | | read another one, just as we do for types. llvm-svn: 174745
* Remove dead code related to the now defunct PCH stat cache.Ted Kremenek2013-02-051-48/+0
| | | | llvm-svn: 174342
* Add a new -Wundefined-inline warning for inline functions which are used but notNick Lewycky2013-02-011-9/+9
| | | | | | defined. Fixes PR14993! llvm-svn: 174158
* Remove elements from Sema.UndefinedInternals as functions are defined. AlsoNick Lewycky2013-01-311-4/+5
| | | | | | | filter the elements before emitting them into a PCH. No user-visible functionality change, except that PCH files may be smaller? llvm-svn: 174034
* [Frontend] Remove HeaderSearchOptions::Entry::IsInternal, which is unused.Daniel Dunbar2013-01-301-1/+0
| | | | llvm-svn: 173866
* [Frontend] Add an ExternCSystem include entry group.Daniel Dunbar2013-01-301-1/+0
| | | | | | | | - The only group where it makes sense for the "ExternC" bit is System, so this simplifies having to have the extra isCXXAware (or ImplicitExternC, depending on what code you talk to) bit caried around. llvm-svn: 173859
* Preserve Sema::UndefinedInternals across PCH boundaries. FixesNick Lewycky2013-01-261-1/+16
| | | | | | -Wundefined-internal warnings with PCH. llvm-svn: 173538
* [Frontend] Remove another IsUserSpecified member variable that is now unused.Daniel Dunbar2013-01-251-1/+0
| | | | llvm-svn: 173412
* Introduce a fast path for the ASTReader's name lookup within aDouglas Gregor2013-01-211-0/+1
| | | | | | | | | DeclContext. When the DeclContext is of a kind that can only be defined once and never updated, we limit the search to the module file that conatins the lookup table. Provides a 15% speedup in one modules-heavy source file. llvm-svn: 173050
* [PCH/Modules] Revert r172843, it caused a module to fail building.Argyrios Kyrtzidis2013-01-191-12/+18
| | | | llvm-svn: 172884
* [PCH/Modules] Re-apply r172620 and r172629, now with 100% less infinite loops!Argyrios Kyrtzidis2013-01-181-18/+12
| | | | | | | | | Makes sure that a deserialized macro is only added to the preprocessor macro definitions only once. Unfortunately I couldn't get a reduced test case. rdar://13016031 llvm-svn: 172843
* [ubsan] Add support for -fsanitize-blacklistWill Dietz2013-01-181-0/+2
| | | | llvm-svn: 172808
* Revert Clang r172620 and r172629, which caused a hang when buildingDouglas Gregor2013-01-181-9/+16
| | | | | | | complicated modules (<rdar://problem/13038265>). Unfortunately, this un-fixes <rdar://problem/13016031>. llvm-svn: 172783
* Rework the traversal of Objective-C categories and extensions toDouglas Gregor2013-01-161-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | consider (sub)module visibility. The bulk of this change replaces myriad hand-rolled loops over the linked list of Objective-C categories/extensions attached to an interface declaration with loops using one of the four new category iterator kinds: visible_categories_iterator: Iterates over all visible categories and extensions, hiding any that have their "hidden" bit set. This is by far the most commonly used iterator. known_categories_iterator: Iterates over all categories and extensions, ignoring the "hidden" bit. This tends to be used for redeclaration-like traversals. visible_extensions_iterator: Iterates over all visible extensions, hiding any that have their "hidden" bit set. known_extensions_iterator: Iterates over all extensions, whether they are visible to normal name lookup or not. The effect of this change is that any uses of the visible_ iterators will respect module-import visibility. See the new tests for examples. Note that the old accessors for categories and extensions are gone; there are *Raw() forms for some of them, for those (few) areas of the compiler that have to manipulate the linked list of categories directly. This is generally discouraged. Part two of <rdar://problem/10634711>. llvm-svn: 172665
* [PCH/Modules] Change how macro [re]definitions are de/serialized.Argyrios Kyrtzidis2013-01-161-16/+9
| | | | | | | | | | | | | | | | | | Previously we would serialize the macro redefinitions as a list, part of the identifier, and try to chain them together across modules individually without having the info that they were already chained at definition time. Change this by serializing the macro redefinition chain and then try to synthesize the chain parts across modules. This allows us to correctly pinpoint when 2 different definitions are ambiguous because they came from unrelated modules. Fixes bogus "ambiguous expansion of macro" warning when a macro in a PCH is redefined without undef'ing it first. rdar://13016031 llvm-svn: 172620
* Fix CastingDavid Greene2013-01-151-1/+1
| | | | | | Make the const_cast explicit to silence a compiler warning. llvm-svn: 172560
* Implement parsing, AST, (de-)serialization, and placeholder globalDouglas Gregor2013-01-141-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
* Remove useless 'llvm::' qualifier from names like StringRef and others that areDmitri Gribenko2013-01-121-3/+3
| | | | | | brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
* Truth in advertising: LocallyScopedExternalDecls actually only containsRichard Smith2013-01-101-10/+10
| | | | | | external declarations with C language linkage. llvm-svn: 172150
* [PCH] (De)serialize the end location of MacroInfo.Argyrios Kyrtzidis2013-01-071-0/+1
| | | | llvm-svn: 171772
* updateOutOfDateIdentifier() can cause the identifier table to beDouglas Gregor2013-01-071-2/+10
| | | | | | | | rehashed, invaliding the iterator walking through the identifier table. Separate out the identification of out-of-date identifiers from updating them. llvm-svn: 171756
* Change DeclContextLookup(Const)Result to (Mutable)ArrayRef<NamedDecl*>, as ↵David Blaikie2012-12-191-7/+8
| | | | | | | | | | | | | | | per review discussion in r170365 This does limit these typedefs to being sequences, but no current usage requires them to be contiguous (we could expand this to a more general iterator pair range concept at some point). Also, it'd be nice if SmallVector were constructible directly from an ArrayRef but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the inverse conversion. (& generalizing over all range-like things, while nice, would require some nontrivial SFINAE I haven't thought about yet) llvm-svn: 170482
* [PCH] Make the new PCH format (control block) backwards compatible andArgyrios Kyrtzidis2012-12-131-0/+6
| | | | | | | | | | | | don't crash when loading a PCH with the older format. The introduction of the control block broke compatibility with PCHs from older versions. This patch allows loading (and rejecting) PCHs from an older version and allows newer PCHs to be rejected from older clang versions as well. rdar://12821386 llvm-svn: 170150
* [PCH] When writing out the list of input files, avoid emitting duplicateArgyrios Kyrtzidis2012-12-111-1/+6
| | | | | | | | | entries of the same file. This can happen because the file was "included" multiple times and is referenced by multiple SLocEntries. llvm-svn: 169829
* Finish implementing 'selected constructor' rules for triviality in C++11. InRichard Smith2012-12-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
* Implement C++03 [dcl.init]p5's checking for value-initialization of referencesRichard Smith2012-12-081-0/+1
| | | | | | | | properly, rather than faking it up by pretending that a reference member makes the default constructor non-trivial. That leads to rejects-valids when putting such types inside unions. llvm-svn: 169662
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-10/+10
| | | | | | | | | | | | | uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
* Refactor to reduce duplication in handling of special member functions. No ↵Richard Smith2012-11-301-18/+4
| | | | | | functionality change. llvm-svn: 168977
* Store on the CXXRecordDecl whether the class has, or would have, a copyRichard Smith2012-11-281-0/+4
| | | | | | | constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
* Introduce ASTUnresolvedSet, an UnresolvedSet-like class, whose contents areArgyrios Kyrtzidis2012-11-281-2/+2
| | | | | | | | | | | allocated using the allocator associated with an ASTContext. Use this inside CXXRecordDecl::DefinitionData instead of an UnresolvedSet to avoid a potential memory leak. rdar://12761275 llvm-svn: 168771
* [modules] Use a memory buffer directly as input for the module includes,Argyrios Kyrtzidis2012-11-151-0/+5
| | | | | | instead of messing with virtual files. llvm-svn: 168062
* [modules] Setup the import location of a module file and use itArgyrios Kyrtzidis2012-11-151-1/+1
| | | | | | as the include location of the main file of an imported module. llvm-svn: 168061
OpenPOWER on IntegriCloud