summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInstance.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [modules] If the same .pcm file is imported via two different paths, don'tRichard Smith2014-12-091-1/+3
| | | | | | complain that the contained modules are defined twice. llvm-svn: 223724
* PR21217: Slightly more eagerly load -fmodule-map-file= files and provideRichard Smith2014-12-061-0/+8
| | | | | | diagnostics if they don't exist. Based on a patch by John Thompson! llvm-svn: 223561
* [modules] Track how 'header' directives were written in module map files,Richard Smith2014-12-021-2/+9
| | | | | | | | | | | | | rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
* Make DiagnosticsEngine::takeClient return std::unique_ptr<>Alexander Kornienko2014-11-171-5/+3
| | | | | | | | | | | | | | | | | | Summary: Make DiagnosticsEngine::takeClient return std::unique_ptr<>. Updated callers to store conditional ownership using a pair of pointer and unique_ptr instead of a pointer + bool. Updated code that temporarily registers clients to use the non-owning registration (+ removed extra calls to takeClient). Reviewers: dblaikie Reviewed By: dblaikie Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6294 llvm-svn: 222193
* A small correction for r221884. No functional changes.Alexander Kornienko2014-11-171-1/+1
| | | | llvm-svn: 222130
* Support non-owned DiagnosticConsumer in SetupSerializedDiagnosticsAlexander Kornienko2014-11-131-4/+8
| | | | | | | | | | This fixes an assertion when running clang-tidy on a file having --serialize-diagnostics in compiler options. Committing a regression test for clang-tidy separately. Patch by Aaron Wishnick! llvm-svn: 221884
* [modules] Load .pcm files specified by -fmodule-file lazily.Richard Smith2014-10-271-44/+67
| | | | llvm-svn: 220731
* Make VFS and FileManager match the current MemoryBuffer API.Benjamin Kramer2014-10-261-6/+6
| | | | | | | This eliminates converting back and forth between the 3 formats and gives us a more homogeneous interface. llvm-svn: 220657
* Driver: Include driver diagnostics when we --serialize-diagnosticsJustin Bogner2014-10-231-11/+1
| | | | | | | | | | | | | | | Currently, when --serialize-diagnostics is passed this only includes the diagnostics from clang -cc1, and driver diagnostics are dropped. This causes issues for tools that use the serialized diagnostics, since stderr is lost and these diagnostics aren't seen at all. We handle this by merging the diagnostics from the CC1 process and the driver diagnostics into a single file when the driver invokes CC1. Fixes rdar://problem/10585062 llvm-svn: 220525
* [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
OpenPOWER on IntegriCloud