precompiled preamble as the "main" source file's file ID within the
source manager. This makes compiling with a precompiled preamble
produce the same source locations as when compiling without the
precompiled preamble; prior to this change, we ended up with different
file IDs for source locations within the precompiled preamble
vs. those after the precompiled preamble, even for entities (e.g.,
preprocessing entities) in the same file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120390 91177308-0d34-0410-b5e6-96231b3b80d8
FileSystemOpts through a ton of apis, simplifying a lot of code.
This also fixes a latent bug in ASTUnit where it would invoke
methods on FileManager without creating one in some code paths
in cindextext.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120010 91177308-0d34-0410-b5e6-96231b3b80d8
-Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class.
-DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units.
-The rest of the state in Diagnostic object is considered related and tied to one translation unit.
-Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a
SourceLocation instead of a FullSourceLoc.
-Reflect the changes to various interfaces.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119730 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostic-capturing client lives as long as the ASTUnit itself
does. Otherwise, we can end up with crashes when we get a diagnostic
outside of parsing/code completion. The circumstances under which this
happen are really hard to reproduce, because a file needs to change
from under us.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118751 91177308-0d34-0410-b5e6-96231b3b80d8
When -working-directory is passed in command line, file paths are resolved relative to the specified directory.
This helps both when using libclang (where we can't require the user to actually change the working directory)
and to help reproduce test cases when the reproduction work comes along.
--FileSystemOptions is introduced which controls how file system operations are performed (currently it just contains
the working directory value if set).
--FileSystemOptions are passed around to various interfaces that perform file operations.
--Opening & reading the content of files should be done only through FileManager. This is useful in general since
file operations will be abstracted in the future for the reproduction mechanism.
FileSystemOptions is independent of FileManager so that we can have multiple translation units sharing the same
FileManager but with different FileSystemOptions.
Addresses rdar://8583824.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118203 91177308-0d34-0410-b5e6-96231b3b80d8
emitting diagnostics in a binary form to be consumed by libclang,
since libclang no longer does any of its work out-of-process, making
this code dead. Besides, this stuff never worked at 100% anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116250 91177308-0d34-0410-b5e6-96231b3b80d8
This mainly prevents failures and/or crashes when multiple processes try to read/write the same PCH file. (rdar://8392711&8294781); suggestion & review by Daniel!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114187 91177308-0d34-0410-b5e6-96231b3b80d8
declarations (in addition to macros). Each kind of declaration maps to
a certain set of completion contexts, and the ASTUnit completion logic
introduces the completion strings for those declarations if the actual
code-completion occurs in one of the contexts where it matters.
There are a few new code-completion-context kinds. Without these,
certain completions (e.g., after "using namespace") would need to
suppress all global completions, which would be unfortunate.
Note that we don't get the priorities right for global completions,
because we don't have enough type information. We'll need a way to
compare types in an ASTContext-agnostic way before this can be
implemented.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111093 91177308-0d34-0410-b5e6-96231b3b80d8
completion within the translation unit using the same command-line
arguments for parsing the translation unit. Eventually, we'll reuse
the precompiled preamble to improve code-completion performance, and
this also gives us a place to cache results.
Expose this function via the new libclang function
clang_codeCompleteAt(), which performs the code completion within a
CXTranslationUnit. The completion occurs in-process
(clang_codeCompletion() runs code completion out-of-process).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110210 91177308-0d34-0410-b5e6-96231b3b80d8
of the usual consistency checks used to determine when a precompiled
header is incompatible with the translation unit it's being loaded
into.
Enable this option when loading a precompiled preamble, because the
preamble loader will be performing all of this checking itself. Enable
the preamble-based test now that it's working.
This option is also useful for debugging Clang's PCH
(<rdar://problem/7532213>).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109475 91177308-0d34-0410-b5e6-96231b3b80d8
separate count of "suppressed" errors. This way, semantic analysis
bits that depend on the error count to determine whether problems
occured (e.g., some template argument deduction failures, jump-scope
checking) will not get confused.
The actual problem here is that a missing #include (which is a fatal
error) could cause the jump-scope checker to run on invalid code,
which it is not prepared to do. Trivial fix for both
<rdar://problem/7775941> and <rdar://problem/7775709>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101297 91177308-0d34-0410-b5e6-96231b3b80d8
of errors and warnings. This allows us to emit something like this:
2 warnings and 1 error generated.
instead of:
3 diagnostics generated.
This also stops counting 'notes' because they are just follow-on information
about the previous diag, not a diagnostic in themselves.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100675 91177308-0d34-0410-b5e6-96231b3b80d8
actual action.
- This is easier to use, and more reliable for timing the thing this was
actually meant to be useful for.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98978 91177308-0d34-0410-b5e6-96231b3b80d8
we attach diagnostics to translation units and code-completion
results, so they can be queried at any time.
To facilitate this, the new StoredDiagnostic class stores a diagnostic
in a serializable/deserializable form, and ASTUnit knows how to
capture diagnostics in this stored form. CIndex's CXDiagnostic is a
thin wrapper around StoredDiagnostic, providing a C interface to
stored or de-serialized diagnostics.
I've XFAIL'd one test case temporarily, because currently we end up
storing diagnostics in an ASTUnit that's never returned to the user
(because it contains errors). I'll introduce a temporary fix for this
soon; the real fix will be to allow us to return and query invalid ASTs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96592 91177308-0d34-0410-b5e6-96231b3b80d8
This allows clients to install their own CompilerInvocation object, which is
important for clients that may wish to create references to things like
LangOptions whose lifetime will extend past that of the CompilerInstance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94923 91177308-0d34-0410-b5e6-96231b3b80d8
so that CIndex can report diagnostics through the normal mechanisms
even when executing Clang in a separate process. This applies both
when performing code completion and when using ASTs as an intermediary
for clang_createTranslationUnitFromSourceFile().
The serialized format is not perfect at the moment, because it does
not encapsulate macro-instantiation information. Instead, it maps all
source locations back to the instantiation location. However, it does
maintain source-range and fix-it information. To get perfect fidelity
from the serialized format would require serializing a large chunk of
the source manager; at present, it isn't clear if this code will live
long enough for that to matter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94740 91177308-0d34-0410-b5e6-96231b3b80d8
clang -cc1 logic for running an action against a set of options.
- This should make it easier to build tools that have a clang -cc1 like
interface, but aren't actually part of clang -cc1.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93282 91177308-0d34-0410-b5e6-96231b3b80d8
-remap-file=from;to
which takes the file "from" and transparently replaces its contents
with the contents of the file "to" from the source manager's
perspective. This is the moral equivalent of
cp from saved
cp to from
<call clang>
cp saved from
rm saved
without all of the pesky file copying.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90307 91177308-0d34-0410-b5e6-96231b3b80d8
files with the contents of an arbitrary memory buffer. Use this new
functionality to drastically clean up the way in which we handle file
truncation for code-completion: all of the truncation/completion logic
is now encapsulated in the preprocessor where it belongs
(<rdar://problem/7434737>).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90300 91177308-0d34-0410-b5e6-96231b3b80d8
- The design philosophy is in the CompilerInstance doxyment, if you don't agree
with it now would be a good time to speak up.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@87078 91177308-0d34-0410-b5e6-96231b3b80d8
Michael J. Spencer