'bool' rather than '_Bool' within types, to make things a bit more
readable. Fixes <rdar://problem/10063263>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140650 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138913 91177308-0d34-0410-b5e6-96231b3b80d8
, 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138709 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138040 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137014 91177308-0d34-0410-b5e6-96231b3b80d8
variadic bit (", ..." or ", args...") into the prior placeholder, like
we do with functions and methods. Fixes <rdar://problem/9740808>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136563 91177308-0d34-0410-b5e6-96231b3b80d8
already-defined and forward-declared results. Already-defined results
are fine because they could be the start of a category. Fixes
<rdar://problem/9811691>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136559 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134615 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
+keyPathsForValuesAffecting<Key> completion was mislabeled as an
instance method, and +automaticallyNotifiesObserversOf<Key> was
missing entirely. Fixes <rdar://problem/9516762>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132452 91177308-0d34-0410-b5e6-96231b3b80d8
that we've previously seen, both in declared methods and from previous
KVC completions, to eliminate duplicates. Fixes <rdar://problem/9162207>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130890 91177308-0d34-0410-b5e6-96231b3b80d8
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>).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129699 91177308-0d34-0410-b5e6-96231b3b80d8
implementation
@synthesize <property> =
also produce a completion for a to-be-synthesized ivar named
_<property>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129697 91177308-0d34-0410-b5e6-96231b3b80d8
completion, look through block pointer and function pointer types to the
result type of the block/function. Fixes <rdar://problem/9282583>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129535 91177308-0d34-0410-b5e6-96231b3b80d8
RTTI is disabled. Similarly, don't suggest throw or try as code
completion results when C++ exceptions are disabled. Fixes
<rdar://problem/9193560>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129346 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129143 91177308-0d34-0410-b5e6-96231b3b80d8
enumeration type, prioritize the enumeration constants and don't
provide completions for any other expressions. Fixes <rdar://problem/7283668>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125991 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125977 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125718 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C, also look in the categories and class extensions of our
superclasses. Fixes <rdar://problem/8853540>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125628 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125594 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124673 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
struct X {
X() : au_i1(123) {}
union {
int au_i1;
float au_f1;
};
};
clang will now deal with au_i1 explicitly as an IndirectFieldDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120900 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
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118620 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
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
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116241 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@115444 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114704 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114379 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114375 91177308-0d34-0410-b5e6-96231b3b80d8
at the statement level or in Objective-C message receivers. Therefore,
just give types and declarations the same basic priority, and adjust
from there.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114374 91177308-0d34-0410-b5e6-96231b3b80d8
various priority adjustments for preferences (based on selectors,
types) in a single function to make extension easier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114370 91177308-0d34-0410-b5e6-96231b3b80d8
statement context; it really isn't helpful in practice (remember
printf!) and we'll be doing other adjustments for statements very soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114358 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114356 91177308-0d34-0410-b5e6-96231b3b80d8
doesn't add any value. Instead, we'll just take the first method with
that selector that we find and create a completion for it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114082 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114078 91177308-0d34-0410-b5e6-96231b3b80d8
'[' 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113976 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113904 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113545 91177308-0d34-0410-b5e6-96231b3b80d8
(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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112691 91177308-0d34-0410-b5e6-96231b3b80d8
declaration send or a variadic function call, collapse the ", ..."
into the parameter before it, so that we don't get a second
placeholder.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112579 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112456 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112454 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112294 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112263 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112244 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112193 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112180 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112149 91177308-0d34-0410-b5e6-96231b3b80d8
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112095 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112070 91177308-0d34-0410-b5e6-96231b3b80d8
expect "natural" language and should not provide any completions,
e.g., comments, string literals, #error.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112054 91177308-0d34-0410-b5e6-96231b3b80d8
(e.g., for message sends or method declaration/definition
completions), adjust methods that come from a base class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112013 91177308-0d34-0410-b5e6-96231b3b80d8
e.g., after #ifdef/#ifndef or #undef, or inside a defined <macroname>
expression in a preprocessor conditional.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111954 91177308-0d34-0410-b5e6-96231b3b80d8
#include Sema.h while keeping all the AST declarations opaque. That may
not be reasonably attainable, though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111907 91177308-0d34-0410-b5e6-96231b3b80d8
the ", nil", ", NULL", or ", (void*)0" to the end of the code
completion, since it always has to be there anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111867 91177308-0d34-0410-b5e6-96231b3b80d8
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++).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111843 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111818 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111203 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111139 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111093 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111051 91177308-0d34-0410-b5e6-96231b3b80d8
the code-completion consumer. The consumer can use this information to
augument, filter, or display the code-completion results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110858 91177308-0d34-0410-b5e6-96231b3b80d8
and create separate decl nodes for forward declarations and the
definition," which appears to be causing significant Objective-C
breakage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110803 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110610 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110210 91177308-0d34-0410-b5e6-96231b3b80d8
condition is not of enumeration type, provide code-completion results
containing all values of integral or enumeral type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109677 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108234 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107929 91177308-0d34-0410-b5e6-96231b3b80d8
priority as other constants. And, if we're in a place where we prefer
a pointer type, consider "nil" and "NULL" to be close matches.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107910 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105268 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105128 91177308-0d34-0410-b5e6-96231b3b80d8
expression context in C/Objective-C, or when we're in an
@interface/@implementation/@protocol in Objective-C(++).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104908 91177308-0d34-0410-b5e6-96231b3b80d8
message. This completion gives better results than just using the
"expression" completion, which is effectively what happened before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104895 91177308-0d34-0410-b5e6-96231b3b80d8
1) Suppress diagnostics as soon as we form the code-completion
token, so we don't get any error/warning spew from the early
end-of-file.
2) If we consume a code-completion token when we weren't expecting
one, go into a code-completion recovery path that produces the best
results it can based on the context that the parser is in.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104585 91177308-0d34-0410-b5e6-96231b3b80d8
ObjCObjectType, which is basically just a pair of
one of {primitive-id, primitive-Class, user-defined @class}
with
a list of protocols.
An ObjCObjectPointerType is therefore just a pointer which always points to
one of these types (possibly sugared). ObjCInterfaceType is now just a kind
of ObjCObjectType which happens to not carry any protocols.
Alter a rather large number of use sites to use ObjCObjectType instead of
ObjCInterfaceType. Store an ObjCInterfaceType as a pointer on the decl rather
than hashing them in a FoldingSet. Remove some number of methods that are no
longer used, at least after this patch.
By simplifying ObjCObjectPointerType, we are now able to easily remove and apply
pointers to Objective-C types, which is crucial for a certain kind of ObjC++
metaprogramming common in WebKit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103870 91177308-0d34-0410-b5e6-96231b3b80d8
already knows what context it's looking in. Just pass that context in
instead of (questionably) recalculating it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102818 91177308-0d34-0410-b5e6-96231b3b80d8
way that C does. Among other differences, elaborated type specifiers
are defined to skip "non-types", which, as you might imagine, does not
include typedefs. Rework our use of IDNS masks to capture the semantics
of different kinds of declarations better, and remove most current lookup
filters. Removing the last remaining filter is more complicated and will
happen in a separate patch.
Fixes PR 6885 as well some spectrum of unfiled bugs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102164 91177308-0d34-0410-b5e6-96231b3b80d8
sends. Major changes include:
- Expanded the interface from two actions (ActOnInstanceMessage,
ActOnClassMessage), where ActOnClassMessage also handled sends to
"super" by checking whether the identifier was "super", to three
actions (ActOnInstanceMessage, ActOnClassMessage,
ActOnSuperMessage). Code completion has the same changes.
- The parser now resolves the type to which we are sending a class
message, so ActOnClassMessage now accepts a TypeTy* (rather than
an IdentifierInfo *). This opens the door to more interesting
types (for Objective-C++ support).
- Split ActOnInstanceMessage and ActOnClassMessage into parser
action functions (with their original names) and semantic
functions (BuildInstanceMessage and BuildClassMessage,
respectively). At present, this split is onyl used by
ActOnSuperMessage, which decides which kind of super message it
has and forwards to the appropriate Build*Message. In the future,
Build*Message will be used by template instantiation.
- Use getObjCMessageKind() within the disambiguation of Objective-C
message sends vs. array designators.
Two notes about substandard bits in this patch:
- There is some redundancy in the code in ParseObjCMessageExpr and
ParseInitializerWithPotentialDesignator; this will be addressed
shortly by centralizing the mapping from identifiers to type names
for the message receiver.
- There is some #if 0'd code that won't likely ever be used---it
handles the use of 'super' in methods whose class does not have a
superclass---but could be used to model GCC's behavior more
closely. This code will die in my next check-in, but I want it in
Subversion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102021 91177308-0d34-0410-b5e6-96231b3b80d8
expressions, to improve source-location information, clarify the
actual receiver of the message, and pave the way for proper C++
support. The ObjCMessageExpr node represents four different kinds of
message sends in a single AST node:
1) Send to a object instance described by an expression (e.g., [x method:5])
2) Send to a class described by the class name (e.g., [NSString method:5])
3) Send to a superclass class (e.g, [super method:5] in class method)
4) Send to a superclass instance (e.g., [super method:5] in instance method)
Previously these four cases where tangled together. Now, they have
more distinct representations. Specific changes:
1) Unchanged; the object instance is represented by an Expr*.
2) Previously stored the ObjCInterfaceDecl* referring to the class
receiving the message. Now stores a TypeSourceInfo* so that we know
how the class was spelled. This both maintains typedef information
and opens the door for more complicated C++ types (e.g., dependent
types). There was an alternative, unused representation of these
sends by naming the class via an IdentifierInfo *. In practice, we
either had an ObjCInterfaceDecl *, from which we would get the
IdentifierInfo *, or we fell into the case below...
3) Previously represented by a class message whose IdentifierInfo *
referred to "super". Sema and CodeGen would use isStr("super") to
determine if they had a send to super. Now represented as a
"class super" send, where we have both the location of the "super"
keyword and the ObjCInterfaceDecl* of the superclass we're
targetting (statically).
4) Previously represented by an instance message whose receiver is a
an ObjCSuperExpr, which Sema and CodeGen would check for via
isa<ObjCSuperExpr>(). Now represented as an "instance super" send,
where we have both the location of the "super" keyword and the
ObjCInterfaceDecl* of the superclass we're targetting
(statically). Note that ObjCSuperExpr only has one remaining use in
the AST, which is for "super.prop" references.
The new representation of ObjCMessageExpr is 2 pointers smaller than
the old one, since it combines more storage. It also eliminates a leak
when we loaded message-send expressions from a precompiled header. The
representation also feels much cleaner to me; comments welcome!
This patch attempts to maintain the same semantics we previously had
with Objective-C message sends. In several places, there are massive
changes that boil down to simply replacing a nested-if structure such
as:
if (message has a receiver expression) {
// instance message
if (isa<ObjCSuperExpr>(...)) {
// send to super
} else {
// send to an object
}
} else {
// class message
if (name->isStr("super")) {
// class send to super
} else {
// send to class
}
}
with a switch
switch (E->getReceiverKind()) {
case ObjCMessageExpr::SuperInstance: ...
case ObjCMessageExpr::Instance: ...
case ObjCMessageExpr::SuperClass: ...
case ObjCMessageExpr::Class:...
}
There are quite a few places (particularly in the checkers) where
send-to-super is effectively ignored. I've placed FIXMEs in most of
them, and attempted to address send-to-super in a reasonable way. This
could use some review.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101972 91177308-0d34-0410-b5e6-96231b3b80d8
in case it ends up doing something that might trigger diagnostics
(template instantiation, ambiguity reporting, access
reporting). Noticed while working on PR6831.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101412 91177308-0d34-0410-b5e6-96231b3b80d8
definitions, e.g., after
-
or
- (id)
we'll find all of the "likely" instance methods that one would want to
declare or define at this point. In the latter case, we only produce
results whose return types match "id".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100587 91177308-0d34-0410-b5e6-96231b3b80d8
while we're completing in the middle of a function call), also produce
"ordinary" name results that show what can be typed at that point.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100558 91177308-0d34-0410-b5e6-96231b3b80d8
statement or for ordinary names. This means that we won't show macros
when completing, e.g., member expressions such as "p->".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100555 91177308-0d34-0410-b5e6-96231b3b80d8
presence of precompiled headers by forcibly loading all of the
methods we know about from the PCH file before constructing our
code-completion list.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100535 91177308-0d34-0410-b5e6-96231b3b80d8
"id" or an expression of type "id". In these cases, we produce a list
of all of the (class or instance) methods, respectively, that we know about.
Note that this implementation does not yet work well with precompiled
headers; that's coming soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100528 91177308-0d34-0410-b5e6-96231b3b80d8
of file locations for anonymous tag types (e.g., "enum <anonymous at
t.h:15:6>"), which can get rather long.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100470 91177308-0d34-0410-b5e6-96231b3b80d8
entity (if applicable) which was actually looked up. If a candidate was found
via a using declaration, this is the UsingShadowDecl; otherwise, if
the candidate is template specialization, this is the template; otherwise,
this is the function.
The point of this exercise is that "found declarations" are the entities
we do access control for, not their underlying declarations. Broadly speaking,
this patch fixes access control for using declarations.
There is a *lot* of redundant code calling into the overload-resolution APIs;
we really ought to clean that up.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98945 91177308-0d34-0410-b5e6-96231b3b80d8
I'm expecting this portion of the AST to grow and change, and I'd like to
be able to do that with minimal recompilation. If this proves unnecessary
when access control is fully-implemented, I'll fold the classes back into
DeclCXX.h.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98249 91177308-0d34-0410-b5e6-96231b3b80d8
which has the label map, switch statement stack, etc. Previously, we
had a single set of maps in Sema (for the function) along with a stack
of block scopes. However, this lead to funky behavior with nested
functions, e.g., in the member functions of local classes.
The explicit-stack approach is far cleaner, and we retain a 1-element
cache so that we're not malloc/free'ing every time we enter a
function. Fixes PR6382.
Also, tweaked the unused-variable warning suppression logic to look at
errors within a given Scope rather than within a given function. The
prior code wasn't looking at the right number-of-errors count when
dealing with blocks, since the block's count would be deallocated
before we got to ActOnPopScope. This approach works with nested
blocks/functions, and gives tighter error recovery.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97518 91177308-0d34-0410-b5e6-96231b3b80d8
may be some other places that could take advantage of this new information,
but I haven't really looked yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95600 91177308-0d34-0410-b5e6-96231b3b80d8
lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:
const int i;
(void)(i + 17);
the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it.
We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
- the left-hand side of a '.' operator
- the left-hand side of an assignment
- a C++ throw expression
- a subscript expression that's subscripting a vector
Making this change exposed two issues with blocks:
- we were deducing const-qualified return types of non-class type
from a block return, which doesn't fit well
- we weren't always setting the known return type of a block when it
was provided with the ^return-type syntax
Fixes the current Clang-on-Clang compile failure and PR6076.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95167 91177308-0d34-0410-b5e6-96231b3b80d8
after adding the ability to determine whether our lookup is a
base-class lookup. Eliminate CollectMemberLookupResults, since it is
no longer used (yay).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93428 91177308-0d34-0410-b5e6-96231b3b80d8
than traversing visible declarations twice, only perform one traversal
and recognize nested-name-specifiers as special.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93418 91177308-0d34-0410-b5e6-96231b3b80d8
provided nested-name-specifier results for base classes (only), rather
than everything that could possibly be a nested-name-specifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93398 91177308-0d34-0410-b5e6-96231b3b80d8
LookupVisibleDecls, unifying the name lookup mechanisms used by code
completion and typo correction. Aside from the software-engineering
improvements, this makes code-completion see through using directives
and see ivars when performing unqualified name lookup in an
Objective-C instance method.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93397 91177308-0d34-0410-b5e6-96231b3b80d8
the "typed" text, first, then take into account
nested-name-specifiers, name hiding, etc. This means that the
resulting sort is actually alphabetical :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93370 91177308-0d34-0410-b5e6-96231b3b80d8
provide completions for @ keywords. Previously, we only provided
@-completions after an @ was actually typed, which is useful but
probably not the common case.
Also, make sure a few Objective-C 2.0 completions only show up when
Objective-C 2.0 support is enabled (the default).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93354 91177308-0d34-0410-b5e6-96231b3b80d8
C++ grammatical constructs that show up in top-level (namespace-level)
declarations, member declarations, template declarations, statements,
expressions, conditions, etc. For example, we now provide a pattern
for
static_cast<type>(expr)
when we can have an expression, or
using namespace identifier;
when we can have a using directive.
Also, improves the results of code completion at the beginning of a
top-level declaration. Previously, we would see value names (function
names, global variables, etc.); now we see types, namespace names,
etc., but no values.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93134 91177308-0d34-0410-b5e6-96231b3b80d8
tring str2;
we produce the following diagnostic + fix-it:
typo.cpp:15:1: error: unknown type name 'tring'; did you mean 'string'?
tring str2;
^~~~~
string
To make this really useful, we'll need to introduce typo correction in
many more places (wherever we do name lookup), and implement
declaration-vs-expression heuristics that cope with typos
better. However, for now this will handle the simple cases where we
already get good "unknown type name" diagnostics.
The LookupVisibleDecls functions are intended to be used by code
completion as well as typo correction; that refactoring will happen
later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92308 91177308-0d34-0410-b5e6-96231b3b80d8
function in a C++ call using an arbitrary call-expression type.
Actually exploit this to fix the recovery implemented earlier.
The diagnostic is still iffy, though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91538 91177308-0d34-0410-b5e6-96231b3b80d8
Remove isPod() from DenseMapInfo, splitting it out to its own
isPodLike type trait. This is a generally useful type trait for
more than just DenseMap, and we really care about whether something
acts like a pod, not whether it really is a pod.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91422 91177308-0d34-0410-b5e6-96231b3b80d8
specializations and class template partial specializations (they're
never named directly). Also, member access expressions only refer to
value declarations (fields, functions, enumerators, etc.) and
Objective-C property declarations; filter out everything else.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91133 91177308-0d34-0410-b5e6-96231b3b80d8
DependentScopeDeclRefExpr support storing templateids. Unite the common
code paths between ActOnDeclarationNameExpr and ActOnTemplateIdExpr.
This gets us to a point where we don't need to store function templates in
the AST using TemplateNames, which is critical to ripping out OverloadedFunction.
Also resolves a few FIXMEs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89785 91177308-0d34-0410-b5e6-96231b3b80d8
into pretty much everything about overload resolution in order to wean
BuildDeclarationNameExpr off LookupResult::getAsSingleDecl(). Replace
UnresolvedFunctionNameExpr with UnresolvedLookupExpr, which generalizes the
idea of a non-member lookup that we haven't totally resolved yet, whether by
overloading, argument-dependent lookup, or (eventually) the presence of
a function template in the lookup results.
Incidentally fixes a problem with argument-dependent lookup where we were
still performing ADL even when the lookup results contained something from
a block scope.
Incidentally improves a diagnostic when using an ObjC ivar from a class method.
This just fell out from rewriting BuildDeclarationNameExpr's interaction with
lookup, and I'm too apathetic to break it out.
The only remaining uses of OverloadedFunctionDecl that I know of are in
TemplateName and MemberExpr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89544 91177308-0d34-0410-b5e6-96231b3b80d8
provide completion results before each keyword argument, e.g.,
[foo Method:arg WithArg1:arg1 WithArg2:arg2]
We now complete before "WithArg1" and before "WithArg2", in addition
to completing before "Method".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89290 91177308-0d34-0410-b5e6-96231b3b80d8
declaration by providing patterns for "getter = <method>" and "setter
= <method>". As part of this, invented a new "pattern" result kind
that is merely a semantic string. The "pattern" result kind should
help with other kinds of code templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89277 91177308-0d34-0410-b5e6-96231b3b80d8
Argyrios Kyrtzidis