rnk added a comment.
You've described the core issue with parsing C++ templates prior to
instantiation, you have to know what identifiers are types, and that's why we
need typename. :) MSVC only parses templates after instantiation, so it doesn't
need typename.
To deal with the specific case in ATL, we can use the 'new' expression as a
hint that the unknown identifier is actually a dependent type. There should be
some bit of context we can look at in DiagnoseUnknownTypeName to know that we
are in a new expression inside a dependent template, and then form a
DependentNameType to delay checking until template instantiation.
In the general case, I don't think we can ever behave exactly like MSVC without
implementing token-based template instantiation, and nobody wants to add an
entirely new, untested, separate codepath just for MSVC-style template
instantiation. It means giving up on compiling invalid C++ that MSVC accepts,
such as this:
template <typename T>
struct A : T {
void f() {
g(TypeOrFunction());
}
};
// In A<B>, it's a type
struct B {
struct TypeOrFunction { };
void g(TypeOrFunction);
};
template struct A<B>;
// In A<C>, it's a function
struct C {
int TypeOrFunction();
void g(int);
};
template struct A<C>;
http://reviews.llvm.org/D19479
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
