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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
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
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
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
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
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
Richard Smith