summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInstance.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [modules] Initial support for explicitly loading .pcm files.Richard Smith2014-10-221-3/+51
| | | | | | | | | | | | | | | Implicit module builds are not well-suited to a lot of build systems. In particular, they fare badly in distributed build systems, and they lead to build artifacts that are not tracked as part of the usual dependency management process. This change allows explicitly-built module files (which are already supported through the -emit-module flag) to be explicitly loaded into a build, allowing build systems to opt to manage module builds and dependencies themselves. This is only the first step in supporting such configurations, and it should be considered experimental and subject to change or removal for now. llvm-svn: 220359
* Extend -Rmodule-build to also remark when module building finishes.Richard Smith2014-10-141-4/+9
| | | | | | | In cases of nested module builds, or when you care how long module builds take, this information was not previously easily available / obvious. llvm-svn: 219658
* Ensure that all module build failures get diagnosedBen Langmuir2014-09-261-2/+11
| | | | | | | | Otherwise we can end up silently skipping an import. If we happen to be building another module at the time, we may build a mysteriously broken module and not know why it seems to be missing symbols. llvm-svn: 218552
* unique_ptrify ChainedDiagnosticConsumer's ctor parametersDavid Blaikie2014-09-151-6/+11
| | | | llvm-svn: 217793
* Fix memory leak of raw_ostreams in LogDiagnosticPrinter handling.David Blaikie2014-09-151-7/+7
| | | | | | | | | | | | | | | This is another case of conditional ownership (in this case a raw reference, plus a boolean to indicate whether the referenced object should be deleted). While it's not ideal, I prefer to make the ownership explicit with a unique_ptr than using a boolean flag (though it does make the reference and the unique_ptr redundant in the sense that they both refer to the same memory). At some point we might write a reusable conditional ownership pointer (a stateful custom deleter for a unique_ptr may be appropriate). Based on a patch from a patch by Anton Yartsev. llvm-svn: 217791
* unique_ptrify the raw_ostream argument to clang::serialized_diags::createDavid Blaikie2014-08-291-4/+3
| | | | llvm-svn: 216767
* Provide a BuryPointer for unique_ptrs.David Blaikie2014-08-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, it'd be nice if we could move to a case where all buried pointers were buried via unique_ptr to demonstrate that the program had finished with the value (that we could really have cleanly deallocated it) but instead chose to bury it. I think the main reason that's not possible right now is the various IntrusiveRefCntPtrs in the Frontend, sharing ownership for a variety of compiler bits (see the various similar "CompilerInstance::releaseAndLeak*" functions). I have yet to figure out their correct ownership semantics - but perhaps, even if the intrusiveness can be removed, the shared ownership may yet remain and that would lead to a non-unique burying as is there today. (though we could model that a little better - by passing in a shared_ptr, etc - rather than needing the two step that's currently used in those other releaseAndLeak* functions) This might be a bit more robust if BuryPointer took the boolean: BuryPointer(bool, unique_ptr<T>) and the choice to bury was made internally - that way, even when DisableFree was not set, the unique_ptr would still be null in the caller and there'd be no chance of accidentally having a different codepath where the value is used after burial in !DisableFree, but it becomes null only in DisableFree, etc... llvm-svn: 216742
* unique_ptrify SourceManager::createFileIDDavid Blaikie2014-08-291-1/+2
| | | | llvm-svn: 216715
* Overload SourceManager::overrideFileContents so that unconditionally passing ↵David Blaikie2014-08-271-3/+3
| | | | | | | | | | ownership is explicitly done using unique_ptr. Only those callers who are dynamically passing ownership should need the 3 argument form. Those accepting the default ("do pass ownership") should do so explicitly with a unique_ptr now. llvm-svn: 216614
* Update for LLVM api change.Rafael Espindola2014-08-271-2/+2
| | | | llvm-svn: 216585
* Add support for the static analyzer to synthesize function implementations ↵Ted Kremenek2014-08-271-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from external model files. Currently the analyzer lazily models some functions using 'BodyFarm', which constructs a fake function implementation that the analyzer can simulate that approximates the semantics of the function when it is called. BodyFarm does this by constructing the AST for such definitions on-the-fly. One strength of BodyFarm is that all symbols and types referenced by synthesized function bodies are contextual adapted to the containing translation unit. The downside is that these ASTs are hardcoded in Clang's own source code. A more scalable model is to allow these models to be defined as source code in separate "model" files and have the analyzer use those definitions lazily when a function body is needed. Among other things, it will allow more customization of the analyzer for specific APIs and platforms. This patch provides the initial infrastructure for this feature. It extends BodyFarm to use an abstract API 'CodeInjector' that can be used to synthesize function bodies. That 'CodeInjector' is implemented using a new 'ModelInjector' in libFrontend, which lazily parses a model file and injects the ASTs into the current translation unit. Models are currently found by specifying a 'model-path' as an analyzer option; if no path is specified the CodeInjector is not used, thus defaulting to the current behavior in the analyzer. Models currently contain a single function definition, and can be found by finding the file <function name>.model. This is an initial starting point for something more rich, but it bootstraps this feature for future evolution. This patch was contributed by Gábor Horváth as part of his Google Summer of Code project. Some notes: - This introduces the notion of a "model file" into FrontendAction and the Preprocessor. This nomenclature is specific to the static analyzer, but possibly could be generalized. Essentially these are sources pulled in exogenously from the principal translation. Preprocessor gets a 'InitializeForModelFile' and 'FinalizeForModelFile' which could possibly be hoisted out of Preprocessor if Preprocessor exposed a new API to change the PragmaHandlers and some other internal pieces. This can be revisited. FrontendAction gets a 'isModelParsingAction()' predicate function used to allow a new FrontendAction to recycle the Preprocessor and ASTContext. This name could probably be made something more general (i.e., not tied to 'model files') at the expense of losing the intent of why it exists. This can be revisited. - This is a moderate sized patch; it has gone through some amount of offline code review. Most of the changes to the non-analyzer parts are fairly small, and would make little sense without the analyzer changes. - Most of the analyzer changes are plumbing, with the interesting behavior being introduced by ModelInjector.cpp and ModelConsumer.cpp. - The new functionality introduced by this change is off-by-default. It requires an analyzer config option to enable. llvm-svn: 216550
* Return a std::unique_ptr from getBufferForFile. NFC.Rafael Espindola2014-08-261-2/+2
| | | | llvm-svn: 216476
* Update for llvm api change.Rafael Espindola2014-08-251-36/+26
| | | | llvm-svn: 216397
* Revert r215331, "unique_ptrify CompilerInstance::OutputFile(s) and remove a ↵NAKAMURA Takumi2014-08-111-16/+14
| | | | | | | | | | | | | | | | | | | | | unique_ptr around a non-owning raw_ostream in CodeGenAction::CreateASTConsumer" It cannot be compiled on Visual Studio 2012. clang\include\clang/Frontend/CompilerInstance.h(153): error C2248: 'std::unique_ptr<_Ty>::unique_ptr' : cannot access private member declared in class 'std::unique_ptr<_Ty>' with [ _Ty=llvm::raw_ostream ] D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\memory(1447) : see declaration of 'std::unique_ptr<_Ty>::unique_ptr' with [ _Ty=llvm::raw_ostream ] This diagnostic occurred in the compiler generated function 'clang::CompilerInstance::OutputFile::OutputFile(const clang::CompilerInstance::OutputFile &)' llvm-svn: 215346
* unique_ptrify CompilerInstance::OutputFile(s) and remove a unique_ptr around ↵David Blaikie2014-08-101-14/+16
| | | | | | a non-owning raw_ostream in CodeGenAction::CreateASTConsumer llvm-svn: 215331
* Out-of-line CompilerInstance::takeSema to avoid a header dependence from ↵David Blaikie2014-08-101-1/+5
| | | | | | | | | CompilerInstance.h on Sema.h Hopefully this fixes the libstdc++ build on some of the buildbots after r215321. llvm-svn: 215325
* Recommit 213307: unique_ptr-ify ownership of ASTConsumers (reverted in r213325)David Blaikie2014-08-101-2/+2
| | | | | | | | After post-commit review and community discussion, this seems like a reasonable direction to continue, making ownership semantics explicit in the source using the type system. llvm-svn: 215323
* Refactor the module map file used for uniquing a module name out ofBen Langmuir2014-08-091-2/+3
| | | | | | | | | class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
* Add stopgap option -fmodule-implementation-of <name>Ben Langmuir2014-07-231-2/+8
| | | | | | | | | | | | | | | | | | This flag specifies that we are building an implementation file of the module <name>, preventing importing <name> as a module. This does not consider this to be the 'current module' for the purposes of doing modular checks like decluse or non-modular-include warnings, unlike -fmodule-name. This is needed as a stopgap until: 1) we can resolve relative includes to a VFS-mapped module (or can safely import a header textually and as part of a module) and ideally 2) we can safely do incremental rebuilding when implementation files import submodules. llvm-svn: 213767
* If a module build reports errors, don't try to load itBen Langmuir2014-07-191-13/+21
| | | | | | ... just to find out that it didn't build. llvm-svn: 213454
* Revert "unique_ptr-ify ownership of ASTConsumers"David Blaikie2014-07-171-2/+2
| | | | | | | | | This reverts commit r213307. Reverting to have some on-list discussion/confirmation about the ongoing direction of smart pointer usage in the LLVM project. llvm-svn: 213325
* unique_ptr-ify ownership of ASTConsumersDavid Blaikie2014-07-171-2/+2
| | | | | | | | | (after fixing a bug in MultiplexConsumer I noticed the ownership of the nested consumers was implemented with raw pointers - so this fixes that... and follows the source back to its origin pushing unique_ptr ownership up through there too) llvm-svn: 213307
* Peel away old-style file remapping typedefs and cruftAlp Toker2014-07-071-17/+10
| | | | llvm-svn: 212438
* Fix layering of file remapping and header search initializationAlp Toker2014-07-071-1/+67
| | | | | | | | These two functions initialize the source manager and header search objects and shouldn't be in InitPreprocessor which is concerned with priming the preprocessor itself and predefining macros. llvm-svn: 212434
* Update for llvm api change.Rafael Espindola2014-07-061-3/+6
| | | | llvm-svn: 212408
* Use non-intrusive refcounting for TargetOptionsAlp Toker2014-07-061-1/+2
| | | | llvm-svn: 212388
* Constify a read-only parameter and give function a better nameAlp Toker2014-07-061-1/+1
| | | | | | | This makes it clear that TargetInfo doesn't capture the LangOptions object, rather uses it to apply adjustments. llvm-svn: 212386
* Track IntrusiveRefCntPtr::get() changes from LLVM r212366Alp Toker2014-07-051-1/+1
| | | | llvm-svn: 212369
* Consider module depedencies when checking a preamble in libclangBen Langmuir2014-06-301-0/+6
| | | | | | | | | | | | | Add module dependencies (header files, module map files) to the list of files to check when deciding whether to rebuild a preamble. That fixes using preambles with module imports so long as they are in non-overridden files. My intent is to use to unify the existing dependency collectors to the new “DependencyCollectory” interface from this commit, starting with the DependencyFileGenerator. llvm-svn: 212060
* Remove 'const' from MemoryBuffers used through the SourceManagerDavid Blaikie2014-06-271-1/+1
| | | | | | | | | | | | | | This removes a const_cast added in r211884 that occurred due to an inconsistency in how MemoryBuffers are handled between some parts of clang and LLVM. MemoryBuffers are immutable and the general convention in the LLVM project is to omit const from immutable types as it's simply redundant/verbose (see llvm::Type, for example). While this change doesn't remove "const" from /every/ MemoryBuffer, it at least makes this chain of ownership/usage consistent. llvm-svn: 211915
* Frontend: Add a CC1 flag to dump module dependencies to a directoryJustin Bogner2014-06-191-0/+22
| | | | | | | | | | | | | | | | | | This adds the -module-dependency-dir to clang -cc1, which specifies a directory to copy all of a module's dependencies into in a form suitable to be used as a VFS using -ivfsoverlay with the generated vfs.yaml. This is useful for crashdumps that involve modules, so that the module dependencies will be intact when a crash report script is used to reproduce a problem on another machine. We currently encode the absolute path to the dump directory, due to limitations in the VFS system. Until we can handle relative paths in the VFS, users of the VFS map may need to run a simple search and replace in the file. llvm-svn: 211303
* Retry building modules that were compiled by other instances and are out-of-dateBen Langmuir2014-06-171-26/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When another clang instance builds a module, it may still be considered "out of date" for the current instance in a couple of cases*. This patch prevents us from giving spurious errors when compilers race to build a module by allowing the module load to fail when the pcm was built by a different compiler instance. * Cases where a module can be out of date despite just having been built: 1) There are different -I paths between invocations that result in finding a different module map file for some dependent module. This is not an error, and should never be diagnosed. <rdar://problem/16843887> 2) There are file system races where the headers making up a module are touched or moved. Although this can sometimes mean trouble, diagnosing it only during a build-race is worse than useless and we cannot detect this in general. It is more robust to just rebuild. This was causing spurious issues in some setups where only the modtime of headers was bumped during a build. <rdar://problem/16157638> llvm-svn: 211129
* Update for llvm api change.Rafael Espindola2014-06-131-1/+2
| | | | llvm-svn: 210921
* Include system_error directly.Rafael Espindola2014-06-121-1/+1
| | | | llvm-svn: 210802
* Replace llvm::error_code with std::error_code.Rafael Espindola2014-06-121-5/+5
| | | | llvm-svn: 210780
* Use std::error_code instead of llvm::error_code.Rafael Espindola2014-06-111-1/+1
| | | | | | This is an update for a llvm api change. llvm-svn: 210688
* Revert "Revert "Devise a package-private means to determine the LLVM version ↵Alp Toker2014-06-061-3/+2
| | | | | | | | | | | string"" We probably just need to touch LLVM's configure this time to work around the totally inadequate Makefile build server integration. This reverts commit r210314. llvm-svn: 210320
* Revert "Devise a package-private means to determine the LLVM version string"Alp Toker2014-06-061-2/+3
| | | | | | | | This didn't work out on the build servers. Investigating This reverts commit r210313. llvm-svn: 210314
* Devise a package-private means to determine the LLVM version stringAlp Toker2014-06-061-3/+2
| | | | | | | | | | This will unbreak clang vendor builds as a follow-up to r210238, now that we can't poke into LLVM's private config.h (nor should the string be exposed by llvm-config.h). This hopefully removes for good the last include of LLVM's config.h. llvm-svn: 210313
* Remove the last remaining llvm/Config/config.h includesAlp Toker2014-06-041-1/+2
| | | | | | | | | | | | This corrects long-standing misuses of LLVM's internal config.h. In most cases the public llvm-config.h header was intended and we can now remove the old hacks thanks to LLVM r210144. The config.h header is private, won't be installed and should no longer be included by clang or other modules. llvm-svn: 210145
* Fix leak from r210059Alp Toker2014-06-031-0/+6
| | | | | | | Also revert r210096 which temporarily disabled the test while this was being investigated. llvm-svn: 210115
* [C++11] Use 'nullptr'. Frontend edition.Craig Topper2014-05-221-17/+17
| | | | llvm-svn: 209389
* SourceManager: Use setMainFileID() consistentlyAlp Toker2014-05-211-3/+5
| | | | | | | | | | | Eliminate createMainFileID() / createMainFileIDForMemBuffer() utility functions. These didn't add much convenience and conflated two distinct operations. This change makes things easier to follow by providing a consistent interface and getting rid of a bunch of cast-to-voids. llvm-svn: 209266
* Switch Wmodule-build to a remarkBen Langmuir2014-05-081-1/+1
| | | | | | | | | On reflection, this is better despite the missing command-line handling bits for remarks. Making this a remark makes it much clearer that this is purely informational and avoids the negative connotations of a 'warning'. llvm-svn: 208367
* Let ASTReader optionally delete its ASTDeserializationListener.Nico Weber2014-05-081-22/+15
| | | | | | | | | | | | | | | | | | | | Use this to fix the leak of DeserializedDeclsDumper and DeserializedDeclsChecker in FrontendAction (found by LSan), PR19560. The "delete this" bool is necessary because both PCHGenerator and ASTUnit return the same object from both getDeserializationListener() and getASTMutationListener(), so ASTReader can't just have a unique_ptr. It's also not possible to just let FrontendAction (or CompilerInstance) own these listeners due to lifetime issues (see comments on PR19560). Finally, ASTDeserializationListener can't easily be refcounted, since several of the current listeners are allocated on the stack. Having this bool isn't ideal, but it's a pattern that's used in other places in the codebase too, and it seems better than leaking. llvm-svn: 208277
* Add -Wmodule-build to make it easy to see when modules are (re)builtBen Langmuir2014-05-051-0/+3
| | | | | | Warning is default ignore, and not in -Wall. llvm-svn: 207975
* Make module self-import an errorBen Langmuir2014-05-051-1/+1
| | | | | | | | Ideally, importing Foo.a from Foo.b would "do the right thing", but until it does, this patch makes it an error rather than allow it to silently be ignored. llvm-svn: 207948
* Eliminate ASTContext's DelayInitialization flagAlp Toker2014-05-031-3/+3
| | | | | | | | | Having various possible states of initialization following construction doesn't add value here. Also remove the unused size_reserve parameter. llvm-svn: 207897
* Reformat code following Preprocessor constructor updatesAlp Toker2014-05-021-4/+2
| | | | | | Landing this separately to make the previous commits easy to follow at home. llvm-svn: 207826
* Factor TargetInfo pointer/DelayInitialization bool pair out of Preprocessor ctorAlp Toker2014-05-021-2/+2
| | | | | | | | The Preprocessor::Initialize() function already offers a clear interface to achieve this, further reducing the confusing number of states a newly constructed preprocessor can have. llvm-svn: 207825
OpenPOWER on IntegriCloud