Add -fno-implicit-modules.

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 with, is the same as
the one in the current compiler invocation. If they differ reject the PCH.

This protects against the ba

[PCH/Modules] Check that the specific module cache path the PCH was built 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

show more ...

Diagnose timeouts in the LockFileManager and delete the dead lock file

If the lock file manager times out, we should give an error rather than
silently trying to load the existing module. And delet

Diagnose timeouts in the LockFileManager and delete the dead lock file

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

show more ...

[modules] When using -E, we may try to merge decls despite having no Sema
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.

Ul

[modules] When using -E, we may try to merge decls despite having no Sema
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

show more ...

PR22299: Relocate code for handling -fmodule-map-file= so that we don't try to
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't
complain that the contained modules are defined twice.

llvm-svn: 223724

PR21217: Slightly more eagerly load -fmodule-map-file= files and provide
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,
rather than trying to extract this information from the FileEntry after the
fact.

This has a number of beneficial effects. F

[modules] Track how 'header' directives were written in module map files,
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

show more ...

Make DiagnosticsEngine::takeClient return std::unique_ptr<>

Summary:
Make DiagnosticsEngine::takeClient return std::unique_ptr<>. Updated
callers to store conditional ownership using a pair of point

Make DiagnosticsEngine::takeClient return std::unique_ptr<>

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

show more ...

A small correction for r221884. No functional changes.

llvm-svn: 222130

Support non-owned DiagnosticConsumer in SetupSerializedDiagnostics

This fixes an assertion when running clang-tidy on a file having
--serialize-diagnostics in compiler options. Committing a regressi

Support non-owned DiagnosticConsumer in SetupSerializedDiagnostics

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

show more ...

[modules] Load .pcm files specified by -fmodule-file lazily.

llvm-svn: 220731

Make VFS and FileManager match the current MemoryBuffer API.

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-diagnostics

Currently, when --serialize-diagnostics is passed this only includes
the diagnostics from clang -cc1, and driver diagnostics are
dr

Driver: Include driver diagnostics when we --serialize-diagnostics

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

show more ...

[modules] Initial support for explicitly loading .pcm files.

Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and th

[modules] Initial support for explicitly loading .pcm files.

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

show more ...

Extend -Rmodule-build to also remark when module building finishes.

In cases of nested module builds, or when you care how long module builds take,
this information was not previously easily availab

Extend -Rmodule-build to also remark when module building finishes.

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

show more ...

Ensure that all module build failures get diagnosed

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
m

Ensure that all module build failures get diagnosed

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

show more ...

unique_ptrify ChainedDiagnosticConsumer's ctor parameters

llvm-svn: 217793

Fix memory leak of raw_ostreams in LogDiagnosticPrinter handling.

This is another case of conditional ownership (in this case a raw
reference, plus a boolean to indicate whether the referenced objec

Fix memory leak of raw_ostreams in LogDiagnosticPrinter handling.

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

show more ...

unique_ptrify the raw_ostream argument to clang::serialized_diags::create

llvm-svn: 216767

Provide a BuryPointer for unique_ptrs.

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 v

Provide a BuryPointer for unique_ptrs.

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

show more ...

unique_ptrify SourceManager::createFileID

llvm-svn: 216715

Overload SourceManager::overrideFileContents so that unconditionally passing ownership is explicitly done using unique_ptr.

Only those callers who are dynamically passing ownership should need the
3

Overload SourceManager::overrideFileContents so that unconditionally passing 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

show more ...

Update for LLVM api change.

llvm-svn: 216585

Add support for the static analyzer to synthesize function implementations from external model files.

Currently the analyzer lazily models some functions using 'BodyFarm',
which constructs a fake fu

Add support for the static analyzer to synthesize function implementations 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

show more ...