When we are in code-completion mode, skip parsing of all function bodies except the one where the
code-completion point resides.
For big .cpp files like 'SemaExpr.cpp' the improvement makes a huge difference, in some cases cutting down
code-completion time -62% !
We don't get diagnostics for the bodies though, so modify the code-completion tests that check for errors.
See rdar://8814203.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122765 91177308-0d34-0410-b5e6-96231b3b80d8
take into account the region of interest. Otherwise, we may fail to
traverse some important preprocessed entity cursors.
Fixes <rdar://problem/8554072>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122350 91177308-0d34-0410-b5e6-96231b3b80d8
classes, categories, protocols, and class extensions, where the
methods and properties of these entities would be inserted into the
DeclContext in an ordering that doesn't necessarily reflect source
order. The culprits were Sema::ActOnMethodDeclaration(), which did not
perform the insertion of the just-created method declaration into
the DeclContext for these Objective-C entities, and
Sema::ActOnAtEnd(), which inserted all method declarations at the
*end* of the DeclContext.
With this fix in hand, clean up the code-completion actions for
property setters/getters that worked around this brokenness in the AST.
Fixes <rdar://problem/8062781>, where this problem manifested as poor
token-annotation information, but this would have struck again in many
other places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122347 91177308-0d34-0410-b5e6-96231b3b80d8
global code completions are disabled (e.g., because they are
cached). Also, make sure that forward-declared protocols are visited
when we look for all visible names within a declaration context.
Previously, we would end up with duplicate completions for protocols.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121416 91177308-0d34-0410-b5e6-96231b3b80d8
trap the serialized preprocessing records (macro definitions, macro
instantiations, macro definitions) from the generation of the
precompiled preamble, then replay those when walking the list of
preprocessed entities. This eliminates a bug where clang_getCursor()
wasn't able to find preprocessed-entity cursors in the preamble.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120396 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C message sends, which have only whitespace in their
TypedText chunk. Such results have no purpose.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119569 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119516 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119514 91177308-0d34-0410-b5e6-96231b3b80d8
@synthesize foo = _foo;
keep track of the location of the ivar ("_foo"). Teach libclang to
visit the ivar as a member reference.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119447 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119409 91177308-0d34-0410-b5e6-96231b3b80d8
Now we explicitly memset all of its values.
This bug was uncovered by the 'Index/recursive-cxx-member-calls.cpp', which exhibited an assertion
on an i386 darwin build of clang. Adding this test case back since the assertion is now resolved.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118881 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118783 91177308-0d34-0410-b5e6-96231b3b80d8
and CXXCallMemberExprs. This scheme is hopefully general enough to extend to the
rest of the visitor if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118782 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
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118495 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118492 91177308-0d34-0410-b5e6-96231b3b80d8
to deeply nested BinaryOperators. This is done by turning the explicit recursion into being data recursive.
Fixes: <rdar://problem/8289205>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118444 91177308-0d34-0410-b5e6-96231b3b80d8
and we statically can compute a bound on the actual type (e.g.,
because it's a send to the the magic "class" instance method), code
complete as if we were performing a class message send to that class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118443 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118297 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118132 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118109 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117973 91177308-0d34-0410-b5e6-96231b3b80d8
This adds them where missing, and traces them through PCH. We fix at least one
bug in the extents found by the Index library, and make a lot of refactoring
tools which care about the exact formulation of a constructor call easier to
write. Also some minor cleanups to more consistently follow the friend pattern
instead of the setter pattern when rebuilding a serialized AST.
Patch originally by Samuel Benzaquen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117254 91177308-0d34-0410-b5e6-96231b3b80d8
more closely parallel the computation of linkage. This gets us to a state
much closer to what gcc emits, modulo bugs, which will undoubtedly arise in
abundance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117147 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117001 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116952 91177308-0d34-0410-b5e6-96231b3b80d8
type matches have a bigger impact. The impetus for this change was
that, when initializing an enumeration value, we want enumerators of
that enumeration type to have a higher priority than, e.g., unrelated
local variables.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116774 91177308-0d34-0410-b5e6-96231b3b80d8
C++/C99/Objective-C, so that we properly include types. This fix
affects global caching of code-completion results; without caching,
the behavior was already correct.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116757 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116746 91177308-0d34-0410-b5e6-96231b3b80d8
(after - or +), always traverse superclasses and all categories. The
programmer may want to complete a method from *anywhere*.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116723 91177308-0d34-0410-b5e6-96231b3b80d8