| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
algorithm.
llvm-svn: 119437
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
the other side.
llvm-svn: 119349
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 119322
|
|
|
|
|
|
|
| |
their own .cpp file and make the interpretation
of its flags private.
llvm-svn: 119319
|
|
|
|
|
|
| |
traffic.
llvm-svn: 119290
|
|
|
|
|
|
|
| |
certain internal type-checking procedures as well as for representing
certain implicitly-generated operations. Uses to follow.
llvm-svn: 119289
|
|
|
|
| |
llvm-svn: 119287
|
|
|
|
| |
llvm-svn: 119282
|
|
|
|
|
|
|
| |
Clang currently uses a ridiculous amount of stack space when inlining
this function, which can lead to premature stack overflows.
llvm-svn: 119281
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
remaining Exprs still
covered by the normal recursive visitation.
llvm-svn: 119030
|
|
|
|
| |
llvm-svn: 119028
|
|
|
|
| |
llvm-svn: 118990
|
|
|
|
|
|
| |
data-recursive algorithm.
llvm-svn: 118989
|
|
|
|
|
|
|
|
| |
don't have to enqueue
its children and then reverse them.
llvm-svn: 118986
|
|
|
|
|
|
| |
to data-recursive algorithm.
llvm-svn: 118964
|
|
|
|
| |
llvm-svn: 118961
|
|
|
|
| |
llvm-svn: 118960
|
|
|
|
| |
llvm-svn: 118957
|
|
|
|
|
|
| |
switch statement to a StmtVisitor. No functionality change.
llvm-svn: 118956
|
|
|
|
|
|
| |
/llvm/tools/clang/tools/libclang/CIndex.cpp:1823: error: unused variable 'E' [-Wunused-variable]
llvm-svn: 118947
|
|
|
|
|
|
| |
algorithm.
llvm-svn: 118934
|
|
|
|
| |
llvm-svn: 118933
|
|
|
|
|
|
| |
data-recursion algorithm.
llvm-svn: 118929
|
|
|
|
| |
llvm-svn: 118928
|
|
|
|
| |
llvm-svn: 118927
|
|
|
|
|
|
| |
data-recursion algorithm.
llvm-svn: 118912
|
|
|
|
|
|
| |
worklist.
llvm-svn: 118911
|
|
|
|
| |
llvm-svn: 118910
|
|
|
|
|
|
| |
data-recursion algorithm.
llvm-svn: 118909
|
|
|
|
|
|
|
| |
SourceManager::getPresumedLoc(), so that we don't try to make use of
an invalid presumed location. Doing so can cause crashes.
llvm-svn: 118885
|
|
|
|
|
|
| |
data-recursion. Fixes <rdar://problem/8659019>.
llvm-svn: 118853
|
|
|
|
|
|
|
|
|
|
| |
While the CursorVisitor
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
|
|
|
|
|
|
|
| |
and CXXCallMemberExprs. This scheme is hopefully general enough to extend to the
rest of the visitor if necessary.
llvm-svn: 118782
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
avoid leaking memory.
Fixes rdar://8649963.
llvm-svn: 118674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 118494
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 118479
|
|
|
|
|
|
|
|
|
| |
we can blow out the stack due
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
|
|
|
|
|
|
| |
using "safety" threads.
llvm-svn: 118278
|
|
|
|
|
|
|
| |
thread, primarily to get a larger stack.
- Yes, I feel dirty.
llvm-svn: 118274
|
|
|
|
| |
llvm-svn: 118273
|
|
|
|
|
|
| |
preferably). Good thing c-index-test is written in C!!!!
llvm-svn: 118223
|