Objective-C code completion within properties after "setter = " or
"getter = ", to provide suitable method names.

llvm-svn: 89334

Improve code completion for Objective-C message sends, so that we
provide completion results before each keyword argument, e.g.,

[foo Method:arg WithArg1:arg1 WithArg2:arg2]

We now complete befor

Improve code completion for Objective-C message sends, so that we
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".

llvm-svn: 89290

show more ...

Improve the accuracy of code completion for the attributes of an @property declaration, so that we don't produce completions for attributes that would conflict with already-specified attributes

llvm

Improve the accuracy of code completion for the attributes of an @property declaration, so that we don't produce completions for attributes that would conflict with already-specified attributes

llvm-svn: 89281

show more ...

Improve code-completion results for the flags in an @property
declaration by providing patterns for "getter = <method>" and "setter
= <method>". As part of this, invented a new "pattern" result kind

Improve code-completion results for the flags in an @property
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.

llvm-svn: 89277

show more ...

Rename CodeCompleteObjCProperty to something more specific. No functionality change.

llvm-svn: 89267

Code completion after @dynamic

llvm-svn: 89265

Code completion for Objective-C @synthesized.

llvm-svn: 89259

Implement code completion for Objective-C category names in @interface
and @implementation declarations.

llvm-svn: 89223

Code completion for Objective-C class names after @interface,
@implementation, and in the declaration of the superclass of an
@interface.

llvm-svn: 89207

Code completion after @property, providing the names of forward-declared properties

llvm-svn: 89196

Code completion for Objective-C properly lists

llvm-svn: 89194

Code completion for member accesses that involve Objective-C properties and instance variables

llvm-svn: 89182

Finish code completion for Objective-C message sends

llvm-svn: 89168

Rename Objective-C message send completion functions to indicate that we're referring to message sends

llvm-svn: 89164

Refactor code-completion support for message sends, collecting the
code to find and add Objective-C methods (starting at an
ObjCContainerDecl) into a single, static function. Also, make sure
that we

Refactor code-completion support for message sends, collecting the
code to find and add Objective-C methods (starting at an
ObjCContainerDecl) into a single, static function. Also, make sure
that we search into the implementations of classes and categories to
find even more methods.

llvm-svn: 89163

show more ...

Implement code completion for Objective-C message sends to "super".

llvm-svn: 89112

Augment code-completion results to provide argument names and
placeholder arguments for Objective-C message sends.

llvm-svn: 89103

Instead of hanging a using declaration's target decls directly off the using
decl, create shadow declarations and put them in scope like normal.
Work in progress.

llvm-svn: 89048

Rework Sema code completion interface.
- Provide Sema in callbacks, instead of requiring it in constructor. This
eliminates the need for a factory function. Clients now just pass the object
to

Rework Sema code completion interface.
- Provide Sema in callbacks, instead of requiring it in constructor. This
eliminates the need for a factory function. Clients now just pass the object
to consume the results in directly.

- CodeCompleteConsumer is cheap to construct, so building it whenever we are
doing code completion is reasonable.

Doug, please review.

llvm-svn: 87099

show more ...

Make sure that we look into nested, transparent declaration contexts
when looking for a name within a given DeclContext. Now enumerators
will show up in code-completion results.

llvm-svn: 86591

Add basic code completion support for ObjC messages.

Still a work in progress...

llvm-svn: 86323

Various improvements to Clang's code-completion infrastructure:
- Introduce more code-completion string "chunk" kinds that describe
symbols, the actual text that the user is expected to type, etc

Various improvements to Clang's code-completion infrastructure:
- Introduce more code-completion string "chunk" kinds that describe
symbols, the actual text that the user is expected to type, etc.
- Make the generation of macro results optional, since it can be
slow
- Make code-completion accessible through the C API, marshalling the
code-completion results through a temporary file (ick) to maintain
process separation.

The last doesn't have tests yet.

llvm-svn: 86306

show more ...

Include macros in code-completion results

llvm-svn: 85594

Track source information for template arguments and template specialization
types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable,

Track source information for template arguments and template specialization
types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.

llvm-svn: 85500

show more ...

Eliminate QualifiedDeclRefExpr, which captured the notion of a
qualified reference to a declaration that is not a non-static data
member or non-static member function, e.g.,

namespace N { int i;

Eliminate QualifiedDeclRefExpr, which captured the notion of a
qualified reference to a declaration that is not a non-static data
member or non-static member function, e.g.,

namespace N { int i; }
int j = N::i;

Instead, extend DeclRefExpr to optionally store the qualifier. Most
clients won't see or care about the difference (since
QualifierDeclRefExpr inherited DeclRefExpr). However, this reduces the
number of top-level expression types that clients need to cope with,
brings the implementation of DeclRefExpr into line with MemberExpr,
and simplifies and unifies our handling of declaration references.

Extended DeclRefExpr to (optionally) store explicitly-specified
template arguments. This occurs when naming a declaration via a
template-id (which will be stored in a TemplateIdRefExpr) that,
following template argument deduction and (possibly) overload
resolution, is replaced with a DeclRefExpr that refers to a template
specialization but maintains the template arguments as written.

llvm-svn: 84962

show more ...