For each macro directive (define, undefine, visibility) have a separate object that gets chained
to the macro directive history. This has several benefits:
-No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like
PPMutationListener become unnecessary.
-No need to keep extra source locations for the undef/visibility locations for the define directive object
(which is the majority of the directives)
-Much easier to hide/unhide a section in the macro directive history.
-Easier to track the effects of the directives across different submodules.
llvm-svn: 178037
for self.GetterName where GetterName is the getter method
for a property with name different from the property name
(declared via a property getter attribute) // rdar://12791315
llvm-svn: 177744
This created 2 issues:
1) Performance issue, since typo-correction with PCH/modules is rather expensive.
2) Correctness issue, since if it managed to "correct" 'super' then bogus compiler errors would
be emitted, like this:
3.m:8:3: error: unknown type name 'super'; did you mean 'super1'?
super.x = 0;
^~~~~
super1
t3.m:5:13: note: 'super1' declared here
typedef int super1;
^
t3.m:8:8: error: expected identifier or '('
super.x = 0;
^
llvm-svn: 177126
for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)
(A MacroDirective always points to a MacroInfo object.)
Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).
For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.
Introducing the separation of macro concepts is the first part towards better modeling of module macros.
llvm-svn: 175585
The TypeLoc hierarchy used the llvm::cast machinery to perform undefined
behavior by casting pointers/references to TypeLoc objects to derived types
and then using the derived copy constructors (or even returning pointers to
derived types that actually point to the original TypeLoc object).
Some context is in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html
Though it's spread over a few months which can be hard to read in the mail
archive.
llvm-svn: 175462
Objective-C message receiver, the user is as likely to want to write a
type name as any other declaration, so give types the same priority as
other declarations. Fixes <rdar://problem/12480600>.
llvm-svn: 174038
consider (sub)module visibility.
The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:
visible_categories_iterator: Iterates over all visible categories
and extensions, hiding any that have their "hidden" bit set. This is
by far the most commonly used iterator.
known_categories_iterator: Iterates over all categories and
extensions, ignoring the "hidden" bit. This tends to be used for
redeclaration-like traversals.
visible_extensions_iterator: Iterates over all visible extensions,
hiding any that have their "hidden" bit set.
known_extensions_iterator: Iterates over all extensions, whether
they are visible to normal name lookup or not.
The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.
Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.
Part two of <rdar://problem/10634711>.
llvm-svn: 172665
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
write out the macro history for that macro. Similarly, we need to cope
with reading a macro definition that has been #undef'd.
Take advantage of this new ability so that global code-completion
results can refer to #undef'd macros, rather than losing them
entirely. For multiply defined/#undef'd macros, we will still get the
wrong result, but it's better than getting no result.
llvm-svn: 165502
Summary:
Summary: Keep history of macro definitions and #undefs with corresponding source locations, so that we can later find out all macros active in a specified source location. We don't save the history in PCH (no need currently). Memory overhead is about sizeof(void*)*3*<number of macro definitions and #undefs>+<in-memory size of all #undef'd macros>
I've run a test on a file composed of 109 .h files from boost 1.49 on x86-64 linux.
Stats before this patch:
*** Preprocessor Stats:
73222 directives found:
19171 #define.
4345 #undef.
#include/#include_next/#import:
5233 source files entered.
27 max include stack depth
19210 #if/#ifndef/#ifdef.
2384 #else/#elif.
6891 #endif.
408 #pragma.
14466 #if/#ifndef#ifdef regions skipped
80023/451669/1270 obj/fn/builtin macros expanded, 85724 on the fast path.
127145 token paste (##) operations performed, 11008 on the fast path.
Preprocessor Memory: 5874615B total
BumpPtr: 4399104
Macro Expanded Tokens: 417768
Predefines Buffer: 8135
Macros: 1048576
#pragma push_macro Info: 0
Poison Reasons: 1024
Comment Handlers: 8
Stats with this patch:
...
Preprocessor Memory: 7541687B total
BumpPtr: 6066176
Macro Expanded Tokens: 417768
Predefines Buffer: 8135
Macros: 1048576
#pragma push_macro Info: 0
Poison Reasons: 1024
Comment Handlers: 8
In my test increase in memory usage is about 1.7Mb, which is ~28% of initial preprocessor's memory usage and about 0.8% of clang's total VMM allocation.
As for CPU overhead, it should only be noticeable when iterating over all macros, and should mostly consist of couple extra dereferences and one comparison per macro + skipping of #undef'd macros. It's less trivial to measure, though, as the preprocessor consumes a very small fraction of compilation time.
Reviewers: doug.gregor, klimek, rsmith, djasper
Reviewed By: doug.gregor
CC: cfe-commits, chandlerc
Differential Revision: http://llvm-reviews.chandlerc.com/D28
llvm-svn: 162810
diagnostics for bad deployment targets and adding a few
more predicates. Includes a patch by Jonathan Schleifer
to enable ARC for ObjFW.
llvm-svn: 162252
Also, suggest 'readonly' even if the property has been given an ownership
attribute ('strong', 'weak', etc). This is used when properties are declared
readonly in the public interface but readwrite in a class extension.
<rdar://problem/11500004&11932285>
llvm-svn: 162220
Not only look for the comment near the declaration itself, but also walk the
redeclaration chain: the previous declaration might have had a documentation
comment.
llvm-svn: 161722
This also provides isConst/Volatile/Restrict on FunctionTypes to coalesce
the implementation with other callers (& update those other callers).
Patch contributed by Sam Panzer (panzer@google.com).
llvm-svn: 161647
attached to a declaration in the completion string.
Since extracting comments isn't free, a new code completion option is
introduced.
A new code completion option that enables including brief comments
into CodeCompletionString should be a, err, code completion option.
But because ASTUnit caches global declarations during parsing before
even completion consumer is created, the option is duplicated as a
translation unit option (in both libclang and ASTUnit, like the option
to cache code completion results).
llvm-svn: 159539
This behaves like the existing GNU __alignof and C++11 alignof keywords;
most of the patch is simply adding the third token spelling to various places.
llvm-svn: 159494
Specifically, @[] and @{} didn't have a type associated with them; we now
use "NSArray *" and "NSDictionary *", respectively. @"" has the type
"NSString *". @(), unfortunately, has type "id", since it (currently) may
be either an NSNumber or an NSString.
Add a test for all the Objective-C at-expression completions.
<rdar://problem/11507708&11507668&11507711>
llvm-svn: 158533
* Escape #, < and @ symbols where Doxygen would try to interpret them;
* Fix several function param documentation where names had got out of sync;
* Delete param documentation referring to parameters that no longer exist.
llvm-svn: 158472
OBJC_AT_KEYWORD_NAME take a string literal argument where previously
its second argument was an unquoted token; macro invocations such as
OBJC_AT_KEYWORD_NAME(NeedAt,{) confuse Doxygen's parser.
While I'm wary of changing code (rather than just comments) to work
around Doxygen's limitations, in this case the change makes the code
more readable for human beings as well, and the macro derived no
benefit from using the preprocessor's stringification operator, as
it never has need of the unquoted token.
I've also included a couple of trivial drive-by fixes to doc comments.
llvm-svn: 158440
In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.
This rolls back r155808 and r155869.
Review by Doug Gregor incorporating feedback from Chandler Carruth.
llvm-svn: 158104
to get a const char* if necessary.
This avoids unnecessary conversions when we want to use the result of getName as
a StringRef.
Part of rdar://10796159
llvm-svn: 156227
filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.
This change errs on the side of value, making op-> return T* and op* return
T&.
(reviewed by Richard Smith)
llvm-svn: 155808
code-completion related strings specific to a translation unit (ASTContext and related data)
CodeCompletionAllocator does such limited caching, by caching the name assigned
to a DeclContext*, but that is not the appropriate place since that object has
a lifetime that can extend beyond that of an ASTContext.
Introduce CodeCompletionTUInfo which will be always tied to a translation unit
to do this kind of caching and move the caching of CodeCompletionAllocator into this
object, and propagate it to all the places where it will be needed.
The plan is to extend the caching where appropriate, using CodeCompletionTUInfo,
to avoid re-calculating code-completion strings.
Part of rdar://10796159.
llvm-svn: 154408
a view over the contents of a DeclContext without exposing the implementation
details of the StoredDeclsMap. Use this in LookupVisibleDecls to find the
visible declarations. Fixes PR12339!
llvm-svn: 153970
completion item. For example, if the code completion itself represents
a declaration in a namespace (say, std::vector), then this API
retrieves the cursor kind and name of the namespace (std). Implements
<rdar://problem/11121951>.
llvm-svn: 153545
This makes sense because chunk's ctor is also out of line and simplifies considerably
when inlined with a constant parameter. Shrinks clang on i386-linux-Release+Asserts by 65k.
llvm-svn: 153446
ObjCInterfaceDecl::getReferencedProtocols(), because the iterators are safe to use
even if the caller did not check that the interface is a definition.
llvm-svn: 152597
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
argument, which was broken and very ugly (and even had a test case to
make *sure* it was broken and ugly). Fixes <rdar://problem/10609117>.
llvm-svn: 148606
does not depend on Sema, it accepts an ASTContext and a Preprocessor.
Step towards making clang_getCursorCompletionString not depend on Sema.
llvm-svn: 148278
separately-allocated DefinitionData structure. Introduce various
functions that will help with the separation of declarations from
definitions (isThisDeclarationADefinition(), hasDefinition(),
getDefinition()).
llvm-svn: 147408
declarations and definitions) as ObjCInterfaceDecls within the same
redeclaration chain. This new representation matches what we do for
C/C++ variables/functions/classes/templates/etc., and makes it
possible to answer the query "where are all of the declarations of
this class?"
llvm-svn: 146679
separately-allocated DefinitionData structure, which we manage the
same way as CXXRecordDecl::DefinitionData. This prepares the way for
making ObjCInterfaceDecls redeclarable, to more accurately model
forward declarations of Objective-C classes and eliminate the mutation
of ObjCInterfaceDecl that causes us serious trouble in the AST reader.
Note that ObjCInterfaceDecl's accessors are fairly robust against
being applied to forward declarations, because Clang (and Sema in
particular) doesn't perform RequireCompleteType/hasDefinition() checks
everywhere it has to. Each of these overly-robust cases is marked with
a FIXME, which we can tackle over time.
llvm-svn: 146644
to types. Enable this flag for code completion, where knowing whether
something is in an anonymous or inline namespace is actually not
useful, since you don't have to type it anyway. Fixes
<rdar://problem/10208818>.
llvm-svn: 143599
arguments as block literal arguments; the block literal argument code
completion should only go one level deep. Fixes <rdar://problem/10291294>.
llvm-svn: 142335
synthesis. This new feature is currently placed under
-fobjc-default-synthesize-properties option
and is off by default pending further testing.
It will become the default feature soon.
// rdar://8843851
llvm-svn: 138913
, such as list of forward @class decls, in a DeclGroup
node. Deal with its consequence throught clang. This
is in preparation for more Sema work ahead. // rdar://8843851.
Feel free to reverse if it breaks something important
and I am unavailable.
llvm-svn: 138709
to modernity. Instead of passing down individual
context objects from parser to sema, establish decl
context in parser and have sema access current context
as needed. I still need to take of Doug's comment for
minor cleanups.
llvm-svn: 138040
ActOnStartOfSwitchStmt (i.e. before binding up a full-expression)
instead of ActOnFinishSwitchStmt.
Among other things, this means that property l-values are properly
converted inside the full-expression.
llvm-svn: 137014
variadic bit (", ..." or ", args...") into the prior placeholder, like
we do with functions and methods. Fixes <rdar://problem/9740808>.
llvm-svn: 136563
already-defined and forward-declared results. Already-defined results
are fine because they could be the start of a category. Fixes
<rdar://problem/9811691>.
llvm-svn: 136559
clang_codeCompleteGetContexts(), that provides the client with
information about the context in which code completion has occurred
and what kinds of entities make sense as completions at that
point. Patch by Connor Wakamo!
llvm-svn: 134615
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
+keyPathsForValuesAffecting<Key> completion was mislabeled as an
instance method, and +automaticallyNotifiesObserversOf<Key> was
missing entirely. Fixes <rdar://problem/9516762>.
llvm-svn: 132452
that we've previously seen, both in declared methods and from previous
KVC completions, to eliminate duplicates. Fixes <rdar://problem/9162207>.
llvm-svn: 130890
implementation such as
@synthesize Prop1 =
Give priority to ivars whose type matches or closely matches the
property type (as we do for several other kinds of
results). Additionally, if there is an ivar with the same name as the
property, or differs only due to a _ prefix or suffix, give that ivar
a priority bump. Finally, verify that this search is properly
returning ivars within class extensions and implementations
(<rdar://problem/8488854>).
llvm-svn: 129699
completion, look through block pointer and function pointer types to the
result type of the block/function. Fixes <rdar://problem/9282583>.
llvm-svn: 129535
RTTI is disabled. Similarly, don't suggest throw or try as code
completion results when C++ exceptions are disabled. Fixes
<rdar://problem/9193560>.
llvm-svn: 129346
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
llvm-svn: 129143
enumeration type, prioritize the enumeration constants and don't
provide completions for any other expressions. Fixes <rdar://problem/7283668>.
llvm-svn: 125991
that was ignored in a few places (most notably, code
completion). Introduce Selector::getNameForSlot() for the common case
where we only care about the name. Audit all uses of
getIdentifierInfoForSlot(), switching many over to getNameForSlot(),
fixing a few crashers.
Fixed <rdar://problem/8939352>, a code-completion crasher.
llvm-svn: 125977
I will not hold on to temporary StringRefs.
I will not hold on to temporary StringRefs.
I will not hold on to temporary StringRefs.
I will not hold on to temporary StringRefs.
I will not hold on to temporary StringRefs.
I will not hold on to temporary StringRefs.
I will not hold on to temporary StringRefs.
I will not hold on to temporary StringRefs.
I will not hold on to temporary StringRefs.
I will not hold on to temporary StringRefs.
llvm-svn: 125718
separately handle the case of a local declaration-specifier list,
including all types in the set of options. Fixes
<rdar://problem/8790735> and <rdar://problem/8662831>.
llvm-svn: 125594
BumpPtrAllocator, rather than manually new/delete'ing them. This
optimization also allows us to avoid allocating memory for and copying
constant strings (e.g., "return", "class").
This also required embedding the priority and availability of results
within the code completion string, to avoid extra memory allocation
within libclang.
llvm-svn: 124673
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.
llvm-svn: 122347
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.
llvm-svn: 121416
struct X {
X() : au_i1(123) {}
union {
int au_i1;
float au_f1;
};
};
clang will now deal with au_i1 explicitly as an IndirectFieldDecl.
llvm-svn: 120900
That bug concerned the well-formedness of code such as (&ovl)(a, b,
c). GCC rejects the code, while EDG accepts it. On further study of the
standard, I see no support for EDG's position: in particular, C++
[over.over] does not list this as a context where we can take the
address of an overloaded function, C++ [over.call.func] does not
reference the address-of operator at any point, and C++ [expr.call]
claims that the function argument in a call is either a function
lvalue or a pointer-to-function; (&ovl) is neither.
llvm-svn: 118620
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.
llvm-svn: 118443
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.
llvm-svn: 116757
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
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
function/method argument, include the parameter name and always
include parentheses (even for zero-parameter blocks). Otherwise, the
block literal placeholder '^' can look very weird.
llvm-svn: 115444
provided when the optimization is disabled. In particular, split
the completion context CCC_Other into two contexts: CCC_Other, which
means that it's an undisclosed context for which any other results are
unwelcome, and CCC_Recovery, which is used in recovery cases.
Since we're now using the completion context within the completion
results builder, make sure that it's always set to something.
Fixes <rdar://problem/8470644>.
llvm-svn: 114704
message send, e.g.,
[[NSString alloc] initWithCString:<CC>
look up all of the possible methods and determine the preferred type
for the argument expression based on the type of the corresponding
parameter.
llvm-svn: 114379
Objective-C message sends. There is no functionality change here; this
is prep work for using the parameter types to help guide the
expression results when code-completing the argument.
llvm-svn: 114375
at the statement level or in Objective-C message receivers. Therefore,
just give types and declarations the same basic priority, and adjust
from there.
llvm-svn: 114374
statement context; it really isn't helpful in practice (remember
printf!) and we'll be doing other adjustments for statements very soon.
llvm-svn: 114358
- In Objective-C, we prefer BOOL to bool for historic reasons;
slightly penalize "bool".
- Treat Nil macro as a NULL pointer constant.
- Treat YES, NO, true, and false macros as constants.
- Treat the bool macro as a type.
llvm-svn: 114356
missing the opening bracket '[', e.g.,
NSArray <CC>
at function scope. Previously, we would only give trivial completions
(const, volatile, etc.), because we're in a "declaration name"
scope. Now, we also provide completions for class methods of NSArray,
e.g.,
alloc
Note that we already had support for this after the first argument,
e.g.,
NSArray method:x <CC>
would get code completion for class methods of NSArray whose selector
starts with "method:". This was already present because we recover
as if NSArray method:x were a class message send missing the opening
bracket (which was committed in r114057).
llvm-svn: 114078
'[' is missing. Prior commits improving recovery also improved code
completion beyond the first selector, e.g., at or after the "to" in
calculator add:x to:y
but not after "calculator". We now provide the same completions for
calculator <CC>
that we would for
[calculator <CC>
if "calculator" is an expression whose type is something that can
receive Objective-C messages.
This code completion works for instance and super message sends, but not
class message sends.
llvm-svn: 113976
expression, e.g., after the '(' that could also be a type cast. Here,
we provide types as code-completion results in C/Objective-C (C++
already had them), although we wouldn't in a normal expression context.
llvm-svn: 113904
constructor, in source order. Also introduces a new reference kind for
class members, which is used here (for member initializers) and will
also be used for designated initializers and offsetof.
llvm-svn: 113545
(and thus protocol_begin(), protocol_end()) now only contains the list of protocols that were directly referenced in
an @interface declaration. 'all_referenced_protocol_[begin,end]()' now returns the set of protocols that were referenced
in both the @interface and class extensions. The latter is needed for semantic analysis/codegen, while the former is
needed to maintain the lexical information of the original source.
Fixes <rdar://problem/8380046>.
llvm-svn: 112691
declaration send or a variadic function call, collapse the ", ..."
into the parameter before it, so that we don't get a second
placeholder.
llvm-svn: 112579
the parameter names from the completions, e.g., provide
withString:(NSString *)
instead of
withString:(NSString *)string
since the parameter name is, by convention, redundant with the
selector piece that precedes it and the completions can get
unnecessarily long.
llvm-svn: 112456
of prioritizing just by initialization order, we bump the priority of
just the *next* initializer in the list, and leave everything else at
the normal priority. That way, if one intentionally skips the
initialization of a base or member (to get default initialization),
we'll still get ordered completion for the rest.
llvm-svn: 112454
member function you're typing in overrides another virtual function,
this fills in a (qualified!) call to that virtual function to make
such delegation easy.
llvm-svn: 112294
a message send to "super" from a method that appears to be meant to
override a superclass method (same kind, same selector, same argument
types), provide a "super" completion that fills in the selector along
with forwarding the method's arguments (as placeholders).
llvm-svn: 112263
One who seeks the Tao unlearns something new every day.
Less and less remains until you arrive at non-action.
When you arrive at non-action,
nothing will be left undone.
llvm-svn: 112244
function, take into account the qualifiers on the object argument
(e.g., what will become "this"), filtering around uncallable member
functions and giving a slight priority boost to those with
exactly-matching qualifiers.
llvm-svn: 112193
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
Provide a libclang function that sorts the results.
3rd try. How embarrassing.
llvm-svn: 112180
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
Provide a libclang function that sorts the results.
llvm-svn: 112149
code-completion results cached by ASTUnit, sort the resulting result
set. This makes testing far, far easier, so this commit also includes
tests for the previous few fixes.
llvm-svn: 112070
argument in a for-each statement (e.g., "for (id x in <blah>)"), which
restricts the expression completions provided to Objective-C types (or
class types in C++).
llvm-svn: 111843
declarator. Here, we can only see a few things (e.g., cvr-qualifiers,
nested name specifiers) and we do not want to provide other non-macro
completions. Previously, we would end up in recovery mode and would
provide a large number of non-relevant completions.
llvm-svn: 111818
nested-name-specifiers. Also includes fixes to the generation of
nested-name-specifier result in the non-cached case; we were producing
lame results for namespaces and namespace aliases, which (1) didn't
always have nested-name-specifiers when we want them, and (2) did not
have the necessary "::" as part of the completion.
llvm-svn: 111203
type class, so that we can adjust priorities appropriately when the
preferred type for the context and the actual type of the completion
are similar.
This gets us one step closer to parity of the cached completion
results with the non-cached completion results.
llvm-svn: 111139
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.
llvm-svn: 111093
when the CXTranslationUnit_CacheCompletionResults option is given to
clang_parseTranslationUnit(). Essentially, we compute code-completion
results for macro definitions after we have parsed the file, then
store an ASTContext-agnostic version of those results (completion
string, cursor kind, priority, and active contexts) in the
ASTUnit. When performing code completion in that ASTUnit, we splice
the macro definition results into the results provided by the actual
code-completion (which has had macros turned off) before libclang gets
those results. We use completion context information to only splice in
those results that make sense for that context.
With a completion involving all of the macros from Cocoa.h and a few other
system libraries (totally ~8500 macro definitions) living in a
precompiled header, we get about a 9% performance improvement from
code completion, since we no longer have to deserialize all of the
macro definitions from the precompiled header.
Note that macro definitions are merely the canary; the cache is
designed to also support other top-level declarations, which should be
a bigger performance win. That optimization will be next.
Note also that there is no mechanism for determining when to throw
away the cache and recompute its contents.
llvm-svn: 111051
and create separate decl nodes for forward declarations and the
definition," which appears to be causing significant Objective-C
breakage.
llvm-svn: 110803
- Eagerly create ObjCInterfaceTypes for declarations.
- The two above changes lead to a 0.5% increase in memory use and no speed regression when parsing Cocoa.h. On the other hand, now chained PCH works when there's a forward declaration in one PCH and the interface definition in another.
- Add HandleInterestingDecl to ASTConsumer. PCHReader passes the "interesting" decls it finds to this function instead of HandleTopLevelDecl. The default implementation forwards to HandleTopLevelDecl, but ASTUnit's handler for example ignores them. This fixes a potential crash when lazy loading of PCH data would cause ASTUnit's "top level" declaration collection to change while being iterated.
llvm-svn: 110610
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).
llvm-svn: 110210
strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
llvm-svn: 108234
selector of an Objective-C method declaration, e.g., given
- (int)first:(int)x second:(int)y;
this code completion point triggers at the location of "second". It
will provide completions that fill out the method declaration for any
known method, anywhere in the translation unit.
llvm-svn: 107929
bring in the entire lookup table at once.
Also, give ExternalSemaSource's vtable a home. This is important because otherwise
any reference to it will cause RTTI to be emitted, and since clang is compiled
with -fno-rtti, that RTTI will contain unresolved references (to ExternalASTSource's
RTTI). So this change makes it possible to subclass ExternalSemaSource from projects
compiled with RTTI, as long as the subclass's home is compiled with -fno-rtti.
llvm-svn: 105268
type that we expect to see at a given point in the grammar, e.g., when
initializing a variable, returning a result, or calling a function. We
don't prune the candidate set at all, just adjust priorities to favor
things that should type-check, using an ultra-simplified type system.
llvm-svn: 105128
