2010-01-13 01:52:59 +08:00
|
|
|
// RUN: %clang_cc1 -fsyntax-only -verify %s
|
|
|
|
|
|
|
|
template<typename T, typename U>
|
|
|
|
struct X0 : T::template apply<U> {
|
|
|
|
X0(U u) : T::template apply<U>(u) { }
|
|
|
|
};
|
2010-01-13 05:28:44 +08:00
|
|
|
|
|
|
|
template<typename T, typename U>
|
2010-05-22 07:43:39 +08:00
|
|
|
struct X1 : T::apply<U> { }; // expected-error{{use 'template' keyword to treat 'apply' as a dependent template name}}
|
2010-01-13 05:28:44 +08:00
|
|
|
|
|
|
|
template<typename T>
|
2019-05-09 11:31:27 +08:00
|
|
|
struct X2 : vector<T> { }; // expected-error{{no template named 'vector'}}
|
2010-01-15 01:47:39 +08:00
|
|
|
|
|
|
|
namespace PR6031 {
|
|
|
|
template<typename T>
|
|
|
|
struct A;
|
|
|
|
|
|
|
|
template <class X>
|
|
|
|
struct C { };
|
|
|
|
|
|
|
|
template <class TT>
|
|
|
|
struct II {
|
|
|
|
typedef typename A<TT>::type type;
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class TT>
|
|
|
|
struct FI : II<TT>
|
|
|
|
{
|
|
|
|
C<typename FI::type> a;
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class TT>
|
|
|
|
struct FI2
|
|
|
|
{
|
2012-05-09 16:23:23 +08:00
|
|
|
C<typename FI2::type> a; // expected-error{{no type named 'type' in 'FI2<TT>'}}
|
2010-01-15 01:47:39 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
struct Base {
|
|
|
|
class Nested { };
|
|
|
|
template<typename U> struct MemberTemplate { };
|
|
|
|
int a;
|
|
|
|
};
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
struct HasDepBase : Base<T> {
|
|
|
|
int foo() {
|
|
|
|
class HasDepBase::Nested nested;
|
|
|
|
typedef typename HasDepBase::template MemberTemplate<T>::type type;
|
|
|
|
return HasDepBase::a;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
struct NoDepBase {
|
|
|
|
int foo() {
|
2010-04-01 07:17:41 +08:00
|
|
|
class NoDepBase::Nested nested; // expected-error{{no class named 'Nested' in 'NoDepBase<T>'}}
|
2018-05-11 10:43:08 +08:00
|
|
|
typedef typename NoDepBase::template MemberTemplate<T>::type type; // expected-error{{no member named 'MemberTemplate' in 'NoDepBase<T>'}} \
|
2010-01-15 01:47:39 +08:00
|
|
|
// FIXME: expected-error{{unqualified-id}}
|
2010-03-10 19:27:22 +08:00
|
|
|
return NoDepBase::a; // expected-error{{no member named 'a' in 'NoDepBase<T>'}}
|
2010-01-15 01:47:39 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
2010-01-15 09:44:47 +08:00
|
|
|
|
|
|
|
namespace Ambig {
|
|
|
|
template<typename T>
|
|
|
|
struct Base1 {
|
|
|
|
typedef int type; // expected-note{{member found by ambiguous name lookup}}
|
|
|
|
};
|
|
|
|
|
|
|
|
struct Base2 {
|
|
|
|
typedef float type; // expected-note{{member found by ambiguous name lookup}}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
struct Derived : Base1<T>, Base2 {
|
|
|
|
typedef typename Derived::type type; // expected-error{{member 'type' found in multiple base classes of different types}}
|
|
|
|
type *foo(float *fp) { return fp; }
|
|
|
|
};
|
|
|
|
|
|
|
|
Derived<int> di; // expected-note{{instantiation of}}
|
|
|
|
}
|
2010-01-20 00:01:07 +08:00
|
|
|
|
|
|
|
namespace PR6081 {
|
|
|
|
template<typename T>
|
|
|
|
struct A { };
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
class B : public A<T>
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
template< class X >
|
|
|
|
void f0(const X & k)
|
|
|
|
{
|
|
|
|
this->template f1<int>()(k);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
class C
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
template< class X >
|
|
|
|
void f0(const X & k)
|
|
|
|
{
|
2018-05-11 10:43:08 +08:00
|
|
|
this->template f1<int>()(k); // expected-error{{no member named 'f1' in 'C<T>'}} \
|
When we run into an error parsing or type-checking the left-hand side
of a binary expression, continue on and parse the right-hand side of
the binary expression anyway, but don't call the semantic actions to
type-check. Previously, we would see the error and then, effectively,
skip tokens until the end of the statement.
The result should be more useful recovery, both in the normal case
(we'll actually see errors beyond the first one in a statement), but
it also helps code completion do a much better job, because we do
"real" code completion on the right-hand side of an invalid binary
expression rather than completing with the recovery completion. For
example, given
x = p->y
if there is no variable named "x", we can still complete after the p->
as a member expression. Along the recovery path, we would have
completed after the "->" as if we were in an expression context, which
is mostly useless.
llvm-svn: 114225
2010-09-18 06:25:06 +08:00
|
|
|
// FIXME: expected-error{{unqualified-id}} \
|
|
|
|
// expected-error{{function-style cast or type construction}} \
|
|
|
|
// expected-error{{expected expression}}
|
2010-01-20 00:01:07 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
2010-02-27 08:25:28 +08:00
|
|
|
|
|
|
|
namespace PR6413 {
|
|
|
|
template <typename T> class Base_A { };
|
|
|
|
|
|
|
|
class Base_B { };
|
|
|
|
|
|
|
|
template <typename T>
|
|
|
|
class Derived
|
|
|
|
: public virtual Base_A<T>
|
|
|
|
, public virtual Base_B
|
|
|
|
{ };
|
|
|
|
}
|
2010-03-02 09:36:28 +08:00
|
|
|
|
|
|
|
namespace PR5812 {
|
|
|
|
template <class T> struct Base {
|
|
|
|
Base* p;
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class T> struct Derived: public Base<T> {
|
|
|
|
typename Derived::Base* p; // meaning Derived::Base<T>
|
|
|
|
};
|
|
|
|
|
|
|
|
Derived<int> di;
|
|
|
|
}
|