template instantiation, since they cannot be dependent or have
dependent parts. Handle them the simple way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102094 91177308-0d34-0410-b5e6-96231b3b80d8
method being called at template definition time, retain that method
and pass it through to type-checking. We will not perform any lookup
for the method during template instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102081 91177308-0d34-0410-b5e6-96231b3b80d8
support dependent receivers for class and instance messages, along
with dependent message arguments (of course), and check as much as we
can at template definition time.
This commit also deals with a subtle aspect of template instantiation
in Objective-C++, where the type 'T *' can morph from a dependent
PointerType into a non-dependent ObjCObjectPointer type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102071 91177308-0d34-0410-b5e6-96231b3b80d8
function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101826 91177308-0d34-0410-b5e6-96231b3b80d8
nested-name-specifier (e.g., "class T::foo") fails to find a tag
member in the scope nominated by the
nested-name-specifier. Previously, we gave a bland
error: 'Nested' does not name a tag member in the specified scope
which didn't actually say where we were looking, which was rather
horrible when the nested-name-specifier was instantiated. Now, we give
something a bit better:
error: no class named 'Nested' in 'NoDepBase<T>'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100060 91177308-0d34-0410-b5e6-96231b3b80d8
(such as "class T::foo") from an ElaboratedType of a TypenameType to a
DependentNameType, which more accurately models the underlying
concept.
Improve template instantiation for DependentNameType nodes that
represent nested-name-specifiers, by performing tag name lookup and
checking the resulting tag appropriately. Fixes PR5681.
There is still much testing and cleanup to do in this area.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100054 91177308-0d34-0410-b5e6-96231b3b80d8
this was parsed as a typename-specifier, elaborated-type-specifier
(including the kind), or just a dependent qualified type name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100039 91177308-0d34-0410-b5e6-96231b3b80d8
the underlying/instantiated decl) through a lot of API, including "intermediate"
MemberExprs required for (e.g.) template instantiation. This is necessary
because of the access semantics of member accesses to using declarations:
only the base class *containing the using decl* need be accessible from the
naming class.
This allows us to complete an access-controlled selfhost, if there are no
recent regressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99936 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation. Based on a patch by Enea Zaffanella! I found a way to
reduce some of the redundancy between TreeTransform's "standard"
FunctionProtoType transformation and TemplateInstantiator's override,
and I killed off the old SubstFunctionType by adding type source info
for the last cases where we were creating FunctionDecls without TSI
(at least that get passed through template instantiation).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98252 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
nested-name-specifier. For example, this allows member access in
diamond-shaped hierarchies like:
struct Base {
void Foo();
int Member;
};
struct D1 : public Base {};
struct D2 : public Base {};
struct Derived : public D1, public D2 { }
void Test(Derived d) {
d.Member = 17; // error: ambiguous cast from Derived to Base
d.D1::Member = 17; // error: okay, modify D1's Base's Member
}
Fixes PR5820 and <rdar://problem/7535045>. Also, eliminate some
redundancy between Sema::PerformObjectMemberConversion() and
Sema::PerformObjectArgumentInitialization() -- the latter now calls
the former.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97674 91177308-0d34-0410-b5e6-96231b3b80d8
used to do this, but it got lost when we switched functional-style
cast syntax over to using the new initialization code. Fixes PR6457.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97568 91177308-0d34-0410-b5e6-96231b3b80d8
given declaration in a template, make sure that the context we're
searching through is complete. Fixes PR6376.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97444 91177308-0d34-0410-b5e6-96231b3b80d8
used when we instantiate C++ new expressions, delete expressions, and
object-construction expressions. Fixes PR6424, although we can't test
all of it until we finish implementing lookup of "operator delete" for
new expressions (!).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97195 91177308-0d34-0410-b5e6-96231b3b80d8
to mark the constructor as referenced. Fixes the narrow issue reported
in PR6424, but there are a few other places that I'll fix before
closing out that PR.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97185 91177308-0d34-0410-b5e6-96231b3b80d8
compilation using g++ v3.4.
I'll watch the buildbots and back out if necessary.
Feel free to do the same if something breaks.
Without this patch I get (on g++ 3.4.6) following error:
In file included from clang/lib/Sema/SemaTemplate.cpp:14:
clang/lib/Sema/TreeTransform.h: In member function `clang::ASTOwningResult<&clang::ActionBase::DeleteExpr> clang::TreeTransform<Derived>::RebuildCXXPseudoDestructorExpr(clang::ASTOwningResult<&clang::ActionBase::DeleteExpr>, clang::SourceLocation, bool, clang::NestedNameSpecifier*, clang::SourceRange, clang::TypeSourceInfo*, clang::SourceLocation, clang::SourceLocation, clang::PseudoDestructorTypeStorage)':
clang/lib/Sema/TreeTransform.h:5784: error: expected primary-expression before '>' token
clang/lib/Sema/TreeTransform.h:5784: error: expected primary-expression before ')' token
make[4]: *** [clang/lib/Sema/Release/SemaTemplate.o] Error 1
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97136 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
expressions that look like pseudo-destructors, e.g.,
p->T::~T()
where p has dependent type.
At template instantiate time, we determine whether we actually have a
pseudo-destructor or a member access, and funnel down to the
appropriate routine in Sema.
Fixes PR6380.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97092 91177308-0d34-0410-b5e6-96231b3b80d8
CXXPseudoDestructorExpr.
Update template instantiation for pseudo-destructor expressions to use
this source information and to make use of
Sema::BuildPseudoDestructorExpr when the base expression is dependent
or refers to a scalar type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97079 91177308-0d34-0410-b5e6-96231b3b80d8
destructor calls, e.g.,
p->T::~T
We now detect when the member access that we've parsed, e.g.,
p-> or x.
may be a pseudo-destructor expression, either because the type of p or
x is a scalar or because it is dependent (and, therefore, may become a
scalar at template instantiation time).
We then parse the pseudo-destructor grammar specifically:
::[opt] nested-name-specifier[opt] type-name :: ∼ type-name
and hand those results to a new action, ActOnPseudoDestructorExpr,
which will cope with both dependent member accesses of destructors and
with pseudo-destructor expressions.
This commit affects the parsing of pseudo-destructors, only; the
semantic actions still go through the semantic actions for member
access expressions. That will change soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97045 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
now cope with the destruction of types named as dependent templates,
e.g.,
y->template Y<T>::~Y()
Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't
follow the letter of the standard here because that would fail to
parse
template<typename T, typename U>
X0<T, U>::~X0() { }
properly. The problem is captured in core issue 339, which gives some
(but not enough!) guidance. I expect to revisit this code when the
resolution of 339 is clear, and/or we start capturing better source
information for DeclarationNames.
Fixes PR6152.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96367 91177308-0d34-0410-b5e6-96231b3b80d8
rebuilding a typename type terminating in a template-id (with
dependent template name, naturally) as a TypenameType when, because
its context could be fully resolved, we should have been building it
as a QualifiedNameType. Fixes PR6268.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96084 91177308-0d34-0410-b5e6-96231b3b80d8
realize that CXXConstructExpr is always implicit, so we should just
return its argument (if there is only one) rather than directly
invoking the constructor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95192 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Zhongxing Xu
Chandler Carruth
John McCall
Gabor Greif
John Thompson
Anders Carlsson