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
of a class template or class template partial specialization. That is to
say, in
template <class T> class A { ... };
or
template <class T> class B<const T*> { ... };
make 'A<T>' and 'B<const T*>' sugar for the corresponding InjectedClassNameType
when written inside the appropriate context. This allows us to track the
current instantiation appropriately even inside AST routines. It also allows
us to compute a DeclContext for a type much more efficiently, at some extra
cost every time we write a template specialization (which can be optimized,
but I've left it simple in this patch).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102407 91177308-0d34-0410-b5e6-96231b3b80d8
when they are not complete (since we could not match them up to
anything) and ensuring that enum parsing can cope with dependent
elaborated-type-specifiers. Fixes PR6915 and PR6649.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102247 91177308-0d34-0410-b5e6-96231b3b80d8
generally recover from typos in keywords (since we would effectively
have to mangle the token stream). However, there are still benefits to
typo-correcting with keywords:
- We don't make stupid suggestions when the user typed something
that is similar to a keyword.
- We can suggest the keyword in a diagnostic (did you mean
"static_cast"?), even if we can't recover and therefore don't have
a fix-it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101274 91177308-0d34-0410-b5e6-96231b3b80d8
injected class name of a class template or class template partial specialization.
This is a non-canonical type; the canonical type is still a template
specialization type. This becomes the TypeForDecl of the pattern declaration,
which cleans up some amount of code (and complicates some other parts, but
whatever).
Fixes PR6326 and probably a few others, primarily by re-establishing a few
invariants about TypeLoc sizes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98134 91177308-0d34-0410-b5e6-96231b3b80d8
class types, dependent types, and namespaces. I had previously
weakened this invariant while working on parsing pseudo-destructor
expressions, but recent work in that area has made these changes
unnecessary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97112 91177308-0d34-0410-b5e6-96231b3b80d8
pseudo-destructor expressions, and builds the CXXPseudoDestructorExpr
node directly. Currently, this only affects pseudo-destructor
expressions when they are parsed, but not after template
instantiation. That's coming next...
Improve parsing of pseudo-destructor-names. When parsing the
nested-name-specifier and we hit the sequence of tokens X :: ~, query
the actual module to determine whether X is a type-name (in which case
the X :: is part of the pseudo-destructor-name but not the
nested-name-specifier) or not (in which case the X :: is part of the
nested-name-specifier).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97058 91177308-0d34-0410-b5e6-96231b3b80d8
typedef int Int;
int *p;
p->Int::~Int();
This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96743 91177308-0d34-0410-b5e6-96231b3b80d8
in a member access expression referring into the current instantiation
need not be resolved at template definition *if* the current
instantiation has any dependent base classes. Fixes PR6081.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93877 91177308-0d34-0410-b5e6-96231b3b80d8
finds nothing), and the current instantiation has dependent base
classes, treat the qualified lookup as if it referred to an unknown
specialization. Fixes PR6031.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93433 91177308-0d34-0410-b5e6-96231b3b80d8
typo.cpp:18:1: error: use of undeclared identifier 'other_std'; did
you mean 'otherstd'?
other_std::strng str1;
^~~~~~~~~
otherstd
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92350 91177308-0d34-0410-b5e6-96231b3b80d8
the redeclaration problems in the [temp.explicit]p3 testcase worse, but I can
live with that; they'll need to be fixed more holistically anyhow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91771 91177308-0d34-0410-b5e6-96231b3b80d8
intended. On the first testcase in the bug, we now produce:
cxx-decl.cpp:12:2: error: unexpected ':' in nested name specifier
y:a a2;
^
::
instead of:
t.cc:8:1: error: C++ requires a type specifier for all declarations
x:a a2;
^
t.cc:8:2: error: invalid token after top level declarator
x:a a2;
^
;
t.cc:9:11: error: use of undeclared identifier 'a2'
x::a a3 = a2;
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90713 91177308-0d34-0410-b5e6-96231b3b80d8
LookupResult::getAsSingleDecl() is no more. Shift Sema::LookupSingleName to
return null on overloaded results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90309 91177308-0d34-0410-b5e6-96231b3b80d8
LookupResult RAII powers to diagnose ambiguity in the results. Other diagnostics
(e.g. access control and deprecation) will be moved to automatically trigger
during lookup as part of this same mechanism.
This abstraction makes it much easier to encapsulate aliasing declarations
(e.g. using declarations) inside the lookup system: eventually, lookup will
just produce the aliases in the LookupResult, and the standard access methods
will naturally strip the aliases off.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89027 91177308-0d34-0410-b5e6-96231b3b80d8
type of the object even when it is dependent. Specifically, this makes
sure that we get the right type for "this->", which is important when
performing name lookup into this scope to determine whether an
identifier or operator-function-id is a template name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86060 91177308-0d34-0410-b5e6-96231b3b80d8
what we found when we looked into <blah>", where <blah> is a
DeclContext*. We can now format DeclContext*'s in nice ways, e.g.,
"namespace N", "the global namespace", "'class Foo'".
This is part of PR3990, but we're not quite there yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84028 91177308-0d34-0410-b5e6-96231b3b80d8
complete (or, possibly causing template instantiation).
Test this via some explicit specializations of member functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82732 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
involve qualified names, e.g., x->Base::f. We now maintain enough
information in the AST to compare the results of the name lookup of
"Base" in the scope of the postfix-expression (determined at template
definition time) and in the type of the object expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80953 91177308-0d34-0410-b5e6-96231b3b80d8
with to properly support member access expressions in templates. This
test is XFAIL'd, because we get it completely wrong, but I've made the
minimal changes to the representation to at least avoid a crash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80856 91177308-0d34-0410-b5e6-96231b3b80d8
x->Base::f
We no longer try to "enter" the context of the type that "x" points
to. Instead, we drag that object type through the parser and pass it
into the Sema routines that need to know how to perform lookup within
member access expressions.
We now implement most of the crazy name lookup rules in C++
[basic.lookup.classref] for non-templated code, including performing
lookup both in the context of the type referred to by the member
access and in the scope of the member access itself and then detecting
ambiguities when the two lookups collide (p1 and p4; p3 and p7 are
still TODO). This change also corrects our handling of name lookup
within template arguments of template-ids inside the
nested-name-specifier (p6; we used to look into the scope of the
object expression for them) and fixes PR4703.
I have disabled some tests that involve member access expressions
where the object expression has dependent type, because we don't yet
have the ability to describe dependent nested-name-specifiers starting
with an identifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80843 91177308-0d34-0410-b5e6-96231b3b80d8
qualified name does not actually refer into a class/class
template/class template partial specialization.
Improve printing of nested-name-specifiers to eliminate redudant
qualifiers. Also, make it possible to output a nested-name-specifier
through a DiagnosticBuilder, although there are relatively few places
that will use this leeway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80056 91177308-0d34-0410-b5e6-96231b3b80d8
their members, including member class template, member function
templates, and member classes and functions of member templates.
To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,
template<typename X> template<typename Y>
X Outer<X>::Inner1<Y>::foo(Y) {
return X();
}
we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.
Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80044 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes PR4704 problems
Addresses Eli's patch feedback re: ugly cast code
Updates all postfix operators to remove ParenListExprs. While this is awful,
no better solution (say, in the parser) is obvious to me. Better solutions
welcome.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78621 91177308-0d34-0410-b5e6-96231b3b80d8
current instantiation when that current instantiation is a class
template partial specialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77609 91177308-0d34-0410-b5e6-96231b3b80d8
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77510 91177308-0d34-0410-b5e6-96231b3b80d8
templates, e.g.,
template<typename T>
struct Outer {
struct Inner;
};
template<typename T>
struct Outer<T>::Inner {
// ...
};
Implementing this feature required some extensions to ActOnTag, which
now takes a set of template parameter lists, and is the precursor to
removing the ActOnClassTemplate function from the parser Action
interface. The reason for this approach is simple: the parser cannot
tell the difference between a class template definition and the
definition of a member of a class template; both have template
parameter lists, and semantic analysis determines what that template
parameter list means.
There is still some cleanup to do with ActOnTag and
ActOnClassTemplate. This commit provides the basic functionality we
need, however.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76820 91177308-0d34-0410-b5e6-96231b3b80d8
cannot match that nested-name-specifier to a class template or class template
partial specialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76704 91177308-0d34-0410-b5e6-96231b3b80d8
John McCall
Douglas Gregor
Jeffrey Yasskin
Chris Lattner
Mike Stump
Anders Carlsson
Argyrios Kyrtzidis
Nate Begeman
Ted Kremenek