-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.
llvm-svn: 119730
an implicit "this"; it causes clang_getCursor() to find the implicit
"this" expression (which isn't written in the source!) rather than the
actual member.
llvm-svn: 119516
interest (e.g., as used by clang_getCursor()), count the
decl-specifier-seq as part of the source range, as we do for
clang_annotateTokens(). Makes clang_getCursor() work properly for the
result types of functions, for example.
llvm-svn: 119514
we were just getting a range covering only the property name, which is
certainly not correct (and broke token annotation, among other
things).
Also, teach libclang about the relationship between
@synthesize/@dynamic and @property, so we get property name and
cursor-reference information for @synthesize and @dynamic.
llvm-svn: 119409
for the backing of generated USRs. This optmizes
for the case when a client generates a sequence
of USRs in sequence, disposing of them soon
after generating them. By using a string buffer,
we recycle malloc'ed memory instead of constantly
malloc'ing and copying strings.
llvm-svn: 119338
but to wrap both an ASTUnit and a "string pool"
that will be used for fast USR generation.
This requires a bunch of mechanical changes, as
there was a ton of code that assumed that CXTranslationUnit
and ASTUnit* were the same.
Along with this change, introduce CXStringBuf,
which provides an llvm::SmallVector<char> backing
for repeatedly generating CXStrings without a huge
amount of malloc() traffic. This requires making
some changes to the representation of CXString
by renaming a few fields (but keeping the size
of the object the same).
llvm-svn: 119337
caching global code-completion results. In particular, don't perform
either operation the first time we parse, but do both after the first
reparse.
llvm-svn: 119285
the Stmt* visitation in CursorVisitor to be
data-recursive.
Since AnnotationTokensWorker explicitly calls
CursorVisitor::VisitChildren(), it essentially
transforms the data-recursive algorithm in
CursorVisitor back into a non-data recursive one.
This is particularly bad because the data-recursive
algorithm uses more stack space per stack frame,
which can cause us to blow the stack in some cases.
"Fix" this by making the stack that AnnotationTokensWorker
runs in really huge. The real fix is to modify
AnnotationTokensWorker not to do the explicit
recursive call.
llvm-svn: 119047
is gradually becoming more data recursive, AnnotateTokensVisitor does its own recursive call
within the visitor that can still blow out the stack. This can potentially be reworked to avoid this,
but for now just do token annotation on a separate thread.
llvm-svn: 118783
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.
llvm-svn: 118751
location where we're spelling a token even within a
macro. clang_getInstantiationLocation() tells where we instantiated
the macro.
I'm still not thrilled with the CXSourceLocation/CXSourceRange APIs,
since they gloss over macro-instantiation information.
Take 2: this time, adjusted tests appropriately and used a "simple"
approach to the spelling location.
llvm-svn: 118495
location where we're spelling a token even within a
macro. clang_getInstantiationLocation() tells where we instantiated
the macro.
I'm still not thrilled with the CXSourceLocation/CXSourceRange APIs,
since they gloss over macro-instantiation information.
llvm-svn: 118492
to deeply nested BinaryOperators. This is done by turning the explicit recursion into being data recursive.
Fixes: <rdar://problem/8289205>
llvm-svn: 118444
abstractions (e.g., TemplateArgumentListBuilder) that were designed to
support variadic templates. Only a few remnants of variadic templates
remain, in the parser (parsing template type parameter packs), AST
(template type parameter pack bits and TemplateArgument::Pack), and
Sema; these are expected to be used in a future implementation of
variadic templates.
But don't get too excited about that happening now.
llvm-svn: 118385
CXXConstructorExpr/CXXTemporaryObjectExpr references the constructor
it calls. Then, tweak clang_getCursor() to prefer such a call over a
type reference to the type being called.
llvm-svn: 118297
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.
llvm-svn: 118203
ensuring that they cover all of their child nodes. There's still a
clang_getCursor()-related issue with CXXFunctionalCastExprs with
CXXConstructExprs as children (see FIXME in the test case); I'll look
at that separately.
llvm-svn: 118132
within an @implementation, but we have no way to record that information in the AST.
This may cause CursorVisitor to miss these Decls when doing a AST walk.
Fixes <rdar://problem/8595462>.
llvm-svn: 118109
to recover some context that is currently not modeled directly in the AST. Currently VarDecl's cannot
properly determine their source range because they have no context on whether or not they appear in a DeclGroup.
For the meantime, this bandaid suffices in libclang since that is where the correct SourceRange is directly needed.
Fixes <rdar://problem/8595749>.
llvm-svn: 117973
entities in the preprocessing record. Previously, we would only end up
getting the first token of a preprocessing record annotated
correctly. For example, given
#include "foo.h"
we would only get the '#' annotated as an inclusion directive; the
'include' and '"foo.h"' tokens would be given the general 'processing
directive' annotation.
Now, we get proper annotations for entities in the preprocessing
record.
llvm-svn: 117001
inclusion directives, keeping track of every #include, #import,
etc. in the translation unit. We keep track of the source location and
kind of the inclusion, how the file name was spelled, and the
underlying file to which the inclusion resolved.
llvm-svn: 116952
declaring methods and when sending messages to them, by bringing all
of the selector into TypedCheck chunks in the completion result. This
way, we can improve the sorting of these results to account for the
full selector name rather than just the first chunk.
llvm-svn: 116746
The previous method used the DESTDIR environment variable at configure
time, but sometimes it is only available at install time. See PR8397.
llvm-svn: 116689
The problem was that text files were open in text mode and Microsoft implementation of fread and write will try to do nasty line-feed conversion which make the line position no longer valid. The fix is to read and write files in binary mode.
llvm-svn: 116286
diagnostics produced by the driver itself. Previously, we were
allowing these to either be dropped or to slip through to stderr.
Fixes <rdar://problem/7595339>.
llvm-svn: 116285
on the presence of a 'clang' executable. Simplify
CIndexer::getClangResourcesPath() a bit.
Patch up the CMake makefiles to install headers into two locations in
the build tree, for those silly cases where 'clang' will end up
looking into the wrong build directory for headers.
llvm-svn: 116260
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.
llvm-svn: 116250
clang_codeCompleteAt(). This uncovered a few issues with the latter:
- ASTUnit wasn't saving/restoring diagnostic state appropriately between
reparses and code completions.
- "Overload" completions weren't being passed through to the client
llvm-svn: 116241
improvements to the compiler and the introduction of crash recovery,
it no longer makes sense to allow this mode. Moreover, this eliminates
one use of the "clang" executable from within libclang; we'd like them
all to go away.
llvm-svn: 116207
Argyrios Kyrtzidis