summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/DeclTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Allow the use of default template arguments when forming a classDouglas Gregor2009-02-111-0/+20
| | | | | | | | | | | | | | template specialization (e.g., std::vector<int> would now be well-formed, since it relies on a default argument for the Allocator template parameter). This is much less interesting than one might expect, since (1) we're not actually using the default arguments for anything important, such as naming an actual Decl, and (2) we'll often need to instantiate the default arguments to check their well-formedness. The real fun will come later. llvm-svn: 64310
* Implement parsing, semantic analysis and ASTs for default templateDouglas Gregor2009-02-101-0/+9
| | | | | | | | | arguments. This commit covers checking and merging default template arguments from previous declarations, but it does not cover the actual use of default template arguments when naming class template specializations. llvm-svn: 64229
* Eliminate TemplateArg so that we only have a single kind ofDouglas Gregor2009-02-091-5/+0
| | | | | | | | | | | | representation for template arguments. Also simplifies the interface for ActOnClassTemplateSpecialization and eliminates some annoying allocations of TemplateArgs. My attempt at smart pointers for template arguments lists is relatively lame. We can improve it once we're sure that we have the right representation for template arguments. llvm-svn: 64154
* Start processing template-ids as types when the template-name refersDouglas Gregor2009-02-091-0/+6
| | | | | | | | | | | | | | | | | | | | | 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
* Semantic checking for class template declarations andDouglas Gregor2009-02-061-5/+11
| | | | | | | | | | | | | | | redeclarations. For example, checks that a class template redeclaration has the same template parameters as previous declarations. Detangled class-template checking from ActOnTag, whose logic was getting rather convoluted because it tried to handle C, C++, and C++ template semantics in one shot. Made some inroads toward eliminating extraneous "declaration does not declare anything" errors by adding an "error" type specifier. llvm-svn: 63973
* Improve the representation of template type parameters. We nowDouglas Gregor2009-02-051-1/+2
| | | | | | | | | | | canonicalize by template parameter depth, index, and name, and the unnamed version of a template parameter serves as the canonical. TemplateTypeParmDecl no longer needs to inherit from TemplateParmPosition, since depth and index information is present within the type. llvm-svn: 63899
* Basic representation of C++ class templates, from Andrew Sutton.Douglas Gregor2009-02-041-0/+108
llvm-svn: 63750
OpenPOWER on IntegriCloud