Commit Graph

4 Commits

Author SHA1 Message Date
Douglas Gregor dce2b62b70 Parsing, semantic analysis, and template instantiation for typename
specifiers that terminate in a simple-template-id, e.g.,

  typename MetaFun::template apply<T1, T2>

Also, implement template instantiation for dependent
nested-name-specifiers that involve unresolved identifiers, e.g.,

  typename T::type::type

llvm-svn: 68166
2009-04-01 00:28:59 +00:00
Douglas Gregor b046ffb002 Some cleanup and renaming. No functionality change
llvm-svn: 68140
2009-03-31 20:22:05 +00:00
Douglas Gregor aa59489b18 Implement template instantiation for template names, including both
template template parameters and dependent template names. For
example, the oft-mentioned

  typename MetaFun::template apply<T1, T2>::type

can now be instantiated, with the appropriate name lookup for "apply".

llvm-svn: 68128
2009-03-31 18:38:02 +00:00
Douglas Gregor dc572a3266 Improve the representation of template names in the AST. This
representation handles the various ways in which one can name a
template, including unqualified references ("vector"), qualified
references ("std::vector"), and dependent template names
("MetaFun::template apply").

One immediate effect of this change is that the representation of
nested-name-specifiers in type names for class template
specializations (e.g., std::vector<int>) is more accurate. Rather than
representing std::vector<int> as

  std::(vector<int>)

we represent it as

  (std::vector)<int>

which more closely follows the C++ grammar. 

Additionally, templates are no longer represented as declarations
(DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new
OpaquePtr type (TemplateTy) that holds the representation of a
TemplateName. This will simplify the handling of dependent
template-names, once we get there.

llvm-svn: 68074
2009-03-30 22:58:21 +00:00