llvm-svn: 90209

those associated with TemplateNames.

llvm-svn: 90162

llvm-svn: 90088

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.

llvm-svn: 89785

a new class.  Use it pervasively throughout Sema.

My fingers hurt.

llvm-svn: 89638

this information through lookup rather than rederiving it.

llvm-svn: 89570

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.

llvm-svn: 89544

"getter = ", to provide suitable method names.

llvm-svn: 89334

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

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

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

llvm-svn: 89267

llvm-svn: 89265

llvm-svn: 89259

and @implementation declarations.

llvm-svn: 89223

@implementation, and in the declaration of the superclass of an
@interface.

llvm-svn: 89207

llvm-svn: 89196

llvm-svn: 89194

llvm-svn: 89182

llvm-svn: 89168

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

llvm-svn: 89164

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

llvm-svn: 89112

placeholder arguments for Objective-C message sends. 

llvm-svn: 89103

decl, create shadow declarations and put them in scope like normal.
Work in progress.

llvm-svn: 89048

 - 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

when looking for a name within a given DeclContext. Now enumerators
will show up in code-completion results.

llvm-svn: 86591

Still a work in progress...

llvm-svn: 86323

  - 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

llvm-svn: 85594

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

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

llvm-svn: 84436

  - Filter out unnamed declarations
  - Filter out declarations whose names are reserved for the
  implementation (e.g., __bar, _Foo) 
  - Place OVERLOAD: or COMPLETION: at the beginning of each
  code-completion result, so we can easily separate them from other
  compilation results.

llvm-svn: 83680

- Fixup SortCodeCompleteResult() to properly sort keywords on Mac OS (compare was system dependent). Worked on Linux, failed on Mac OS (which caused the recently added testcase to fail on Linux). 
- Sort results in testcase.

llvm-svn: 83597

llvm-svn: 83579

llvm-svn: 82962

lookup in a member access expression always start a
nested-name-specifier. Additionally, rank names that start
nested-name-specifiers after other names.

llvm-svn: 82663

signature of the function with the current parameter highlighted as a
placeholder.

llvm-svn: 82593

results for other, textual completion. For call completion, we now
produce enough information to show the function call argument that we
are currently on.

llvm-svn: 82592