'struct A<double, int>'
In the "template instantiation depth exceeded" message, print
"-ftemplate-depth-N" rather than "-ftemplate-depth=N".
An unnamed tag type that is declared with a typedef, e.g.,
typedef struct { int x, y; } Point;
can be used as a template argument. Allow this, and check that we get
sensible pretty-printing for such things.
llvm-svn: 66560
response to attempts to diagnose an "incomplete" type. This will force
us to use DiagnoseIncompleteType more regularly (rather than looking at
isIncompleteType), but that's also a good thing.
Implicit instantiation is still very simplistic, and will create a new
definition for the class template specialization (as it should) but it
only actually instantiates the base classes and attaches
those. Actually instantiating class members will follow.
Also, instantiate the types of non-type template parameters before
checking them, allowing, e.g.,
template<typename T, T Value> struct Constant;
to work properly.
llvm-svn: 65924
decls. Test and document the semantic location of class template
specialization definitions that occur within a scope enclosing the
scope of the class template.
llvm-svn: 65478
specializations. In particular:
- Make sure class template specializations have a "template<>"
header, and complain if they don't.
- Make sure class template specializations are declared/defined
within a valid context. (e.g., you can't declare a specialization
std::vector<MyType> in the global namespace).
llvm-svn: 65476
std::vector<int>::allocator_type
When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:
template<> class Outer::Inner<int> { ... };
We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.
Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.
llvm-svn: 65467
specialization of class templates, e.g.,
template<typename T> class X;
template<> class X<int> { /* blah */ };
Each specialization is a different *Decl node (naturally), and can
have different members. We keep track of forward declarations and
definitions as for other class/struct/union types.
This is only the basic framework: we still have to deal with checking
the template headers properly, improving recovery when there are
failures, handling nested name specifiers, etc.
llvm-svn: 64848
Daniel Dunbar