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
Rather than having a pair of pairs and a reference out parameter, build
a structure with everything together and named. A raw pointer and a
unique_ptr, rather than a raw pointer and a boolean, are used to
communicate ownership transfer.
It's possible one day we'll end up with a conditional pointer (probably
represented by a raw pointer and a boolean) abstraction to use in places
like this. Conditional ownership seems to be coming up more often than
I'd hoped...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216712 91177308-0d34-0410-b5e6-96231b3b80d8
This change is the last in the pack of five commits
(also see r216691, r216694, r216695, and r216696) that reduces the number
of test failures in "check-clang" invocation in UBSan bootstrap
from 2443 down to 5.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216697 91177308-0d34-0410-b5e6-96231b3b80d8
std::unique_ptr is null initialized and reset default to null.
Thanks to David Blaikie for noticing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215560 91177308-0d34-0410-b5e6-96231b3b80d8
This code doesn't care where the data it is processing comes from, so a
StringRef is probably the most natural interface.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215448 91177308-0d34-0410-b5e6-96231b3b80d8
(dropping const from the reference as MemoryBuffer is immutable already,
so const is just redundant - and while I'd personally put const
everywhere, that's not the LLVM Way (see llvm::Type for another example
of an immutable type where "const" is omitted for brevity))
Changing the pointer argument to a reference parameter makes call sites
identical between callers with unique_ptrs or raw pointers, minimizing
the churn in a pending unique_ptr migrations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215391 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215323 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r213307.
Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM project.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213325 91177308-0d34-0410-b5e6-96231b3b80d8
(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)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213307 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it clear that TargetInfo doesn't capture the LangOptions object,
rather uses it to apply adjustments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212386 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212060 91177308-0d34-0410-b5e6-96231b3b80d8
We were using old stat values for any files that had previously been
looked up, leading to badness. There might be a more elegant solution in
invalidating the cache for those file (since we already know which ones
they are), but it seems too likely there are existing references to
them hiding somewhere.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211504 91177308-0d34-0410-b5e6-96231b3b80d8
Having various possible states of initialization following construction doesn't
add value here.
Also remove the unused size_reserve parameter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207897 91177308-0d34-0410-b5e6-96231b3b80d8
The Preprocessor::Initialize() function already offers a clear interface to
achieve this, further reducing the confusing number of states a newly
constructed preprocessor can have.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207825 91177308-0d34-0410-b5e6-96231b3b80d8
We don't need the ASTContext for the diagnostics, only the language
options, which we can get from the compiler invocation. It worries me
how many categorically different states the ASTUnit class can be in
depending on how it is being constructed/used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206909 91177308-0d34-0410-b5e6-96231b3b80d8
When transferring data from a CompilerInstance in an error path we need
to consider cases where the various fields are uninitialized.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206644 91177308-0d34-0410-b5e6-96231b3b80d8
Padding does not seem to be useful currently, and it leads to bogus location if an error
points to the end of the file.
rdar://15836513
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203370 91177308-0d34-0410-b5e6-96231b3b80d8
With r197755 we started reading the contents of buffer file entries, but the
buffers may point to ASTReader blobs that have been disposed.
Fix this by having the CompilerInstance object keep a reference to the ASTReader
as well as having the ASTContext keep reference to the ExternalASTSource.
This was very difficult to construct a test case for.
rdar://16149782
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202346 91177308-0d34-0410-b5e6-96231b3b80d8
Previously reverted in r201755 due to causing an assertion failure.
I've removed the offending assertion, and taught the CompilerInstance to
create a default virtual file system inside createFileManager. In the
future, we should be able to reach into the CompilerInvocation to
customize this behaviour without breaking clients that don't care.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201818 91177308-0d34-0410-b5e6-96231b3b80d8
ASTUnit contains code to remap files to other files on disk. This code is not
used. We only remap files to MemoryBuffers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201010 91177308-0d34-0410-b5e6-96231b3b80d8
llvm::sys::cas_flag is 'long' instead of 'uint32_t' on win32, because
that's what InterlockedIncrement is defined to accept.
I still don't know if we should be calling fprintf from ASTUnit.cpp
behind a getenv check.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200718 91177308-0d34-0410-b5e6-96231b3b80d8
files to tell if they were changed since the last time we have computed the
preamble
We used to check only the buffer size, so if the new remapped buffer has the
same size as the previous one, we would think that the buffer did not change,
and we did not rebuild the preambule, which sometimes caused us to crash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197755 91177308-0d34-0410-b5e6-96231b3b80d8
ASTUnit instances are allocated infrequently so it's fine to keep this field
around in all build configurations.
Assigns null to silence -Wunused-private-field in Release.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195419 91177308-0d34-0410-b5e6-96231b3b80d8
This allows using virtual file mappings on the original SourceManager to
map in virtual module.map files. Without this patch, the ModuleMap
search will find a module.map file (as the FileEntry exists in the
FileManager), but will be unable to get the content from the
SourceManager (as ModuleMap previously created its own SourceManager).
Two problems needed to be fixed which this patch exposed:
1. Storing the inferred module map
When writing out a module, the ASTWriter stores the names of the files
in the main source manager; when loading the AST again, the ASTReader
errs out if such a file is found missing, unless it is overridden.
Previously CompilerInstance's compileModule method would store the
inferred module map to a temporary file; the problem with this approach
is that now that the module map is handled by the main source manager,
the ASTWriter stores the name of the temporary module map as source to
the compilation; later, when the module is loaded, the temporary file
has already been deleted, which leads to a compilation error. This patch
changes the inferred module map to instead inject a virtual file into
the source manager. This both saves some disk IO, and works with how the
ASTWriter/ASTReader handle overridden source files.
2. Changing test input in test/Modules/Inputs/*
Now that the module map file is handled by the main source manager, the
VerifyDiagnosticConsumer will not ignore diagnostics created while
parsing the module map file. The module test test/Modules/renamed.m uses
-I test/Modules/Inputs and triggers recursive loading of all module maps
in test/Modules/Inputs, some of which had conflicting names, thus
leading errors while parsing the module maps. Those diagnostics already
occur on trunk, but before this patch they would not break the test, as
they were ignored by the VerifyDiagnosticConsumer. This patch thus
changes the module maps that have been recently introduced which broke
the invariant of compatible modules maps in test/Modules/Inputs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193314 91177308-0d34-0410-b5e6-96231b3b80d8
Let me tell you a tale...
Within some twisted maze of debug info I've ended up implementing an
insane man's Include What You Use device. When the debugger emits debug
info it really shouldn't, I find out why & then realize the code could
be improved too.
In this instance CIndexDiagnostics.cpp had a lot more debug info with
Clang than GCC. Upon inspection a major culprit was all the debug info
describing clang::Sema. This was emitted because clang::Sema is
befriended by DiagnosticEngine which was rightly required, but GCC
doesn't emit debug info for friends so it never emitted anything for
Clang. Clang does emit debug info for friends (will be fixed/changed to
reduce debug info size).
But why didn't Clang just emit a declaration of Sema if this entire TU
didn't require a definition?
1) Diagnostic.h did the right thing, only using a declaration of Sema
and not including Sema.h at all.
2) Some other dependency of CIndexDiagnostics.cpp didn't do the right
thing. ASTUnit.h, only needing a declaration, still included Sema.h
(hence this commit which removes that include and adds the necessary
includes to the cpp files that were relying on this)
3) -flimit-debug-info didn't save us because of
EnterExpressionEvaluationContext, defined inline in Sema.h which fires
the "requiresCompleteType" check/flag (since it uses nested types from
Sema and calls Sema member functions) and thus, if debug info is ever
emitted for the type, the whole type is emitted and not just a
declaration.
Improving -flimit-debug-info to account for this would be... hard.
Modifying the code so that's not 'required to be complete' might be
possible, but probably only by moving EnterExpressionEvaluationContext
either into Sema, or out of Sema.h. That might be a bit too much of a
contortion to be bothered with.
Also, this is only one of the cases where emitting debug info for
friends caused us to emit a lot more debug info (this change reduces
Clang's DWO size by 0.93%, dropping friends entirely reduces debug info
by 3.2%) - I haven't hunted down the other cases, but I assume they
might be similar (Sema or something like it). IWYU or a similar tool
might help us reduce build times a bit, but analyzing debug info to find
these differences isn't worthwhile. I'll take the 3.2% win, provide this
small improvement to the code itself, and move on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190715 91177308-0d34-0410-b5e6-96231b3b80d8
The problem was that an enum without closing semicolon could be associated as a forward enum
in an erroneous declaration, leading to the identifier being associated with the enum decl but
without a declaration actually referencing it.
This resulted in not having it serialized before serializing the identifier that is associated with.
Also prevent the ASTUnit from querying the serialized DeclID for an invalid top-level decl; it may not
have been serialized.
rdar://14539667
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187914 91177308-0d34-0410-b5e6-96231b3b80d8
Use CaptureDroppedDiagnostics to make sure that there is a diagnostic
client installed when warning flags are parsed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186582 91177308-0d34-0410-b5e6-96231b3b80d8
The top-level hash is used to determine if we need to update the global code-completion results.
ImportDecls did not affect the hash so a newly introduced ImportDecl would not trigger an update of the global results.
rdar://14202797
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184782 91177308-0d34-0410-b5e6-96231b3b80d8
A while ago we allowed libclang to build a PCH that had compiler errors; this was to retain the performance
afforded by a PCH even if the user's code is in an intermediate state.
Extend this for the precompiled preamble as well.
rdar://14109828
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183717 91177308-0d34-0410-b5e6-96231b3b80d8
This made sense in pre-module era, before merging of HeaderFileInfos was introduced.
Final part of rdar://13840148.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181490 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we would clone the current diagnostic consumer to produce
a new diagnostic consumer to use when building a module. The problem
here is that we end up losing diagnostics for important diagnostic
consumers, such as serialized diagnostics (where we'd end up with two
diagnostic consumers writing the same output file). With forwarding,
the diagnostics from all of the different modules being built get
forwarded to the one serialized-diagnostic consumer and are emitted in
a sane way.
Fixes <rdar://problem/13663996>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181067 91177308-0d34-0410-b5e6-96231b3b80d8
The global module index was querying the file manager for each of the
module files it knows about at load time, to prune out any out-of-date
information. The file manager would then cache the results of the
stat() falls used to find that module file.
Later, the same translation unit could end up trying to import one of the
module files that had previously been ignored by the module cache, but
after some other Clang instance rebuilt the module file to bring it
up-to-date. The stale stat() results in the file manager would
trigger a second rebuild of the already-up-to-date module, causing
failures down the line.
The global module index now lazily resolves its module file references
to actual AST reader module files only after the module file has been
loaded, eliminating the stat-caching race. Moreover, the AST reader
can communicate to its caller that a module file is missing (rather
than simply being out-of-date), allowing us to simplify the
module-loading logic and allowing the compiler to recover if a
dependent module file ends up getting deleted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177367 91177308-0d34-0410-b5e6-96231b3b80d8
Add an ability to specify custom documentation block comment commands via a new
class CommentOptions. The intention is that this class will hold future
customizations for comment parsing, including defining documentation comments
with specific numbers of parameters, etc.
CommentOptions instance is a member of LangOptions.
CommentOptions is controlled by a new command-line parameter
-fcomment-block-commands=Foo,Bar,Baz.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175892 91177308-0d34-0410-b5e6-96231b3b80d8
Also, it was the only reason that `argc` and `argv` were being passed
into createDiagnostics, so remove those parameters and clean up callers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172945 91177308-0d34-0410-b5e6-96231b3b80d8
code-completion results, the SourceManager state may be slightly
different when code-completing.
And we don't even care for diagnostics when code-completing, anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170979 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
to the CodeCompletionTUInfo that is going to be used to get the results.
Previously we would use ASTUnit's CodeCompletionTUInfo which has its own allocator
that will go away when we reparse. That could result in a use-after-free bug when
getting the parent context name from a CodeCompletionString.
Addresses rdar://12568377.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168133 91177308-0d34-0410-b5e6-96231b3b80d8
The stat cache became essentially useless ever since we started
validating all file entries in the PCH.
But the motivating reason for removing it now is that it also affected
correctness in this situation:
-You have a header without include guards (using "#pragma once" or #import)
-When creating the PCH:
-The same header is referenced in an #include with different filename cases.
-In the PCH, of course, we record only one file entry for the header file
-But we cache in the PCH file the stat info for both filename cases
-Then the source files are updated and the header file is updated in a way that
its size and modification time are the same but its inode changes
-When using the PCH:
-We validate the headers, we check that header file and we create a file entry with its current inode
-There's another #include with a filename with different case than the previously created file entry
-In order to get its stat info we go through the cached stat info of the PCH and we receive the old inode
-because of the different inodes, we think they are different files so we go ahead and include its contents.
Removing the stat cache will potentially break clients that are attempting to use the stat cache
as a way of avoiding having the actual input files available. If that use case is important, patches are welcome
to bring it back in a way that will actually work correctly (i.e., emit a PCH that is self-contained, coping with
literal strings, line/column computations, etc.).
This fixes rdar://5502805
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167172 91177308-0d34-0410-b5e6-96231b3b80d8
the various stakeholders bump up the reference count. In particular,
the diagnostics engine now keeps the DiagnosticOptions object alive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166508 91177308-0d34-0410-b5e6-96231b3b80d8
check each of the files within that directory to determine if any of
them is an AST file that matches the language and target options. If
so, the first matching AST file is loaded. This fixes a longstanding
discrepency with GCC's precompiled header implementation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166469 91177308-0d34-0410-b5e6-96231b3b80d8
failures they know how to tolerate, e.g., out-of-date input files or
configuration/version mismatches. Suppress the corresponding
diagnostics if the client can handle it.
No clients actually use this functionality, yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166449 91177308-0d34-0410-b5e6-96231b3b80d8
The ASTUnit needs to initialize an ASTWriter at the beginning of
parsing to fully handle serialization of a translation unit that
imports modules. Do this by introducing an option to enable it, which
corresponds to CXTranslationUnit_ForSerialization on the C API side.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165717 91177308-0d34-0410-b5e6-96231b3b80d8
-fcatch-undefined-behavior. Don't try to fit 34 different flags
into 32 bits. Also, don't use 32-bit signed left shifts for this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161830 91177308-0d34-0410-b5e6-96231b3b80d8
as "volatile", meaning there's a high enough chance that they may
change while we are trying to use them.
This flag is only enabled by libclang.
Currently "volatile" source files will be stat'ed immediately
before opening them, because the file size stat info
may not be accurate since when we got it (e.g. from the PCH).
This avoids crashes when trying to reference mmap'ed memory
from a file whose size is not what we expect.
Note that there's still a window for a racing issue to occur
but the window for it should be way smaller than before.
We can consider later on to avoid mmap completely on such files.
rdar://11612916
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160074 91177308-0d34-0410-b5e6-96231b3b80d8
attached to a declaration in the completion string.
Since extracting comments isn't free, a new code completion option is
introduced.
A new code completion option that enables including brief comments
into CodeCompletionString should be a, err, code completion option.
But because ASTUnit caches global declarations during parsing before
even completion consumer is created, the option is duplicated as a
translation unit option (in both libclang and ASTUnit, like the option
to cache code completion results).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159539 91177308-0d34-0410-b5e6-96231b3b80d8
output the errors that occurred even if we did not get an AST (e.g. because the
PCH failed to load).
Also honor displayDiagnostics in clang_indexSourceFile().
rdar://11203489
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154472 91177308-0d34-0410-b5e6-96231b3b80d8
code-completion related strings specific to a translation unit (ASTContext and related data)
CodeCompletionAllocator does such limited caching, by caching the name assigned
to a DeclContext*, but that is not the appropriate place since that object has
a lifetime that can extend beyond that of an ASTContext.
Introduce CodeCompletionTUInfo which will be always tied to a translation unit
to do this kind of caching and move the caching of CodeCompletionAllocator into this
object, and propagate it to all the places where it will be needed.
The plan is to extend the caching where appropriate, using CodeCompletionTUInfo,
to avoid re-calculating code-completion strings.
Part of rdar://10796159.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154408 91177308-0d34-0410-b5e6-96231b3b80d8
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152536 91177308-0d34-0410-b5e6-96231b3b80d8
compiler errors or not.
-Control whether ASTReader should reject such a PCH by a boolean flag at ASTReader's creation time.
By default, such a PCH file will be rejected with an error when trying to load it.
[libclang] Allow clang_saveTranslationUnit to create a PCH file even if compiler errors
occurred.
-Have libclang API calls accept a PCH that had compiler errors.
The general idea is that we want libclang to stay functional even if a PCH had a compiler error.
rdar://10976363.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152192 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith