2009-12-16 04:14:24 +08:00
|
|
|
// RUN: %clang_cc1 -fsyntax-only -verify %s
|
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
|
|
|
|
|
|
|
namespace N {
|
|
|
|
namespace M {
|
2009-04-15 06:17:06 +08:00
|
|
|
template<typename T> struct Promote;
|
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
|
|
|
|
|
|
|
template<> struct Promote<short> {
|
|
|
|
typedef int type;
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct Promote<int> {
|
|
|
|
typedef int type;
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct Promote<float> {
|
|
|
|
typedef double type;
|
|
|
|
};
|
|
|
|
|
|
|
|
Promote<short>::type *ret_intptr(int* ip) { return ip; }
|
|
|
|
Promote<int>::type *ret_intptr2(int* ip) { return ip; }
|
|
|
|
}
|
|
|
|
|
|
|
|
M::Promote<int>::type *ret_intptr3(int* ip) { return ip; }
|
2010-06-17 06:31:08 +08:00
|
|
|
M::template Promote<int>::type *ret_intptr4(int* ip) { return ip; } // expected-warning{{'template' keyword outside of a template}}
|
2010-06-17 07:00:59 +08:00
|
|
|
M::template Promote<int> pi; // expected-warning{{'template' keyword outside of a template}}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
N::M::Promote<int>::type *ret_intptr5(int* ip) { return ip; }
|
|
|
|
::N::M::Promote<int>::type *ret_intptr6(int* ip) { return ip; }
|
|
|
|
|
|
|
|
|
2009-11-12 00:39:34 +08:00
|
|
|
N::M::template; // expected-error{{expected unqualified-id}}
|
|
|
|
N::M::template Promote; // expected-error{{expected unqualified-id}}
|
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
|
|
|
|
|
|
|
namespace N {
|
|
|
|
template<typename T> struct A;
|
|
|
|
|
|
|
|
template<>
|
|
|
|
struct A<int> {
|
|
|
|
struct X;
|
|
|
|
};
|
2009-03-31 08:43:58 +08:00
|
|
|
|
|
|
|
struct B;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
struct ::N::A<int>::X {
|
|
|
|
int foo;
|
|
|
|
};
|
2009-03-31 08:43:58 +08:00
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
struct TestA {
|
2009-11-12 00:39:34 +08:00
|
|
|
typedef typename N::template B<T>::type type; // expected-error{{'B' following the 'template' keyword does not refer to a template}} \
|
|
|
|
// expected-error{{expected member name}}
|
2009-03-31 08:43:58 +08:00
|
|
|
};
|
2010-04-30 07:50:39 +08:00
|
|
|
|
|
|
|
// Reduced from a Boost failure.
|
|
|
|
namespace test1 {
|
|
|
|
template <class T> struct pair {
|
|
|
|
T x;
|
|
|
|
T y;
|
|
|
|
|
|
|
|
static T pair<T>::* const mem_array[2];
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class T>
|
|
|
|
T pair<T>::* const pair<T>::mem_array[2] = { &pair<T>::x, &pair<T>::y };
|
|
|
|
}
|
2010-05-14 12:53:42 +08:00
|
|
|
|
|
|
|
typedef int T;
|
|
|
|
namespace N1 {
|
|
|
|
template<typename T> T f0();
|
|
|
|
}
|
|
|
|
|
|
|
|
template<typename T> T N1::f0() { }
|
2010-06-18 00:03:49 +08:00
|
|
|
|
|
|
|
namespace PR7385 {
|
|
|
|
template< typename > struct has_xxx0
|
|
|
|
{
|
|
|
|
template< typename > struct has_xxx0_introspect
|
|
|
|
{
|
|
|
|
template< typename > struct has_xxx0_substitute ;
|
|
|
|
template< typename V >
|
|
|
|
int int00( has_xxx0_substitute < typename V::template xxx< > > = 0 );
|
|
|
|
};
|
|
|
|
static const int value = has_xxx0_introspect<int>::value; // expected-error{{no member named 'value'}}
|
|
|
|
typedef int type;
|
|
|
|
};
|
|
|
|
|
|
|
|
has_xxx0<int>::type t; // expected-note{{instantiation of}}
|
|
|
|
}
|
2010-07-28 22:49:07 +08:00
|
|
|
|
|
|
|
namespace PR7725 {
|
|
|
|
template<class ignored> struct TypedefProvider;
|
|
|
|
template<typename T>
|
|
|
|
struct TemplateClass : public TypedefProvider<T>
|
|
|
|
{
|
|
|
|
void PrintSelf() {
|
|
|
|
TemplateClass::Test::PrintSelf();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|