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
Douglas Gregor