summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInstance.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update for llvm::sys::fs::unique_file not creating directories.Rafael Espindola2013-06-281-13/+21
| | | | llvm-svn: 185127
* Small improvements to createOutputFile.Rafael Espindola2013-06-271-25/+41
| | | | | | | | * Use a single stat to find out if the file exists and if it is a regular file. * Use early returns when possible. * Add comments explaining why we have each check. llvm-svn: 185091
* Remove PathV1.h from CompilerInstance.cpp.Rafael Espindola2013-06-261-8/+6
| | | | llvm-svn: 184913
* [Modules] If a module map resides in a system header directory, treat it as ↵Douglas Gregor2013-06-211-1/+1
| | | | | | | | | a system module. This prevents -pedantic from causing warnings in the system headers used to create modules. Fixes <rdar://problem/14201171>. llvm-svn: 184560
* Use llvm::sys::fs::can_write.Rafael Espindola2013-06-181-1/+2
| | | | llvm-svn: 184234
* Don't depend on the transitive inclusion of PathV1.h.Rafael Espindola2013-06-131-0/+1
| | | | llvm-svn: 183945
* Use the sys::RemoveFileOnSignal that takes a StringRef.Rafael Espindola2013-06-131-1/+1
| | | | llvm-svn: 183944
* Use the global functions instead of the Program methods.Rafael Espindola2013-06-121-1/+1
| | | | llvm-svn: 183861
* [modules] If we hit a failure while loading a PCH/module, abort parsing ↵Argyrios Kyrtzidis2013-05-241-0/+2
| | | | | | | | | | instead of trying to continue in an invalid state. Also don't let libclang create a PCH with such an error. Fixes rdar://13953768 llvm-svn: 182629
* Remove DiagnosticConsumer::clone(), a bad idea that is now unused.Douglas Gregor2013-05-031-11/+4
| | | | llvm-svn: 181070
* When building a module, forward diagnostics to the outer diagnostic consumer.Douglas Gregor2013-05-031-2/+5
| | | | | | | | | | | | | | | Previously, we would clone the current diagnostic consumer to produce a new diagnostic consumer to use when building a module. The problem here is that we end up losing diagnostics for important diagnostic consumers, such as serialized diagnostics (where we'd end up with two diagnostic consumers writing the same output file). With forwarding, the diagnostics from all of the different modules being built get forwarded to the one serialized-diagnostic consumer and are emitted in a sane way. Fixes <rdar://problem/13663996>. llvm-svn: 181067
* Remove the unused MemoryBuffers, no functionality change.Argyrios Kyrtzidis2013-04-041-8/+0
| | | | llvm-svn: 178780
* [preprocessor] Allow comparing two macro definitions syntactically instead ↵Argyrios Kyrtzidis2013-04-031-1/+2
| | | | | | | | | | | | | | of only lexically. Syntactically means the function macro parameter names do not need to use the same identifiers in order for the definitions to be considered identical. Syntactic equivalence is a microsoft extension for macro redefinitions and we'll also use this kind of comparison to check for ambiguous macros coming from modules. rdar://13562254 llvm-svn: 178671
* Use getPredefinesFileID() appropriately.Douglas Gregor2013-04-031-2/+2
| | | | | | Thanks to Argyrios for the pointer. llvm-svn: 178616
* Remove sign-compare warning on systems that still use 32 bit time_ts.Benjamin Kramer2013-03-291-4/+4
| | | | llvm-svn: 178351
* [Preprocessor] Remove PPMutationListener.Argyrios Kyrtzidis2013-03-271-2/+0
| | | | | | It's not used anymore. llvm-svn: 178106
* [Preprocessor/Modules] Separate the macro directives kinds into their own ↵Argyrios Kyrtzidis2013-03-261-18/+21
| | | | | | | | | | | | | | | | 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
* Use <time.h> rather than <sys/time.h>Douglas Gregor2013-03-251-1/+1
| | | | llvm-svn: 177924
* <rdar://problem/13434605> Periodically prune the module cache so that it ↵Douglas Gregor2013-03-251-0/+101
| | | | | | does not grow forever. llvm-svn: 177918
* <rdar://problem/13479539> Only rebuild the global module cache when we're ↵Douglas Gregor2013-03-221-1/+2
| | | | | | | | allowed to. This eliminates excessive rebuilds of the global module cache. llvm-svn: 177766
* <rdar://problem/12368093> Extend module maps with a 'conflict' declaration, ↵Douglas Gregor2013-03-201-4/+6
| | | | | | and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
* <rdar://problem/10796651> Introduce configuration macros into module maps.Douglas Gregor2013-03-201-1/+98
| | | | | | | | | | | | | | | | | | | | | | 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-101/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Never cache the result of a module file lookup.Douglas Gregor2013-02-081-3/+4
| | | | llvm-svn: 174744
* Be a little more permissive with -fmodules-ignore-macro= by removing ↵Douglas Gregor2013-02-071-7/+2
| | | | | | everything after the second '=' if it is there. llvm-svn: 174567
* Introduce -fmodules-ignore-macro=NNN to ignore a macro when building/loading ↵Douglas Gregor2013-02-071-0/+30
| | | | | | | | | | | | | | | | | | | | | modules. The use of this flag enables a modules optimization where a given set of macros can be labeled as "ignored" by the modules system. Definitions of those macros will be completely ignored when building the module hash and will be stripped when actually building modules. The overall effect is that this flag can be used to drastically reduce the number of Eventually, we'll want modules to tell us what set of macros they respond to (the "configuration macros"), and anything not in that set will be excluded. However, that requires a lot of per-module information that must be accurate, whereas this option can be used more readily. Fixes the rest of <rdar://problem/13165109>. llvm-svn: 174560
* Detect when we end up trying to load conflicting module files.Douglas Gregor2013-02-061-3/+18
| | | | | | | | | | | | This can happen when one abuses precompiled headers by passing more -D options when using a precompiled hedaer than when it was built. This is intentionally permitted by precompiled headers (and is exploited by some build environments), but causes problems for modules. First part of <rdar://problem/13165109>, detecting when something when horribly wrong. llvm-svn: 174554
* For ModuleLoader::makeModuleVisible() also pass the source location where theArgyrios Kyrtzidis2013-02-011-4/+6
| | | | | | module import occurred. llvm-svn: 174191
* Don't warn about Unicode characters in -E mode.Jordan Rose2013-01-301-0/+2
| | | | | | | | | | | | | | | People use the C preprocessor for things other than C files. Some of them have Unicode characters. We shouldn't warn about Unicode characters appearing outside of identifiers in this case. There's not currently a way for the preprocessor to tell if it's in -E mode, so I added a new flag, derived from the PreprocessorOutputOptions. This is only used by the Unicode warnings for now, but could conceivably be used by other warnings or even behavioral differences later. <rdar://problem/13107323> llvm-svn: 173881
* Implement the reader of the global module index and wire it into theDouglas Gregor2013-01-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | AST reader. The global module index tracks all of the identifiers known to a set of module files. Lookup of those identifiers looks first in the global module index, which returns the set of module files in which that identifier can be found. The AST reader only needs to look into those module files and any module files not known to the global index (e.g., because they were (re)built after the global index), reducing the number of on-disk hash tables to visit. For an example source I'm looking at, we go from 237844 total identifier lookups into on-disk hash tables down to 126817. Unfortunately, this does not translate into a performance advantage. At best, it's a wash once the global module index has been built, but that's ignore the cost of building the global module index (which is itself fairly large). Profiles show that the global module index code is far less efficient than it should be; optimizing it might give enough of an advantage to justify its continued inclusion. llvm-svn: 173405
* Rename the -cc1 option "-generate-module-index" toDouglas Gregor2013-01-251-8/+21
| | | | | | | "-fmodules-global-index" and expand its behavior to include both the use and generation of the global module index. llvm-svn: 173404
* Implement the writer side of the global module index. Douglas Gregor2013-01-231-1/+9
| | | | | | | | | | | | | | | | | | | | The global module index is a "global" index for all of the module files within a particular subdirectory in the module cache, which keeps track of all of the "interesting" identifiers and selectors known in each of the module files. One can perform a fast lookup in the index to determine which module files will have more information about entities with a particular name/selector. This information can help eliminate redundant lookups into module files (a serious performance problem) and help with creating auto-import/auto-include Fix-Its. The global module index is created or updated at the end of a translation unit that has triggered a (re)build of a module by scraping all of the .pcm files out of the module cache subdirectory, so it catches everything. As with module rebuilds, we use the file system's atomicity to synchronize. llvm-svn: 173301
* Nuke SetUpBuildDumpLog.Sean Silva2013-01-201-32/+3
| | | | | | | Also, it was the only reason that `argc` and `argv` were being passed into createDiagnostics, so remove those parameters and clean up callers. llvm-svn: 172945
* Fix what appears to be a copy-paste error.Sean Silva2013-01-201-1/+1
| | | | | | | | | | This looks like it was copied from SetUpBuildDumpLog, which dumps to the file `DiagOpts->DumpBuildInformation`. There is another member `DiagOpts->DiagnosticLogFile` which appears to be unused. The fact that this feature doesn't even print to the output file specified on the command line makes me think that it should be ripped out. llvm-svn: 172944
* Remove useless 'llvm::' qualifier from names like StringRef and others that areDmitri Gribenko2013-01-121-1/+1
| | | | | | brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
* Provide Decl::getOwningModule(), which determines the (sub)module inDouglas Gregor2013-01-121-0/+6
| | | | | | | | | | | | | which a particular declaration resides. Use this information to customize the "definition of 'blah' must be imported from another module" diagnostic with the module the user actually has to import. Additionally, recover by importing that module, so we don't complain about other names in that module. Still TODO: coming up with decent Fix-Its for these cases, and expand this recovery approach for other name lookup failures. llvm-svn: 172290
* Be more careful about updating the failed-modules setDouglas Gregor2013-01-101-2/+3
| | | | llvm-svn: 172035
* Remove -Wmodule-build; it was a dumb idea anyway. <rdar://problem/12957525>Douglas Gregor2013-01-041-2/+0
| | | | llvm-svn: 171478
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-12/+12
| | | | | | | | | | | | | 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 recording the preprocessor conditional directive regions out ofArgyrios Kyrtzidis2012-12-041-1/+1
| | | | | | | | | PreprocessingRecord and into its own class, PPConditionalDirectiveRecord. Decoupling allows a client to use the functionality of PPConditionalDirectiveRecord without needing a PreprocessingRecord. llvm-svn: 169229
* Rename ModuleBuildPath -> ModuleBuildStack. Thanks, Dmitri!Douglas Gregor2012-11-301-6/+6
| | | | llvm-svn: 169045
* When an error occurs while building a module on demand, provide "WhileDouglas Gregor2012-11-301-14/+25
| | | | | | | | | building module 'Foo' imported from..." notes (the same we we provide "In file included from..." notes) in the diagnostic, so that we know how this module got included in the first place. This is part of <rdar://problem/12696425>. llvm-svn: 169021
* Keep track of modules that have failed to build. If we encounter anDouglas Gregor2012-11-291-18/+55
| | | | | | | | | | | | import of that module elsewhere, don't try to build the module again: it won't work, and the experience is quite dreadful. We track this information somewhat globally, shared among all of the related CompilerInvocations used to build modules on-the-fly, so that a particular Clang instance will only try to build a given module once. Fixes <rdar://problem/12552849>. llvm-svn: 168961
* Frontend: Create a virtual file for named pipe inputs.Daniel Dunbar2012-11-271-1/+5
| | | | | | - This ensures we see the right buffer size for the file. llvm-svn: 168636
* Since CreateTargetInfo is taking ownership of the target options, passDouglas Gregor2012-11-161-1/+1
| | | | | | it as a pointer. llvm-svn: 168136
* [modules] Setup the import location of a module file and use itArgyrios Kyrtzidis2012-11-151-2/+3
| | | | | | as the include location of the main file of an imported module. llvm-svn: 168061
* Add a FileCharacteristic parameter to SourceManager::createFileIDForMemBufferArgyrios Kyrtzidis2012-11-091-1/+9
| | | | | | | for completeness and use it in CompilerInstance::InitializeSourceManager if the input is a memory buffer. llvm-svn: 167628
* Turn FrontendInputFile into an immutable class and have it also acceptArgyrios Kyrtzidis2012-11-091-2/+2
| | | | | | a memory buffer instead of only a filename. llvm-svn: 167627
* Make CompilerInstance::InitializeSourceManager accept a FrontendInputFile,Argyrios Kyrtzidis2012-11-091-5/+7
| | | | | | no functionality change. llvm-svn: 167626
* When loading a module fails because it is out of date, rebuild thatDouglas Gregor2012-11-071-3/+26
| | | | | | module in place. <rdar://problem/10138913> llvm-svn: 167539
OpenPOWER on IntegriCloud