templates, and keep track of how those member classes were
instantiated or specialized.
Make sure that we don't try to instantiate an explicitly-specialized
member class of a class template, when that explicit specialization
was a declaration rather than a definition.
llvm-svn: 83547
track of the kind of specialization or instantiation. Also, check the
scope of the specialization and ensure that a specialization
declaration without an initializer is not a definition.
llvm-svn: 83533
function of a class template was implicitly instantiated, explicitly
instantiated (declaration or definition), or explicitly
specialized. The same MemberSpecializationInfo structure will be used
for static data members and member classes as well.
llvm-svn: 83509
templates. Previously, these weren't handled as specializations at
all. The AST for representing these as specializations is still a work
in progress.
llvm-svn: 83498
its definition may be defined, including in a class.
Also, put in an assertion when trying to instantiate a class template
partial specialization of a member template, which is not yet
implemented.
llvm-svn: 83469
declarations and explicit template instantiations, improving
diagnostics and making the code usable for function template
specializations (as well as class template specializations and partial
specializations).
llvm-svn: 83436
explicit specializations can occur. Also, fix a minor recovery bug
where we should allow declarations coming from the parser to be NULL.
llvm-svn: 83416
specializations such as:
friend class std::vector<int>;
by using the same code path as explicit specializations, customized to
reference an existing ClassTemplateSpecializationDecl (or build a new
"undeclared" one).
llvm-svn: 82875
class templates. We now treat friend class templates much more like
normal class templates, except that they still get special name lookup
rules. Fixes PR5057 and eliminates a bunch of spurious diagnostics in
<iostream>.
llvm-svn: 82848
template void f<int>(int);
~~~~~~
Previously, we silently dropped the template arguments. With this
change, we now use the template arguments (when available) as the
explicitly-specified template arguments used to aid template argument
deduction for explicit template instantiations.
llvm-svn: 82806
member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.
llvm-svn: 82789
first implementation recognizes when a function declaration is an
explicit function template specialization (based on the presence of a
template<> header), performs template argument deduction + ambiguity
resolution to determine which template is being specialized, and hooks
There are many caveats here:
- We completely and totally drop any explicitly-specified template
arguments on the floor
- We don't diagnose any of the extra semantic things that we should
diagnose.
- I haven't looked to see that we're getting the right linkage for
explicit specializations
On a happy note, this silences a bunch of errors that show up in
libstdc++'s <iostream>, although Clang still can't get through the
entire header.
llvm-svn: 82728
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
MarkUsedTemplateParameters, which is able to mark template parameters
used within non-deduced contexts as well as deduced contexts. Use this
to finish the implementation of [temp.deduct.partial]p11.
llvm-svn: 81794
instantiation definition can follow an explicit instantiation
declaration. This is as far as I want to go with extern templates now,
but they will still need quite a bit more work to get all of the C++0x
semantics right.
llvm-svn: 81573
from its location. Initialize appropriately.
When implicitly creating a declaration of a class template specialization
after encountering the first reference to it, use the pattern class's
location instead of the location of the first reference.
llvm-svn: 81515
templates, e.g.,
x.template get<T>
We can now parse these, represent them within an UnresolvedMemberExpr
expression, then instantiate that expression node in simple cases.
This allows us to stumble through parsing LLVM's Casting.h.
llvm-svn: 81300
templates. We now distinguish between an explicit instantiation
declaration and an explicit instantiation definition, and know not to
instantiate explicit instantiation declarations. Unfortunately, there
is some remaining confusion w.r.t. instantiation of out-of-line member
function definitions that causes trouble here.
llvm-svn: 81053
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.
llvm-svn: 80843
simple-template-id form), check whether the scope specifier is
computable as a declaration context rather than checking whether it is
dependent, so that we properly cope with members of the current
instantiation.
Improve testing for typename specifiers that terminate in a
simpe-template-id.
llvm-svn: 80783
to a multi-level template argument list by making it explicit. The
forced auditing of callers found a bug in the instantiation of member
classes inside member templates.
I *love* static type systems.
llvm-svn: 80391
When performing template instantiation of the definitions of member
templates (or members thereof), we build a data structure containing
the template arguments from each "level" of template
instantiation. During template instantiation, we substitute all levels
of template arguments simultaneously.
llvm-svn: 80389
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.
llvm-svn: 80044
the logic is there for out-of-line definitions with multiple levels of
nested templates, but this is still a work-in-progress: we're having
trouble determining when we should look into a dependent
nested-name-specifier.
llvm-svn: 80003
DeclaratorDecl contains a DeclaratorInfo* to keep type source info.
Subclasses of DeclaratorDecl are FieldDecl, FunctionDecl, and VarDecl.
EnumConstantDecl still inherits from ValueDecl since it has no need for DeclaratorInfo.
Decl/Sema interfaces accept a DeclaratorInfo as parameter but no DeclaratorInfo is created yet.
llvm-svn: 79392
we were going to enter into the scope of a class template or class
template partial specialization, rebuild that type so that it can
refer to members of the current instantiation, as in code like
template<typename T>
struct X {
typedef T* pointer;
pointer data();
};
template<typename T>
typename X<T>::pointer X<T>::data() { ... }
Without rebuilding the return type of this out-of-line definition, the
canonical return type of the out-of-line definition (a TypenameType)
will not match the canonical return type of the declaration (the
canonical type of T*).
llvm-svn: 78316
transformation template (TreeTransform) that handles the
transformation and reconstruction of AST nodes. Template instantiation
for types is a (relatively small) customization of the generic tree
transformation.
llvm-svn: 78071
