Start processing template-ids as types when the template-name refers
to a class template. For example, the template-id 'vector<int>' now
has a nice, sugary type in the type system. What we can do now:
- Parse template-ids like 'vector<int>' (where 'vector' names a
class template) and form proper types for them in the type system.
- Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly,
using (sadly) a bool in the parser to tell it whether '>' should
be treated as an operator or not.
This is a baby-step, with major problems and limitations:
- There are currently two ways that we handle template arguments
(whether they are types or expressions). These will be merged, and,
most likely, TemplateArg will disappear.
- We don't have any notion of the declaration of class template
specializations or of template instantiations, so all template-ids
are fancy names for 'int' :)
llvm-svn: 64153
diff --git a/clang/test/SemaTemplate/class-template-id.cpp b/clang/test/SemaTemplate/class-template-id.cpp
new file mode 100644
index 0000000..0bdc3e9
--- /dev/null
+++ b/clang/test/SemaTemplate/class-template-id.cpp
@@ -0,0 +1,17 @@
+// RUN: clang -fsyntax-only -verify %s
+template<typename T> struct A { };
+
+typedef A<int> A_int;
+
+float *foo(A<int> *ptr, A<int> const *ptr2) {
+ if (ptr)
+ return ptr; // expected-error{{incompatible type returning 'A<int> *', expected 'float *'}}
+ else if (ptr2)
+ return ptr2; // expected-error{{incompatible type returning 'A<int> const *', expected 'float *'}}
+ else {
+ // FIXME: This is completely bogus, but we're using it temporarily
+ // to test the syntactic sugar for class template specializations.
+ int *ip = ptr;
+ return 0;
+ }
+}