summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInstance.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove many superfluous SmallString::str() calls.Yaron Keren2015-03-181-5/+4
| | | | | | | | | | | | | | | Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more. There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity. llvm-svn: 232622
* Make module files passed to a module build via -fmodule-file= available toRichard Smith2015-03-181-0/+13
| | | | | | | | | consumers of that module. Previously, such a file would only be available if the module happened to actually import something from that module. llvm-svn: 232583
* Give better diagnostics when -fmodule-file= finds a bad file: if the file isRichard Smith2015-02-281-3/+13
| | | | | | | found indirectly, explain how we got there, and distinguish between 'file not found' and 'file found but invalid'. llvm-svn: 230839
* [modules] Even if we already have a definition of a class, loading in anotherRichard Smith2015-02-251-1/+4
| | | | | | | | one can give us more lookup results (due to implicit special members). Be sure to complete the redecl chain for every kind of DeclContext before performing a lookup into it, rather than only doing so for NamespaceDecls. llvm-svn: 230558
* [modules] Fix a bug that would result in a build with P paths through a moduleRichard Smith2015-02-251-0/+3
| | | | | | | graph with M modules to take O(P) time, not just O(M) time, when using explicit module builds. llvm-svn: 230412
* Add -fno-implicit-modules.Manuel Klimek2015-02-201-0/+6
| | | | | | | If this flag is set, we error out when a module build is required. This is useful in environments where all required modules are passed via -fmodule-file. llvm-svn: 230006
* [PCH/Modules] Check that the specific module cache path the PCH was built ↵Argyrios Kyrtzidis2015-02-191-8/+12
| | | | | | | | | | | | with, is the same as the one in the current compiler invocation. If they differ reject the PCH. This protects against the badness occurring from getting modules loaded from different module caches (see crashes). rdar://19889860 llvm-svn: 229909
* Diagnose timeouts in the LockFileManager and delete the dead lock fileBen Langmuir2015-02-091-2/+12
| | | | | | | | | | | | If the lock file manager times out, we should give an error rather than silently trying to load the existing module. And delete the (presumably) dead lock file, since it will otherwise prevent progress in future invokations. This is unsound since we have no way to prove that the lock file we are deleting is the same one we timed out on, but since the lock is only to avoid excessive rebuilding anyway it should be okay. Depends on llvm r228603. llvm-svn: 228604
* [modules] When using -E, we may try to merge decls despite having no SemaRichard Smith2015-02-041-14/+13
| | | | | | | | | | | object. In such a case, use the TU's DC for merging global decls rather than giving up when we find there is no TU scope. Ultimately, we should probably avoid all loading of decls when preprocessing, but there are other reasonable use cases for loading an AST file with no Sema object for which this is the right thing. llvm-svn: 228234
* PR22299: Relocate code for handling -fmodule-map-file= so that we don't try toRichard Smith2015-01-231-8/+0
| | | | | | | produce diagnostics with source locations before the diagnostics system is ready for them. llvm-svn: 226882
* [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
OpenPOWER on IntegriCloud