Summary:
It was previsouly set only in ASTUnit, but it should be set for all client of
PrecompiledPreamble.
Reviewers: erikjv, bkramer, klimek
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38617
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315212 91177308-0d34-0410-b5e6-96231b3b80d8
When using a virtual file-system (VFS) and a preamble file (PCH) is generated,
it is generated on-disk in the real file-system instead of in the VFS (which
makes sense, since the VFS is read-only). However, when subsequently reading
the generated PCH, the frontend passes through the VFS it has been given --
resulting in an error and a failed parse (since the VFS doesn't contain the
PCH; the real filesystem does).
This patch fixes that by detecting when a VFS is being used for a parse that
needs to work with a PCH file, and creating an overlay VFS that includes the
PCH file from the real file-system.
This allows tests to be written which make use of both PCH files and a VFS.
Differential Revision: https://reviews.llvm.org/D37474
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312917 91177308-0d34-0410-b5e6-96231b3b80d8
When we have enabled cache for global completions we did not have
diagnostics for Bar and could not complete Ba as in provided code
example.
template <typename T>
struct Foo { T member; };
template<typename T> using Bar = Foo<T>;
int main() {
Ba
}
(This is the fixed version of r 311442, which was reverted in r311445.)
Patch by Ivan Donchevskii!
Differential Revision: https://reviews.llvm.org/D35355
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312780 91177308-0d34-0410-b5e6-96231b3b80d8
In ASTUnit::LoadFromASTFile, the context object is set up using
default-constructed LangOptions (which only later get populated). As the
language options are used in the constructor of PrintingPolicy, this
needs to be updated explicitly after the language options are available.
Patch by Johann Klähn!
Differential Revision: https://reviews.llvm.org/D35271
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311787 91177308-0d34-0410-b5e6-96231b3b80d8
When we have enabled cache for global completions we did not have
diagnostics for Bar and could not complete Ba as in provided code
example.
template <typename T>
struct Foo { T member; };
template<typename T> using Bar = Foo<T>;
int main() {
Ba
}
Patch by Ivan Donchevskii!
Differential Revision: https://reviews.llvm.org/D35355
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311442 91177308-0d34-0410-b5e6-96231b3b80d8
We use this when running a preprocessor-only action on an AST file in order to
avoid paying the runtime cost of loading the extra information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306760 91177308-0d34-0410-b5e6-96231b3b80d8
as part of a compilation.
This is intended for two purposes:
1) Writing self-contained test cases for modules: we can now write a single
source file test that builds some number of module files on the side and
imports them.
2) Debugging / test case reduction. A single-source testcase is much more
amenable to reduction, compared to a VFS tarball or .pcm files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305101 91177308-0d34-0410-b5e6-96231b3b80d8
Cache filename - SourceLocation pairs to speed up preamble loading and
global completion. This is especially relevant for windows, where
preamble loading takes a while.
Patch by Ivan Donchevskii!
Differential Revision: http://reviews.llvm.org/D33493
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305061 91177308-0d34-0410-b5e6-96231b3b80d8
This is useful for parsing a single file, as a fast/inaccurate 'mode' that can still provide declarations from the file, like the classes and their methods.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305044 91177308-0d34-0410-b5e6-96231b3b80d8
replay the steps taken to create the AST file with the preprocessor-only action
installed to produce preprocessed output.
This can be used to produce the preprocessed text for an existing .pch or .pcm
file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304726 91177308-0d34-0410-b5e6-96231b3b80d8
A suspended translation unit uses significantly less memory but on the
other side does not support any other calls than
clang_reparseTranslationUnit to resume it or
clang_disposeTranslationUnit to dispose it completely.
This helps IDEs to reduce the memory footprint. The data that is freed
by a call to clang_suspendTranslationUnit will be re-generated on the
next (re)parse anyway. Used with a preamble, this allows pretty fast
resumption of the translation unit for further use (compared to disposal
of the translation unit and a parse from scratch).
Patch by Nikolai Kosjar!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304212 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, a preamble only included #if blocks (and friends like
ifdef) if there was a corresponding #endif before any declaration or
definition. The problem is that any header file that uses include guards
will not have a preamble generated, which can make code-completion very
slow.
To prevent errors about unbalanced preprocessor conditionals in the
preamble, and unbalanced preprocessor conditionals after a preamble
containing unfinished conditionals, the conditional stack is stored
in the pch file.
This fixes PR26045.
Differential Revision: http://reviews.llvm.org/D15994
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304207 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
OnDiskData.TemporaryFiles is filled only by ASTUnit::addTemporaryFile, which is
dead. Also these files are used nowhere in the frontend nor in libclang.
Reviewers: bkramer, ilya-biryukov
Reviewed By: bkramer, ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33270
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303265 91177308-0d34-0410-b5e6-96231b3b80d8
In doing so, clean up the MD5 interface a little. Most
existing users only care about the lower 8 bytes of an MD5,
but for some users that care about the upper and lower,
there wasn't a good interface. Furthermore, consumers
of the MD5 checksum were required to handle endianness
details on their own, so it seems reasonable to abstract
this into a nicer interface that just gives you the right
value.
Differential Revision: https://reviews.llvm.org/D31105
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298322 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r298185, effectively reapplying r298165, after fixing the
new unit tests (PR32338). The memory buffer generator doesn't null-terminate
the MemoryBuffer it creates; this version of the commit informs getMemBuffer
about that to avoid the assert.
Original commit message follows:
----
Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands). Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly. Furthermore, the LockFileManager is not
robust in every environment. Other -cc1 commands can stall until
timeout (after about eight minutes).
This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack. The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module. Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout. Perhaps we should
reconsider blocking at all.
This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.
The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename. Its ownership is shared by the
CompilerInstance and ModuleManager.
- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.
- When modules fail to validate, they're removed from the cache.
- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.
- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.
Original patch by Manman Ren; most testcases by Adrian Prantl!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298278 91177308-0d34-0410-b5e6-96231b3b80d8
Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands). Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly. Furthermore, the LockFileManager is not
robust in every environment. Other -cc1 commands can stall until
timeout (after about eight minutes).
This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack. The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module. Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout. Perhaps we should
reconsider blocking at all.
This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.
The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename. Its ownership is shared by the
CompilerInstance and ModuleManager.
- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.
- When modules fail to validate, they're removed from the cache.
- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.
- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.
Original patch by Manman Ren; most testcases by Adrian Prantl!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298165 91177308-0d34-0410-b5e6-96231b3b80d8
Change ASTFileSignature from a random 32-bit number to the hash of the
PCM content.
- Move definition ASTFileSignature to Basic/Module.h so Module and
ASTSourceDescriptor can use it.
- Change the signature from uint64_t to std::array<uint32_t,5>.
- Stop using (saving/reading) the size and modification time of PCM
files when there is a valid SIGNATURE.
- Add UNHASHED_CONTROL_BLOCK, and use it to store the SIGNATURE record
and other records that shouldn't affect the hash. Because implicit
modules reuses the same file for multiple levels of -Werror, this
includes DIAGNOSTIC_OPTIONS and DIAG_PRAGMA_MAPPINGS.
This helps to solve a PCH + implicit Modules dependency issue: PCH files
are handled by the external build system, whereas implicit modules are
handled by internal compiler build system. This prevents invalidating a
PCH when the compiler overwrites a PCM file with the same content
(modulo the diagnostic differences).
Design and original patch by Manman Ren!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297655 91177308-0d34-0410-b5e6-96231b3b80d8
Modules/preambles/PCH files can contain diagnostics, which, when used,
are added to the current ASTUnit. For that to work, they are translated
to use the current FileManager's FileIDs. When the entry is not the
main file, all local source locations will be checked by a linear
search. Now this is a problem, when there are lots of diagnostics (say,
25000) and lots of local source locations (say, 440000), and end up
taking seconds when using such a preamble.
The fix is to cache the last FileID, because many subsequent diagnostics
refer to the same file. This reduces the time spent in
ASTUnit::TranslateStoredDiagnostics from seconds to a few milliseconds
for files with many slocs/diagnostics.
This fixes PR31353.
Differential Revision: https://reviews.llvm.org/D29755
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295301 91177308-0d34-0410-b5e6-96231b3b80d8
If the preamble had diagnostic state this would leave behind invalid
state in the DiagnosticsEngine and crash later. The test case runs into
an assertion in DiagnosticsEngine::setSourceManager.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294963 91177308-0d34-0410-b5e6-96231b3b80d8
This ensures the capability to index a module file using an existing ASTReader from a compiler instance or ASTUnit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293461 91177308-0d34-0410-b5e6-96231b3b80d8
Aleksey Shlypanikov pointed out my mistake in migrating an explicit
unique_ptr to auto - I was expecting the function returned a unique_ptr,
but instead it returned a raw pointer - introducing a leak.
Thanks Aleksey!
This reapplies r291184, reverted in r291249.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291270 91177308-0d34-0410-b5e6-96231b3b80d8
interface files. At the moment, all declarations (and no macros) are exported,
and 'export' declarations are not supported yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279794 91177308-0d34-0410-b5e6-96231b3b80d8
In this mode, there is no need to load any module map and the programmer can
simply use "@import" syntax to load the module directly from a prebuilt
module path. When loading from prebuilt module path, we don't support
rebuilding of the module files and we ignore compatible configuration
mismatches.
rdar://27290316
Differential Revision: http://reviews.llvm.org/D23125
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279096 91177308-0d34-0410-b5e6-96231b3b80d8
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
Ilya Biryukov