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
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89163 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@87099 91177308-0d34-0410-b5e6-96231b3b80d8
when looking for a name within a given DeclContext. Now enumerators
will show up in code-completion results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86591 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86306 91177308-0d34-0410-b5e6-96231b3b80d8
types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85500 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84962 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83680 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Benjamin Kramer
John McCall
Daniel Dunbar
Steve Naroff