This changes the CompilerInstance::createOutputFile function to return
a std::unique_ptr<llvm::raw_ostream>, rather than an llvm::raw_ostream
implicitly owned by the CompilerInstance. This in most cases required that
I move ownership of the output stream to the relevant ASTConsumer.
The motivation for this change is to allow BackendConsumer to be a client
of interfaces such as D20268 which take ownership of the output stream.
Differential Revision: http://reviews.llvm.org/D21537
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275507 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise there can be a crash with CFG analysis warnings doing work on invalid AST.
Fixes crash of rdar://26224134
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275313 91177308-0d34-0410-b5e6-96231b3b80d8
When remapped files were changed, they would not always cause the preamble's PCH to be invalidated, because the remapped path didn't necessarily match the include path (e.g. slash direction -- this happens a lot on Windows). I fixed this by moving to a llvm::sys::fs::UniqueID-based map instead of comparing paths stringwise.
Differential Revision: http://reviews.llvm.org/D20137
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269769 91177308-0d34-0410-b5e6-96231b3b80d8
Revert the two changes to thread CodeGenOptions into the TargetInfo allocation
and to fix the layering violation by moving CodeGenOptions into Basic.
Code Generation is arguably not particularly "basic". This addresses Richard's
post-commit review comments. This change purely does the mechanical revert and
will be followed up with an alternate approach to thread the desired information
into TargetInfo.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265806 91177308-0d34-0410-b5e6-96231b3b80d8
This threads CodeGenOptions into the TargetInfo hierarchy. This is motivated by
ARM which can change some target information based on the EABI selected
(-meabi). Similar options exist for other platforms (e.g. MIPS) and thus is
generally useful. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265640 91177308-0d34-0410-b5e6-96231b3b80d8
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.
This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261372 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The current default is to create the preamble on the first reparse, aka
second parse. This is useful for clients that do not want to block when
opening a file because serializing the preamble takes a bit of time.
However, this makes the reparse much more expensive and that may be on the
critical path as it's the first interaction a user has with the source code.
YouCompleteMe currently optimizes for the first code interaction by parsing
the file twice when loaded. That's just unnecessarily slow and this flag
helps to avoid that.
Reviewers: doug.gregor, klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15490
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255635 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce the notion of a module file extension, which introduces
additional information into a module file at the time it is built that
can then be queried when the module file is read. Module file
extensions are identified by a block name (which must be unique to the
extension) and can write any bitstream records into their own
extension block within the module file. When a module file is loaded,
any extension blocks are matched up with module file extension
readers, that are per-module-file and are given access to the input
bitstream.
Note that module file extensions can only be introduced by
programmatic clients that have access to the CompilerInvocation. There
is only one such extension at the moment, which is used for testing
the module file extension harness. As a future direction, one could
imagine allowing the plugin mechanism to introduce new module file
extensions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251955 91177308-0d34-0410-b5e6-96231b3b80d8
ASTUnit was creating multiple FileManagers and throwing them away. Reuse
the one from Tooling. No functionality change now but necessary for
VFSifying tooling.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249410 91177308-0d34-0410-b5e6-96231b3b80d8
to enable the use of external type references in the debug info
(a.k.a. module debugging).
The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs"
and passes that to cc1. All this does at the moment is set a flag
codegenopts.
http://reviews.llvm.org/D11958
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246192 91177308-0d34-0410-b5e6-96231b3b80d8
- introduces a new cc1 option -fmodule-format=[raw,obj]
with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
a PCHContainerReader.
Thanks to Richard Smith for reviewing this patch!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242499 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
A PCHContainerOperations abstract interface provides operations for
creating and unwrapping containers for serialized ASTs (precompiled
headers and clang modules). The default implementation is
RawPCHContainerOperations, which uses a flat file for the output.
The main application for this interface will be an
ObjectFilePCHContainerOperations implementation that uses LLVM to
wrap the module in an ELF/Mach-O/COFF container to store debug info
alongside the AST.
rdar://problem/20091852
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240225 91177308-0d34-0410-b5e6-96231b3b80d8
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238601 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232622 91177308-0d34-0410-b5e6-96231b3b80d8
with a subset of the existing target CPU features or mismatched CPU
names.
While we can't check that the CPU name used to build the module will end
up being able to codegen correctly for the translation unit, we actually
check that the imported features are a subset of the existing features.
While here, rewrite the code to use std::set_difference and have it
diagnose all of the differences found.
Test case added which walks the set relationships and ensures we
diagnose all the right cases and accept the others.
No functional change for implicit modules here, just better diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232248 91177308-0d34-0410-b5e6-96231b3b80d8
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
This reapplies r230044 with a fixed configure+make build and updated
dependencies and testcase requirements. Over the last iteration this
version adds
- missing target requirements for testcases that specify an x86 triple,
- a missing clangCodeGen.a dependency to libClang.a in the make build.
rdar://problem/19104245
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230423 91177308-0d34-0410-b5e6-96231b3b80d8
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
This reapplies r230044 with a fixed configure+make build and updated
dependencies. Take 3.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230305 91177308-0d34-0410-b5e6-96231b3b80d8
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
This reapplies r230044 with a fixed configure+make build and updated
dependencies. Take 2.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230089 91177308-0d34-0410-b5e6-96231b3b80d8
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
This reapplies r230044 with a fixed configure+make build and updated
dependencies.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230067 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r230044 while dealing with buildbot breakage.
Conflicts:
test/Modules/module_container.m
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230052 91177308-0d34-0410-b5e6-96231b3b80d8
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230044 91177308-0d34-0410-b5e6-96231b3b80d8
Should fix the build. Looks like GCC 4.9 is using different scoping rules for
range-based for loops.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228424 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222193 91177308-0d34-0410-b5e6-96231b3b80d8
This eliminates converting back and forth between the 3 formats and
gives us a more homogeneous interface.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220657 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220359 91177308-0d34-0410-b5e6-96231b3b80d8
The various ways to create an ASTUnit all take a refcounted pointer to
a diagnostics engine as an argument, and if it isn't pointing at
anything they initialize it. This is a pretty confusing API, and it
really makes more sense for the caller to initialize the thing since
they control the lifetime anyway.
This fixes the one caller that didn't bother initializing the pointer
and asserts that the argument is initialized.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219752 91177308-0d34-0410-b5e6-96231b3b80d8
Mehdi Amini