summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/DeclTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Canonicality is a property of qualified types, not unqualified types.John McCall2009-10-221-1/+1
| | | | llvm-svn: 84891
* WIP implementation of explicit function template specialization. ThisDouglas Gregor2009-09-241-0/+6
| | | | | | | | | | | | | | | | | | | | | first implementation recognizes when a function declaration is an explicit function template specialization (based on the presence of a template<> header), performs template argument deduction + ambiguity resolution to determine which template is being specialized, and hooks There are many caveats here: - We completely and totally drop any explicitly-specified template arguments on the floor - We don't diagnose any of the extra semantic things that we should diagnose. - I haven't looked to see that we're getting the right linkage for explicit specializations On a happy note, this silences a bunch of errors that show up in libstdc++'s <iostream>, although Clang still can't get through the entire header. llvm-svn: 82728
* Improved representation and support for friend class templates. Angst about ↵John McCall2009-09-161-0/+16
| | | | | | same. llvm-svn: 82088
* Implement partial ordering of class template partial specializations Douglas Gregor2009-09-151-3/+4
| | | | | | (C++ [temp.class.order]). llvm-svn: 81866
* When stringizing a NamedDecl for a diagnostic, treat the templateJohn McCall2009-09-111-0/+13
| | | | | | specialization types differently. llvm-svn: 81512
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-44/+44
| | | | llvm-svn: 81346
* Remove TypeSpecStartLocation from VarDecl/FunctionDecl/FieldDecl, and use ↵Argyrios Kyrtzidis2009-08-211-4/+2
| | | | | | DeclaratorInfo to get this information. llvm-svn: 79584
* Introduce DeclaratorDecl and pass DeclaratorInfo through the Decl/Sema ↵Argyrios Kyrtzidis2009-08-191-1/+2
| | | | | | | | | | | | interfaces. DeclaratorDecl contains a DeclaratorInfo* to keep type source info. Subclasses of DeclaratorDecl are FieldDecl, FunctionDecl, and VarDecl. EnumConstantDecl still inherits from ValueDecl since it has no need for DeclaratorInfo. Decl/Sema interfaces accept a DeclaratorInfo as parameter but no DeclaratorInfo is created yet. llvm-svn: 79392
* Keep track of the template arguments deduced when matching a classDouglas Gregor2009-08-021-0/+16
| | | | | | | | template partial specialization. Then, use those template arguments when instantiating members of that class template partial specialization. Fixes PR4607. llvm-svn: 77925
* Support out-of-line definitions of the members of class templateDouglas Gregor2009-07-301-0/+15
| | | | | | partial specializations. llvm-svn: 77606
* Make tag declarations redeclarable. This change has three purposes:Douglas Gregor2009-07-291-4/+7
| | | | | | | | | | | | | | | | 1) Allow the Index library (and any other interested client) to walk the set of declarations for a given tag (enum, union, class, whatever). At the moment, this information is not readily available. 2) Reduce our dependence on TagDecl::TypeForDecl being mapped down to a TagType (for which getDecl() will return the tag definition, if one exists). This property won't exist for class template partial specializations. 3) Make the canonical declaration of a TagDecl actually canonical, e.g., so that it does not change when the tag is defined. llvm-svn: 77523
* Refactor the code that produces a TemplateSpecializationType, so thatDouglas Gregor2009-07-281-24/+5
| | | | | | | | canonicalization for dependent TemplateSpecializationTypes occurs within ASTContext::getTemplateSpecializationType. Also, move template argument canonicalization into ASTContext::getCanonicalTemplateArgument. llvm-svn: 77388
* Remove ASTContext::getCanonicalDecl() and use Decl::getCanonicalDecl in its ↵Argyrios Kyrtzidis2009-07-181-1/+1
| | | | | | place. llvm-svn: 76274
* Move the functionality of ASTContext::getCanonicalDecl(), into a virtual ↵Argyrios Kyrtzidis2009-07-181-0/+14
| | | | | | method Decl::getCanonicalDecl(). llvm-svn: 76273
* Keep track of function template specializations, to eliminateDouglas Gregor2009-06-291-1/+26
| | | | | | | redundant, implicit instantiations of function templates and provide a place where we can hang function template specializations. llvm-svn: 74454
* Check in a new template argument list builder that should work better for ↵Anders Carlsson2009-06-231-51/+75
| | | | | | variadic templates. llvm-svn: 73937
* Keep track of whether a type parameter type is a parameter pack.Anders Carlsson2009-06-161-1/+1
| | | | llvm-svn: 73452
* More parameter pack work.Anders Carlsson2009-06-151-10/+13
| | | | llvm-svn: 73395
* Add a new 'Pack' argument kind to TemplateArgument. This is not yet used.Anders Carlsson2009-06-151-0/+16
| | | | llvm-svn: 73391
* More work on type parameter packs.Anders Carlsson2009-06-131-1/+3
| | | | llvm-svn: 73281
* Improvements to TemplateArgumentListBuilder to make it work better with ↵Anders Carlsson2009-06-131-0/+18
| | | | | | parameter packs. llvm-svn: 73272
* Keep track of whether a type parameter is actually a type parameter pack.Anders Carlsson2009-06-121-2/+3
| | | | llvm-svn: 73261
* Avoid warnings.Mike Stump2009-06-051-0/+1
| | | | llvm-svn: 72976
* Make TemplateArgumentListBuilder take an ASTContext (because we're probably ↵Anders Carlsson2009-06-051-0/+13
| | | | | | going to need it later). Move push_back to the .cpp file. If the passed in template argument is a type, assert that it's canonical. llvm-svn: 72918
* Make the TemplateArgumentList take a TemplateArgumentListBuilder.Anders Carlsson2009-06-051-10/+9
| | | | llvm-svn: 72917
* Change the specialization decls to take a TemplateArgumentListBuilder.Anders Carlsson2009-06-051-10/+7
| | | | llvm-svn: 72916
* Initial infrastructure for class template partial specialization. HereDouglas Gregor2009-05-311-3/+26
| | | | | | | | | | | | | we have the basics of declaring and storing class template partial specializations, matching class template partial specializations at instantiation time via (limited) template argument deduction, and using the class template partial specialization's pattern for instantiation. This patch is enough to make a simple is_pointer type trait work, but not much else. llvm-svn: 72662
* Encapsulate template arguments lists in a new class,Douglas Gregor2009-05-111-12/+38
| | | | | | | | TemplateArgumentList. This avoids the need to pass around pointer/length pairs of template arguments lists, and will eventually make it easier to introduce member templates and variadic templates. llvm-svn: 71517
* Implement the semantics of the injected-class-name within a classDouglas Gregor2009-05-101-0/+59
| | | | | | | | | | | | | | | | | | template. The injected-class-name is either a type or a template, depending on whether a '<' follows it. As a type, the injected-class-name's template argument list contains its template parameters in declaration order. As part of this, add logic for canonicalizing declarations, and be sure to canonicalize declarations used in template names and template arguments. A TagType is dependent if the declaration it references is dependent. I'm not happy about the rather complicated protocol needed to use ASTContext::getTemplateSpecializationType. llvm-svn: 71408
* Introduce a new expression type, UnresolvedDeclRefExpr, that describesDouglas Gregor2009-03-191-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | dependent qualified-ids such as Fibonacci<N - 1>::value where N is a template parameter. These references are "unresolved" because the name is dependent and, therefore, cannot be resolved to a declaration node (as we would do for a DeclRefExpr or QualifiedDeclRefExpr). UnresolvedDeclRefExprs instantiate to DeclRefExprs, QualifiedDeclRefExprs, etc. Also, be a bit more careful about keeping only a single set of specializations for a class template, and instantiating from the definition of that template rather than a previous declaration. In general, we need a better solution for this for all TagDecls, because it's too easy to accidentally look at a declaration that isn't the definition. We can now process a simple Fibonacci computation described as a template metaprogram. llvm-svn: 67308
* Implement template instantiation for ClassTemplateSpecializationTypes,Douglas Gregor2009-03-091-0/+9
| | | | | | | | | | | | | | | | | | | | | | such as replacing 'T' in vector<T>. There are a few aspects to this: - Extend TemplateArgument to allow arbitrary expressions (an Expr*), and switch ClassTemplateSpecializationType to store TemplateArguments rather than it's own type-or-expression representation. - ClassTemplateSpecializationType can now store dependent types. In that case, the canonical type is another ClassTemplateSpecializationType (with default template arguments expanded) rather than a declaration (we don't build Decls for dependent types). - Split ActOnClassTemplateId into ActOnClassTemplateId (called from the parser) and CheckClassTemplateId (called from ActOnClassTemplateId and InstantiateType). They're smart enough to handle dependent types, now. llvm-svn: 66509
* Make the type associated with a ClassTemplateSpecializationDecl be aDouglas Gregor2009-02-261-1/+0
| | | | | | | | nicely sugared type that shows how the user wrote the actual specialization. This sugared type won't actually show up until we start doing instantiations. llvm-svn: 65577
* Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor2009-02-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
* Implement basic parsing and semantic analysis for explicitDouglas Gregor2009-02-171-5/+9
| | | | | | | | | | | | | | | | | | specialization of class templates, e.g., template<typename T> class X; template<> class X<int> { /* blah */ }; Each specialization is a different *Decl node (naturally), and can have different members. We keep track of forward declarations and definitions as for other class/struct/union types. This is only the basic framework: we still have to deal with checking the template headers properly, improving recovery when there are failures, handling nested name specifiers, etc. llvm-svn: 64848
* Added ClassTemplateSpecializationDecl, which is a subclass ofDouglas Gregor2009-02-171-0/+36
| | | | | | | | | | | | | | | | | | CXXRecordDecl that is used to represent class template specializations. These are canonical declarations that can refer to either an actual class template specialization in the code, e.g., template<> class vector<bool> { }; or to a template instantiation. However, neither of these features is actually implemented yet, so really we're just using (and uniqing) the declarations to make sure that, e.g., A<int> is a different type from A<float>. Note that we carefully distinguish between what the user wrote in the source code (e.g., "A<FLOAT>") and the semantic entity it represents (e.g., "A<float, int>"); the former is in the sugared Type, the latter is an actual Decl. llvm-svn: 64716
* 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