2009-03-24 10:24:46 +08:00
|
|
|
// RUN: clang-cc -fsyntax-only -verify %s
|
2009-02-10 08:24:35 +08:00
|
|
|
|
|
|
|
template<template<typename T> class X> struct A; // expected-note 2{{previous template template parameter is here}}
|
|
|
|
|
|
|
|
template<template<typename T, int I> class X> struct B; // expected-note{{previous template template parameter is here}}
|
|
|
|
|
|
|
|
template<template<int I> class X> struct C; // expected-note{{previous non-type template parameter with type 'int' is here}}
|
|
|
|
|
|
|
|
template<class> struct X; // expected-note{{too few template parameters in template template argument}}
|
|
|
|
template<int N> struct Y; // expected-note{{template parameter has a different kind in template argument}}
|
|
|
|
template<long N> struct Ylong; // expected-note{{template non-type parameter has a different type 'long' in template argument}}
|
|
|
|
|
|
|
|
namespace N {
|
|
|
|
template<class> struct Z;
|
|
|
|
}
|
|
|
|
template<class, class> struct TooMany; // expected-note{{too many template parameters in template template argument}}
|
|
|
|
|
|
|
|
|
|
|
|
A<X> *a1;
|
|
|
|
A<N::Z> *a2;
|
|
|
|
A< ::N::Z> *a3;
|
|
|
|
|
Implement parsing of nested-name-specifiers that involve template-ids, e.g.,
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
2009-02-26 03:37:18 +08:00
|
|
|
A<Y> *a4; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
|
|
|
|
A<TooMany> *a5; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
|
|
|
|
B<X> *a6; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
|
2009-02-10 08:24:35 +08:00
|
|
|
C<Y> *a7;
|
Implement parsing of nested-name-specifiers that involve template-ids, e.g.,
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
2009-02-26 03:37:18 +08:00
|
|
|
C<Ylong> *a8; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
|
2009-02-10 08:24:35 +08:00
|
|
|
|
2009-06-26 06:08:12 +08:00
|
|
|
template<typename T> void f(int); // expected-note{{function template}}
|
2009-02-10 08:24:35 +08:00
|
|
|
|
|
|
|
// FIXME: we're right to provide an error message, but it should say
|
|
|
|
// that we need a class template. We won't get this right until name
|
|
|
|
// lookup of 'f' returns a TemplateDecl.
|
2009-06-26 06:08:12 +08:00
|
|
|
A<f> *a9; // expected-error{{template argument does not refer to}}
|
2009-02-10 08:24:35 +08:00
|
|
|
|
|
|
|
// FIXME: The code below is ill-formed, because of the evil digraph '<:'.
|
|
|
|
// We should provide a much better error message than we currently do.
|
|
|
|
// A<::N::Z> *a10;
|