summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTWriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert r182331, these checks should be based on the target not the host.Richard Smith2013-05-201-4/+1
| | | | llvm-svn: 182333
* Move two Darwin-specific hacks into #ifdef __APPLE__. These were stat'ingRichard Smith2013-05-201-1/+4
| | | | | | nonexistent Darwin-specific files on every module build. llvm-svn: 182331
* First pass of semantic analysis for init-captures: check the initializer, buildRichard Smith2013-05-161-6/+19
| | | | | | | | | | | | | a FieldDecl from it, and propagate both into the closure type and the LambdaExpr. You can't do much useful with them yet -- you can't use them within the body of the lambda, because we don't have a representation for "the this of the lambda, not the this of the enclosing context". We also don't have support or a representation for a nested capture of an init-capture yet, which was intended to work despite not being allowed by the current standard wording. llvm-svn: 181985
* C++1y deduced return types: when we deduce a return type for a function whichRichard Smith2013-05-111-1/+20
| | | | | | | we loaded from PCH, if we're building another PCH, create an update record to patch the return type of the earlier declaration. llvm-svn: 181659
* [modules] When building a module, make sure we don't serialize out ↵Argyrios Kyrtzidis2013-05-081-0/+2
| | | | | | | | | | | HeaderFileInfo for headers not belonging to the module. After r180934 we may initiate module map parsing for modules not related to the module what we are building, make sure we ignore the header file info of headers from such modules. First part of rdar://13840148 llvm-svn: 181489
* Move parsing of identifiers in MS-style inline assembly intoJohn McCall2013-05-031-12/+14
| | | | | | | | | | | | | | | | | | | | | the actual parser and support arbitrary id-expressions. We're actually basically set up to do arbitrary expressions here if we wanted to. Assembly operands permit things like A::x to be written regardless of language mode, which forces us to embellish the evaluation context logic somewhat. The logic here under template instantiation is incorrect; we need to preserve the fact that an expression was unevaluated. Of course, template instantiation in general is fishy here because we have no way of delaying semantic analysis in the MC parser. It's all just fishy. I've also fixed the serialization of MS asm statements. This commit depends on an LLVM commit. llvm-svn: 180976
* Don't treat a non-deduced 'auto' type as being type-dependent. Instead, thereRichard Smith2013-04-301-0/+2
| | | | | | | | are now two distinct canonical 'AutoType's: one is the undeduced 'auto' placeholder type, and the other is a deduced-but-dependent type. All deduced-to-a-non-dependent-type cases are still non-canonical. llvm-svn: 180789
* [PCH/modules] Require the preprocessing record option to match the used PCH, ↵Argyrios Kyrtzidis2013-04-261-0/+2
| | | | | | | | | if modules are enabled. The preprocessing record becomes important when modules are enabled, since it is used to calculate the module cache hash. llvm-svn: 180635
* [Modules] Fix an issue where the reconstructed redeclaration chain was ↵Argyrios Kyrtzidis2013-04-261-1/+22
| | | | | | | | | | | | | incomplete, missing the definition from a module. -Make sure that a deserialized external decl gets added to the TU scope. -When associating an identifier with a set of decls, use the most recent local ones, if they exist, otherwise associating decls from modules (that came after a local one) will lead to an incomplete reconstructed re-declaration chain. rdar://13712705 llvm-svn: 180634
* Implement C++1y decltype(auto).Richard Smith2013-04-261-0/+1
| | | | llvm-svn: 180610
* Enhance the ObjC global method pool to record whether there were 0, 1, or >= ↵Argyrios Kyrtzidis2013-04-171-10/+17
| | | | | | | | | 2 methods (with a particular selector) inside categories. This is done by extending ObjCMethodList (which is only used by the global method pool) to have 2 extra bits of information. We will later take advantage of this info in global method pool for the overridden methods calculation. llvm-svn: 179652
* Basic support for Microsoft property declarations andJohn McCall2013-04-161-0/+1
| | | | | | | | references thereto. Patch by Tong Shen! llvm-svn: 179585
* Add an option to parse all comments as documentation commentsDmitri Gribenko2013-04-101-0/+1
| | | | | | Patch by Amin Shali. llvm-svn: 179180
* Pare back r164351 somewhat. The problem that change was addressing was that weRichard Smith2013-04-031-2/+0
| | | | | | | | don't serialize a lookup map for the translation unit outside C++ mode, so we can't tell when lookup within the TU needs to look within modules. Only apply the fix outside C++ mode, and only to the translation unit. llvm-svn: 178706
* [modules] If a submodule has re-definitions of the same macro, only the last ↵Argyrios Kyrtzidis2013-04-031-0/+6
| | | | | | | | definition will be used as the "exported" one. Fixes rdar://13562262 llvm-svn: 178622
* [modules] Make sure enabled diagnostic pragmas inside the module don't ↵Argyrios Kyrtzidis2013-03-271-3/+9
| | | | | | | | | | | | affect the translation unit that imports the module. Getting diagnostic sections from modules properly working is a fixme. rdar://13516663 llvm-svn: 178151
* [Preprocessor/Modules] Separate the macro directives kinds into their own ↵Argyrios Kyrtzidis2013-03-261-49/+87
| | | | | | | | | | | | | | | | MacroDirective's subclasses. For each macro directive (define, undefine, visibility) have a separate object that gets chained to the macro directive history. This has several benefits: -No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like PPMutationListener become unnecessary. -No need to keep extra source locations for the undef/visibility locations for the define directive object (which is the majority of the directives) -Much easier to hide/unhide a section in the macro directive history. -Easier to track the effects of the directives across different submodules. llvm-svn: 178037
* [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
OpenPOWER on IntegriCloud