Return a std::unique_ptr from getBufferForFile. NFC.

llvm-svn: 216476

Update for llvm api change.

llvm-svn: 216397

Revert r215331, "unique_ptrify CompilerInstance::OutputFile(s) and remove a unique_ptr around a non-owning raw_ostream in CodeGenAction::CreateASTConsumer"

It cannot be compiled on Visual Studio 201

Revert r215331, "unique_ptrify CompilerInstance::OutputFile(s) and remove a 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

show more ...

unique_ptrify CompilerInstance::OutputFile(s) and remove a unique_ptr around a non-owning raw_ostream in CodeGenAction::CreateASTConsumer

llvm-svn: 215331

Out-of-line CompilerInstance::takeSema to avoid a header dependence from CompilerInstance.h on Sema.h

Hopefully this fixes the libstdc++ build on some of the buildbots after
r215321.

llvm-svn: 2153

Out-of-line CompilerInstance::takeSema to avoid a header dependence from CompilerInstance.h on Sema.h

Hopefully this fixes the libstdc++ build on some of the buildbots after
r215321.

llvm-svn: 215325

show more ...

Recommit 213307: unique_ptr-ify ownership of ASTConsumers (reverted in r213325)

After post-commit review and community discussion, this seems like a
reasonable direction to continue, making ownershi

Recommit 213307: unique_ptr-ify ownership of ASTConsumers (reverted in r213325)

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

show more ...

Refactor the module map file used for uniquing a module name out of

class Module. It's almost always going to be the same as
getContainingModule() for top-level modules, so just add a map to cover
t

Refactor the module map file used for uniquing a module name out of

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

show more ...

Add stopgap option -fmodule-implementation-of <name>

This flag specifies that we are building an implementation file of the
module <name>, preventing importing <name> as a module. This does not
cons

Add stopgap option -fmodule-implementation-of <name>

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

show more ...

If a module build reports errors, don't try to load it

... just to find out that it didn't build.

llvm-svn: 213454

Revert "unique_ptr-ify ownership of ASTConsumers"

This reverts commit r213307.

Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM

Revert "unique_ptr-ify ownership of ASTConsumers"

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

show more ...

unique_ptr-ify ownership of ASTConsumers

(after fixing a bug in MultiplexConsumer I noticed the ownership of the
nested consumers was implemented with raw pointers - so this fixes
that... and follow

unique_ptr-ify ownership of ASTConsumers

(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

show more ...

Peel away old-style file remapping typedefs and cruft

llvm-svn: 212438

Fix layering of file remapping and header search initialization

These two functions initialize the source manager and header search objects and
shouldn't be in InitPreprocessor which is concerned wi

Fix layering of file remapping and header search initialization

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

show more ...

Update for llvm api change.

llvm-svn: 212408

Use non-intrusive refcounting for TargetOptions

llvm-svn: 212388

Constify a read-only parameter and give function a better name

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 r212366

llvm-svn: 212369

Consider module depedencies when checking a preamble in libclang

Add module dependencies (header files, module map files) to the list of
files to check when deciding whether to rebuild a preamble. T

Consider module depedencies when checking a preamble in libclang

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

show more ...

Remove 'const' from MemoryBuffers used through the SourceManager

This removes a const_cast added in r211884 that occurred due to an
inconsistency in how MemoryBuffers are handled between some parts

Remove 'const' from MemoryBuffers used through the SourceManager

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

show more ...

Frontend: Add a CC1 flag to dump module dependencies to a directory

This adds the -module-dependency-dir to clang -cc1, which specifies a
directory to copy all of a module's dependencies into in a f

Frontend: Add a CC1 flag to dump module dependencies to a directory

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

show more ...

Retry building modules that were compiled by other instances and are out-of-date

When another clang instance builds a module, it may still be considered
"out of date" for the current instance in a c

Retry building modules that were compiled by other instances and are out-of-date

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

show more ...

Update for llvm api change.

llvm-svn: 210921

Include system_error directly.

llvm-svn: 210802

Replace llvm::error_code with std::error_code.

llvm-svn: 210780

Use std::error_code instead of llvm::error_code.

This is an update for a llvm api change.

llvm-svn: 210688