summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization
Commit message (Collapse)AuthorAgeFilesLines
...
* [modules] Before marking the module imported macros as ambiguous, check if ↵Argyrios Kyrtzidis2013-03-271-11/+57
| | | | | | | | | | | | | this is a case where the system macro uses a not identical definition compared to a macro from the clang headers. For example (these come from different modules): \#define LONG_MAX __LONG_MAX__ (clang's limits.h) \#define LONG_MAX 0x7fffffffffffffffL (system's limits.h) in which case don't mark them ambiguous to avoid the "ambiguous macro expansion" warning. llvm-svn: 178109
* [PCH/modules] Remove HiddenName::MacroUndefArgyrios Kyrtzidis2013-03-271-5/+0
| | | | llvm-svn: 178107
* [Preprocessor] Remove PPMutationListener.Argyrios Kyrtzidis2013-03-272-5/+1
| | | | | | It's not used anymore. llvm-svn: 178106
* [Preprocessor/Modules] Separate the macro directives kinds into their own ↵Argyrios Kyrtzidis2013-03-262-82/+123
| | | | | | | | | | | | | | | | 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-222-279/+454
| | | | | | | | | -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
* [modules] When a MacroInfo object is deserialized, allocate and store its ↵Argyrios Kyrtzidis2013-03-221-1/+1
| | | | | | submodule ID. llvm-svn: 177760
* <rdar://problem/13479539> Simplify ModuleManager/GlobalModuleIndex ↵Douglas Gregor2013-03-223-113/+55
| | | | | | | | | | | | | | interaction to eliminate a pile of extraneous stats(). The refactoring in r177367 introduced a serious performance bug where the "lazy" resolution of module file names in the global module index to actual module file entries in the module manager would perform repeated negative stats(). The new interaction requires the module manager to inform the global module index when a module file has been loaded, eliminating the extraneous stat()s and a bunch of bookkeeping on both sides. llvm-svn: 177750
* OpenMP threadprivate directive parsing and semantic analysisAlexey Bataev2013-03-223-0/+27
| | | | llvm-svn: 177705
* Remove unused variable.Benjamin Kramer2013-03-211-3/+0
| | | | llvm-svn: 177657
* <rdar://problem/12368093> Extend module maps with a 'conflict' declaration, ↵Douglas Gregor2013-03-202-18/+85
| | | | | | 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
* Make sure that Module::ConfigMacrosExhaustive gets initialized and ↵Douglas Gregor2013-03-201-3/+6
| | | | | | | | | deserialized correctly. This fixes regressions introduced in r177466 that caused several module tests to fail sporadically. llvm-svn: 177481
* <rdar://problem/10796651> Introduce configuration macros into module maps.Douglas Gregor2013-03-202-0/+27
| | | | | | | | | | | | | | | | | | | | | | 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
* Minor optimization to r177367 to treat a module with missing dependencies as ↵Douglas Gregor2013-03-191-1/+1
| | | | | | out-of-date rather than missing. llvm-svn: 177369
* <rdar://problem/13363214> Eliminate race condition between module rebuild ↵Douglas Gregor2013-03-194-185/+265
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PCH] Fix assertion hit related to enum decls inside templated funtions.Argyrios Kyrtzidis2013-03-181-0/+1
| | | | | | | Report and suggested fix by Tom Honermann! http://llvm.org/bugs/show_bug.cgi?id=13020 llvm-svn: 177330
* [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-132-20/+47
| | | | | | | | | | | | | | 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-132-5/+5
| | | | | | | | | | | 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
* ArrayRef-ize ASTContext::getFunctionType and Sema::BuildFunctionType.Jordan Rose2013-03-081-2/+1
| | | | | | No (intended) functionality change. llvm-svn: 176726
* [PCH] When complaining that a header from the PCH was modified, also mentionArgyrios Kyrtzidis2013-03-081-1/+1
| | | | | | the filename of the PCH file. llvm-svn: 176717
* [libclang] Introduce clang_findIncludesInFile, that can be used to retrieve ↵Argyrios Kyrtzidis2013-03-081-2/+2
| | | | | | | | | all #import/#include directives in a specific file. It passes to the visitor, that the caller provides, CXCursor_InclusionDirective cursors for all the include directives in a particular file. llvm-svn: 176682
* [PCH] When pre-validating the headers from the PCH, only validate non-system ↵Argyrios Kyrtzidis2013-03-062-4/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-063-40/+66
| | | | | | | | | | | | 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] We don't need to instantiate HeaderFileInfoTrait in ASTReader more ↵Argyrios Kyrtzidis2013-03-062-12/+5
| | | | | | | | than once. We can just re-use the one from HeaderFileInfoLookupTable. llvm-svn: 176565
* [PCH] Remove a couple of fields from ↵Argyrios Kyrtzidis2013-03-062-8/+3
| | | | | | serialization::reader::HeaderFileInfoTrait that are not used for anything. llvm-svn: 176564
* [PCH] In HeaderFileInfoTrait::EqualKey(), use FileManager::getFile() to ↵Argyrios Kyrtzidis2013-03-041-5/+4
| | | | | | | | | compare two filenames, instead of llvm::sys::fs::equivalent(). llvm::sys::fs::equivalent() does 2 stat calls every time it's called. Use FileManager::getFile() to take advantage of the stat caching that FileManager is providing. llvm-svn: 176450
* [PCH] Remove building a SmallPtrSet that is not actually used for anything.Argyrios Kyrtzidis2013-03-011-2/+0
| | | | llvm-svn: 176354
* [PCH] Enhance InputFile to also include whether the file is out-of-date.Argyrios Kyrtzidis2013-03-011-20/+24
| | | | | | | Previously we would return null for an out-of-date file. This inhibited ASTReader::ReadSLocEntry from creating a FileID to recover gracefully in such a case. llvm-svn: 176332
* [PCH] When deserializing an IdentifierInfo, call ↵Argyrios Kyrtzidis2013-02-271-1/+1
| | | | | | | | | IdentifierInfo::RevertTokenIDToIdentifier() only when it's not already an identifier. Fixes an assertion hit. rdar://13288735 llvm-svn: 176148
* objective-C arg: provide fixit support whenFariborz Jahanian2013-02-222-0/+3
| | | | | | | c++'s named cast need be replaced for bridge casting. // rdar://12788838 llvm-svn: 175923
* [preprocessing record] Have the MacroDefinitions map point to the ↵Argyrios Kyrtzidis2013-02-221-2/+6
| | | | | | | | | | MacroDefinition object instead its index in the preprocessed entities vector. This is because the order of the entities in the vector can change in some (uncommon) cases. llvm-svn: 175907
* [Sema] Semantic analysis for empty-declaration and attribute-declaration.Michael Han2013-02-223-0/+15
| | | | | | | | Introduce a new AST Decl node "EmptyDecl" to model empty-declaration. Have attributes from attribute-declaration appertain to the EmptyDecl node by creating the AST representations of these attributes and attach them to the EmptyDecl node so these attributes can be sema checked just as attributes attached to "normal" declarations. llvm-svn: 175900
* Comment parsing: add CommentOptions to allow specifying custom comment block ↵Dmitri Gribenko2013-02-222-0/+27
| | | | | | | | | | | | | | | | 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-202-10/+10
| | | | | | Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
* [preprocessor] Split the MacroInfo class into two separate concepts, ↵Argyrios Kyrtzidis2013-02-202-52/+56
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [modules] Refactor code from ASTReader::makeModuleVisible() into a new function,Argyrios Kyrtzidis2013-02-191-53/+7
| | | | | | Module::getExportedModules() so it can be reused. llvm-svn: 175548
* Use MapVector::pop_back() per LLVM r175538.Douglas Gregor2013-02-191-1/+1
| | | | llvm-svn: 175539
* Ensure that the identifier chains have the most recent declaration after ↵Douglas Gregor2013-02-183-18/+73
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PCH] Deserializing the DeclContext of a template parameter is not safeArgyrios Kyrtzidis2013-02-162-14/+16
| | | | | | | | | | | until recursive loading is finished. Otherwise we may end up with a template trying to deserialize a template parameter that is in the process of getting loaded. rdar://13135282 llvm-svn: 175329
* Order the methods in the global method pool based on when they become ↵Douglas Gregor2013-02-121-3/+40
| | | | | | visible, not when they become deserialized <rdar://problem/13203033>. llvm-svn: 175018
* Fix a bug reduced from a crash when trying to use modules with libc++. We checkRichard Smith2013-02-122-0/+8
| | | | | | | | the linkage of functions and variables while merging declarations from modules, and we don't necessarily have enough of the rest of the AST loaded at that point to allow us to compute linkage, so serialize it instead. llvm-svn: 174943
* [Modules] Cope better with top-level declarations loaded after being ↵Douglas Gregor2013-02-111-3/+23
| | | | | | | | | | | | | | | | | | | | declared in the current translation unit <rdar://problem/13189985>. These two related tweaks to keep the information associated with a given identifier correct when the identifier has been given some top-level information (say, a top-level declaration) and more information is then loaded from a module. The first ensures that an identifier that was "interesting" before being loaded from an AST is considered to be different from its on-disk counterpart. Otherwise, we lose such changes when writing the current translation unit as a module. Second, teach the code that injects AST-loaded names into the identifier chain for name lookup to keep the most recent declaration, so that we don't end up confusing our declaration chains by having a different declaration in there. llvm-svn: 174895
* 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
* Never cache the result of a module file lookup.Douglas Gregor2013-02-082-5/+11
| | | | llvm-svn: 174744
* Add OpenCL samplers as Clang builtin types and check sampler related ↵Guy Benyei2013-02-072-0/+2
| | | | | | restrictions. llvm-svn: 174601
* Fix handling of module imports adding names to a DeclContext after qualifiedRichard Smith2013-02-071-4/+11
| | | | | | | | | | | | | | | | name lookup has been performed in that context (this probably only happens in C++). 1) Whenever we add names to a context, set a flag on it, and if we perform lookup and discover that the context has had a lookup table built but has the flag set, update all entries in the lookup table with additional names from the external source. 2) When marking a DeclContext as having external visible decls, mark the context in which lookup is performed, not the one we are adding. These won't be the same if we're adding another copy of a pre-existing namespace. llvm-svn: 174577
OpenPOWER on IntegriCloud