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
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
lookup in a member access expression always start a
nested-name-specifier. Additionally, rank names that start
nested-name-specifiers after other names.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82663 91177308-0d34-0410-b5e6-96231b3b80d8
results for other, textual completion. For call completion, we now
produce enough information to show the function call argument that we
are currently on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82592 91177308-0d34-0410-b5e6-96231b3b80d8
the start of a nested-name-specifier, add the "::" after the
nested-name-specifier to the code-completion string.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82587 91177308-0d34-0410-b5e6-96231b3b80d8
members found in base classes have the same ranking as members found
in derived classes. However, we will introduce an informative note for
members found in base classes, showing (as a nested-name-specifier)
the qualification to name the base class, to make it clear which
members are from bases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82586 91177308-0d34-0410-b5e6-96231b3b80d8
opening parentheses and after each comma. We gather the set of visible
overloaded functions, perform "partial" overloading based on the set
of arguments that we have thus far, and return the still-viable
results sorted by the likelihood that they will be the best candidate.
Most of the changes in this patch are a refactoring of the overloading
routines for a function call, since we needed to separate out the
notion of building an overload set (common to code-completion and
normal semantic analysis) and then what to do with that overload
set. As part of this change, I've pushed explicit template arguments
into a few more subroutines.
There is still much more work to do in this area. Function templates
won't be handled well (unless we happen to deduce all of the template
arguments before we hit the completion point), nor will overloaded
function-call operators or calls to member functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82549 91177308-0d34-0410-b5e6-96231b3b80d8
a nested-name-specifier that describes how to refer to that name. For
example, given:
struct Base { int member; };
struct Derived : Base { int member; };
the code-completion result for a member access into "Derived" will
provide both "member" to refer to Derived::member (no qualification needed) and
"Base::member" to refer to Base::member (qualification included).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82476 91177308-0d34-0410-b5e6-96231b3b80d8
enumerators when either the user intentionally wrote a qualified name
(in which case we just use that nested-name-specifier to match
the user's code) or when this is the first "case" statement and we
need a qualified name to refer to an enumerator in a different scope.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82474 91177308-0d34-0410-b5e6-96231b3b80d8
real work is performed within Sema. Addresses Chris's comments, but
still retains the heavyweight list-of-multimaps data structure.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82459 91177308-0d34-0410-b5e6-96231b3b80d8
- after "using", show anything that can be a nested-name-specifier.
- after "using namespace", show any visible namespaces or namespace aliases
- after "namespace", show any namespace definitions in the current scope
- after "namespace identifier = ", show any visible namespaces or
namespace aliases
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82251 91177308-0d34-0410-b5e6-96231b3b80d8
will provide the names of various enumerations currently
visible. Introduced filtering of code-completion results when we build
the result set, so that we can identify just the kinds of declarations
we want.
This implementation is incomplete for C++, since we don't consider
that the token after the tag keyword could start a
nested-name-specifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82222 91177308-0d34-0410-b5e6-96231b3b80d8
essence, code completion is triggered by a magic "code completion"
token produced by the lexer [*], which the parser recognizes at
certain points in the grammar. The parser then calls into the Action
object with the appropriate CodeCompletionXXX action.
Sema implements the CodeCompletionXXX callbacks by performing minimal
translation, then forwarding them to a CodeCompletionConsumer
subclass, which uses the results of semantic analysis to provide
code-completion results. At present, only a single, "printing" code
completion consumer is available, for regression testing and
debugging. However, the design is meant to permit other
code-completion consumers.
This initial commit contains two code-completion actions: one for
member access, e.g., "x." or "p->", and one for
nested-name-specifiers, e.g., "std::". More code-completion actions
will follow, along with improved gathering of code-completion results
for the various contexts.
[*] In the current -code-completion-dump testing/debugging mode, the
file is truncated at the completion point and EOF is translated into
"code completion".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82166 91177308-0d34-0410-b5e6-96231b3b80d8
John McCall