Make module files passed to a module build via -fmodule-file= available to
consumers of that module.

Previously, such a file would only be available if the module happened to
actually import somethi

Make module files passed to a module build via -fmodule-file= available to
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

show more ...

Revert "Wrap clang module files in a Mach-O, ELF, or COFF container."

llvm-svn: 230454

Wrap clang module files in a Mach-O, ELF, or COFF container.
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us

Wrap clang module files in a Mach-O, ELF, or COFF container.
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

llvm-svn: 230423

show more ...

Revert "Wrap clang module files in a Mach-O, ELF, or COFF container."

This reverts commit r230305.
Off to fix another round of missing dependencies on various platforms.

llvm-svn: 230309

Wrap clang module files in a Mach-O, ELF, or COFF container.
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us

Wrap clang module files in a Mach-O, ELF, or COFF container.
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.

llvm-svn: 230305

show more ...

Revert "Wrap clang module files in a Mach-O, ELF, or COFF container."

This reverts commit 230099.

The Linux configure+make build variant still needs some work.

llvm-svn: 230103

Wrap clang module files in a Mach-O, ELF, or COFF container.
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us

Wrap clang module files in a Mach-O, ELF, or COFF container.
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.

llvm-svn: 230089

show more ...

Revert "Wrap clang module files in a Mach-O, ELF, or COFF container."

This reverts commit r230067.

Investigating another batch of problems found by the bots.

llvm-svn: 230073

Wrap clang module files in a Mach-O, ELF, or COFF container.
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us

Wrap clang module files in a Mach-O, ELF, or COFF container.
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.

llvm-svn: 230067

show more ...

Revert "Wrap clang module files in a Mach-O, ELF, or COFF container."

This reverts commit r230044 while dealing with buildbot breakage.

Conflicts:
test/Modules/module_container.m

llvm-svn: 230052

Wrap clang module files in a Mach-O, ELF, or COFF container.
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us

Wrap clang module files in a Mach-O, ELF, or COFF container.
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

llvm-svn: 230044

show more ...

[modules] When explicitly importing a module, it's fine for the imported module
to be newer than we were expecting. That happens if .pcm's get moved between
file systems during a distributed build. (

[modules] When explicitly importing a module, it's fine for the imported module
to be newer than we were expecting. That happens if .pcm's get moved between
file systems during a distributed build. (It's still not OK for them to actually
be different, though, so we still check the size and signature matches.)

llvm-svn: 222507

show more ...

Check module signature when the module has already been loaded

We may need to verify the signature on subsequent imports as well, just
like we verify the size/modtime:
@import A;
@import B; // impor

Check module signature when the module has already been loaded

We may need to verify the signature on subsequent imports as well, just
like we verify the size/modtime:
@import A;
@import B; // imports A
@import C; // imports A

llvm-svn: 221569

show more ...

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

[Modules] Free modules that failed signature verification.

The control flow and ownership is weird enough so unique_ptr doesn't help here :(

llvm-svn: 220569

Add a "signature" to AST files to verify that they haven't changed

Since the order of the IDs in the AST file (e.g. DeclIDs, SelectorIDs)
is not stable, it is not safe to load an AST file that depen

Add a "signature" to AST files to verify that they haven't changed

Since the order of the IDs in the AST file (e.g. DeclIDs, SelectorIDs)
is not stable, it is not safe to load an AST file that depends on
another AST file that has been rebuilt since the importer was built,
even if "nothing changed". We previously used size and modtime to check
this, but I've seen cases where a module rebuilt quickly enough to foil
this check and caused very hard to debug build errors.

To save cycles when we're loading the AST, we just generate a random
nonce value and check that it hasn't changed when we load an imported
module, rather than actually hash the whole file.

This is slightly complicated by the fact that we need to verify the
signature inside addModule, since we might otherwise consider that a
mdoule is "OutOfDate" when really it is the importer that is out of
date. I didn't see any regressions in module load time after this
change.

llvm-svn: 220493

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

Return a std::unique_ptr from getBufferForFile. NFC.

llvm-svn: 216476

Store std::unique_ptr in InMemoryBuffers. NFC.

llvm-svn: 215928

Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size.

llvm-svn: 215869

Update for llvm api change.

llvm-svn: 212408

Avoid invalidating successfully loaded module files

Successfully loaded module files may be referenced in other
ModuleManagers, so don't invalidate them. Two related things are fixed:

1) I thought

Avoid invalidating successfully loaded module files

Successfully loaded module files may be referenced in other
ModuleManagers, so don't invalidate them. Two related things are fixed:

1) I thought the last module in the manager was always the one that
failed, but it isn't. So check explicitly against the list of
vetted modules from ReadASTCore.

2) We now keep the file descriptor of pcm file open, which avoids the
possibility of having two different pcms for the same module loaded when
building in parallel with headers being modified during a build.

<rdar://problem/16835846>

llvm-svn: 211330

show more ...

Include system_error directly.

llvm-svn: 210802

Replace llvm::error_code with std::error_code.

llvm-svn: 210780

Invalidate the file system cache entries for files that may rebuild

This reapplies r209910 with a fix for the assertion failures hit on the
buildbots.

original commit message:
I thought we could ge

Invalidate the file system cache entries for files that may rebuild

This reapplies r209910 with a fix for the assertion failures hit on the
buildbots.

original commit message:
I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.

So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.

Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.

<rdar://problem/17038180>

llvm-svn: 209922

show more ...