summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Make TemplateArgumentListBuilder take an ASTContext (because we're probably ↵Anders Carlsson2009-06-051-3/+3
| | | | | | 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-8/+6
| | | | llvm-svn: 72917
* Change the specialization decls to take a TemplateArgumentListBuilder.Anders Carlsson2009-06-051-17/+10
| | | | llvm-svn: 72916
* Add a helper class for building template argument lists.Anders Carlsson2009-06-051-37/+42
| | | | llvm-svn: 72915
* Fix another crash and actually make the test case work.Anders Carlsson2009-06-051-1/+1
| | | | llvm-svn: 72913
* Fix a case when the TemplateArgs vector can be empty.Anders Carlsson2009-06-051-1/+1
| | | | llvm-svn: 72911
* When performing template argument deduction, ensure that multipleDouglas Gregor2009-06-041-86/+14
| | | | | | | | | | deductions of the same template parameter are equivalent. This allows us to implement the is_same type trait (!). Also, move template argument deduction into its own file and update a few build systems with this change (grrrr). llvm-svn: 72819
* Initial infrastructure for class template partial specialization. HereDouglas Gregor2009-05-311-11/+134
| | | | | | | | | | | | | 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
* When we parse a tag specifier, keep track of whether that tagDouglas Gregor2009-05-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specifier resulted in the creation of a new TagDecl node, which happens either when the tag specifier was a definition or when the tag specifier was the first declaration of that tag type. This information has several uses, the first of which is implemented in this commit: 1) In C++, one is not allowed to define tag types within a type specifier (e.g., static_cast<struct S { int x; } *>(0) is ill-formed) or within the result or parameter types of a function. We now diagnose this. 2) We can extend DeclGroups to contain information about any tags that are declared/defined within the declaration specifiers of a variable, e.g., struct Point { int x, y, z; } p; This will help improve AST printing and template instantiation, among other things. 3) For C99, we can keep track of whether a tag type is defined within the type of a parameter, to properly cope with cases like, e.g., int bar(struct T2 { int x; } y) { struct T2 z; } We can also do similar things wherever there is a type specifier, e.g., to keep track of where the definition of S occurs in this legal C99 code: (struct S { int x, y; } *)0 llvm-svn: 72555
* Fix the type of a enum non-type template argument within the instantiation.Sebastian Redl2009-05-271-1/+1
| | | | llvm-svn: 72489
* Add some more tests for instantiation of declaration references. Also,Douglas Gregor2009-05-271-0/+3
| | | | | | improve some error recovery with explicit template instantiation. llvm-svn: 72484
* Use v.data() instead of &v[0] when SmallVector v might be empty.Jay Foad2009-05-211-1/+2
| | | | llvm-svn: 72210
* When instantiating the definition of a member function of a classDouglas Gregor2009-05-181-8/+2
| | | | | | | | | | | | | | template, introduce that member function into the template instantiation stack. Also, add diagnostics showing the member function within the instantiation stack and clean up the qualified-name printing so that we get something like: note: in instantiation of member function 'Switch1<int, 2, 2>::f' requested here in the template instantiation backtrace. llvm-svn: 72015
* Reflow some comments.Mike Stump2009-05-161-21/+18
| | | | llvm-svn: 71936
* Make sure that the type associated with a class template is dependent.Douglas Gregor2009-05-151-1/+10
| | | | llvm-svn: 71878
* Call ActOnStartOfFunctionDecl/ActOnFinishFunctionBody whenDouglas Gregor2009-05-151-7/+7
| | | | | | instantiating the definition of a function from a template. llvm-svn: 71869
* Introduce basic support for instantiating the definitions of memberDouglas Gregor2009-05-141-10/+2
| | | | | | | functions of class templates. Only compound statements and expression statements are currently implemented. llvm-svn: 71814
* In C++, warn when something previously declared as a "struct" is laterDouglas Gregor2009-05-141-7/+7
| | | | | | | declared as a "class", or vice-versa. This warning is under the control of -Wmismatched-tags, which is off by default. llvm-svn: 71773
* Implement explicit instantiations of member classes of class templates, e.g.,Douglas Gregor2009-05-141-1/+80
| | | | | | | | | | | | | | | | | | | | | | | | | template<typename T> struct X { struct Inner; }; template struct X<int>::Inner; This change is larger than it looks because it also fixes some a problem with nested-name-specifiers and tags. We weren't requiring the DeclContext associated with the scope specifier of a tag to be complete. Therefore, when looking for something like "struct X<int>::Inner", we weren't instantiating X<int>. This, naturally, uncovered a problem with member pointers, where we were requiring the left-hand side of a member pointer access expression (e.g., x->*) to be a complete type. However, this is wrong: the semantics of this expression does not require a complete type (EDG agrees). Stuart vouched for me. Blame him. llvm-svn: 71756
* Explicit instantiations of templates now instantiate the definitionsDouglas Gregor2009-05-131-3/+4
| | | | | | | | of class members (recursively). Only member classes are actually instantiated; the instantiation logic for member functions and variables are just stubs. llvm-svn: 71713
* Improve the semantic checking for explicit instantiations ofDouglas Gregor2009-05-131-27/+92
| | | | | | | | | | | | | | | | templates. In particular: - An explicit instantiation can follow an implicit instantiation (we were improperly diagnosing this as an error, previously). - In C++0x, an explicit instantiation that follows an explicit specialization of the same template specialization is ignored. In C++98, we just emit an extension warning. - In C++0x, an explicit instantiation must be in a namespace enclosing the original template. C++98 has no such requirement. Also, fixed a longstanding FIXME regarding the integral type that is used for the size of a constant array type when it is being instantiated. llvm-svn: 71689
* Semantic analysis for explicit instantiation of class templates. WeDouglas Gregor2009-05-131-0/+135
| | | | | | | | still aren't instantiating the definitions of class template members, and core issues 275 and 259 will both affect the checking that we do for explicit instantiations (but are not yet implemented). llvm-svn: 71613
* Encapsulate template arguments lists in a new class,Douglas Gregor2009-05-111-3/+9
| | | | | | | | 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 notions of the "current instantiation" and "unknownDouglas Gregor2009-05-111-8/+21
| | | | | | | | | | | | | | | | | | specialization" within a C++ template, and permit name lookup into the current instantiation. For example, given: template<typename T, typename U> struct X { typedef T type; X* x1; // current instantiation X<T, U> *x2; // current instantiation X<U, T> *x3; // not current instantiation ::X<type, U> *x4; // current instantiation X<typename X<type, U>::type, U>: *x5; // current instantiation }; llvm-svn: 71471
* With the introduction of nullptr, a template argument that refers to a ↵Douglas Gregor2009-05-101-4/+4
| | | | | | declaration can now be NULL. Use cast_or_null appropriately llvm-svn: 71412
* Implement the semantics of the injected-class-name within a classDouglas Gregor2009-05-101-13/+23
| | | | | | | | | | | | | | | | | | 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
* Implement C++0x nullptr.Sebastian Redl2009-05-101-2/+23
| | | | llvm-svn: 71405
* Compute the canonical template name when building a templateDouglas Gregor2009-05-071-2/+3
| | | | | | specialization type for a dependent template name. llvm-svn: 71153
* Start canonicalizing template names. This is not yet complete, but itDouglas Gregor2009-05-071-2/+2
| | | | | | improves type identity with dependent types. llvm-svn: 71152
* One can use "class" and "struct" interchangeably to refer to a classDouglas Gregor2009-05-031-2/+4
| | | | | | in C++. Fixes <rdar://problem/6815995>. llvm-svn: 70784
* Replace more release+static_cast with takeAs.Anders Carlsson2009-05-011-1/+1
| | | | llvm-svn: 70567
* Propagate the ASTContext to various AST traversal and lookup functions.Douglas Gregor2009-04-091-1/+1
| | | | | | No functionality change (really). llvm-svn: 68726
* Add some more code modification hintsDouglas Gregor2009-04-011-4/+9
| | | | llvm-svn: 68261
* Make parsing a semantic analysis a little more robust following SemaDouglas Gregor2009-04-011-1/+6
| | | | | | | | | | | | | | | | failures that involve malformed types, e.g., "typename X::foo" where "foo" isn't a type, or "std::vector<void>" that doens't instantiate properly. Similarly, be a bit smarter in our handling of ambiguities that occur in Sema::getTypeName, to eliminate duplicate error messages about ambiguous name lookup. This eliminates two XFAILs in test/SemaCXX, one of which was crying out to us, trying to tell us that we were producing repeated error messages. llvm-svn: 68251
* Parsing, semantic analysis, and template instantiation for typenameDouglas Gregor2009-04-011-0/+16
| | | | | | | | | | | | | 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
* Parsing and AST representation for dependent template names that occurDouglas Gregor2009-03-311-8/+126
| | | | | | | | | | | within nested-name-specifiers, e.g., for the "apply" in typename MetaFun::template apply<T1, T2>::type At present, we can't instantiate these nested-name-specifiers, so our testing is sketchy. llvm-svn: 68081
* Improve the representation of template names in the AST. ThisDouglas Gregor2009-03-301-55/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Introduce a new OpaquePtr<N> struct type, which is a simple POD wrapper for aChris Lattner2009-03-281-59/+56
| | | | | | | | | | | | | | | | | | | | pointer. Its purpose in life is to be a glorified void*, but which does not implicitly convert to void* or other OpaquePtr's with a different UID. Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>. Change the entire parser/sema interface to use DeclPtrTy instead of DeclTy*. This makes the C++ compiler enforce that these aren't convertible to other opaque types. We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc, but I don't plan to do that in the short term. The one outstanding known problem with this patch is that we lose the bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to bitmangle the success bit into the low bit of DeclPtrTy. I will rectify this with a subsequent patch. llvm-svn: 67952
* Initial implementation of parsing, semantic analysis, and templateDouglas Gregor2009-03-271-0/+81
| | | | | | | | | | | | | | | | | | | | | | | | instantiation for C++ typename-specifiers such as typename T::type The parsing of typename-specifiers is relatively easy thanks to annotation tokens. When we see the "typename", we parse the typename-specifier and produce a typename annotation token. There are only a few places where we need to handle this. We currently parse the typename-specifier form that terminates in an identifier, but not the simple-template-id form, e.g., typename T::template apply<U, V> Parsing of nested-name-specifiers has a similar problem, since at this point we don't have any representation of a class template specialization whose template-name is unknown. Semantic analysis is only partially complete, with some support for template instantiation that works for simple examples. llvm-svn: 67875
* Set the access specifier for templates inside classes.Anders Carlsson2009-03-261-0/+3
| | | | llvm-svn: 67726
* Handle parsing of templates in member declarations. Pass the AccessSpecifier ↵Anders Carlsson2009-03-261-1/+2
| | | | | | | | all the way down to ActOnClassTemplate. Doug, Sebastian: Plz review! :) llvm-svn: 67723
* The injected-class-name of class templates and class templateDouglas Gregor2009-03-261-2/+25
| | | | | | | | | | | | | | | | | | specializations can be treated as a template. Finally, we can parse and process the first implementation of Fibonacci I wrote! Note that this code does not handle all of the cases where injected-class-names can be treated as templates. In particular, there's an ambiguity case that we should be able to handle (but can't), e.g., template <class T> struct Base { }; template <class T> struct Derived : Base<int>, Base<char> { typename Derived::Base b; // error: ambiguous typename Derived::Base<double> d; // OK }; llvm-svn: 67720
* In Parser::ParseClassSpecifier, don't conflate a NULL declaration withDouglas Gregor2009-03-251-22/+18
| | | | | | | | failure to perform a declaration. Instead, explicitly note semantic failures that occur during template parsing with a DeclResult. Fixes PR3872. llvm-svn: 67659
* Type::isObjectType now implements the (more sensible) C++ definitionDouglas Gregor2009-03-241-3/+2
| | | | | | | | | | | | | | | | | | of "object type" rather than the C definition of "object type". The difference is that C's "object type" excludes incomplete types such as struct X; However, C's definition also makes it far too easy to use isObjectType as a means to detect incomplete types when in fact we should use other means (e.g., Sema::RequireCompleteType) that cope with C++ semantics, including template instantiation. I've already audited every use of isObjectType and isIncompleteType to ensure that they are doing the right thing for both C and C++, so this is patch does not change any functionality. llvm-svn: 67648
* Fix a few isObjectTypes that really need to be isIncompleteOrObjectDouglas Gregor2009-03-241-2/+3
| | | | | | types; add another use of RequireCompleteType. llvm-svn: 67644
* Introduce a new expression type, UnresolvedDeclRefExpr, that describesDouglas Gregor2009-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Extend the use of QualifiedNameType to the creation of class templateDouglas Gregor2009-03-191-5/+9
| | | | | | | | | | | specialization names. This way, we keep track of sugared types like std::vector<Real> I believe we are now using QualifiedNameTypes everywhere we can. Next step: QualifiedDeclRefExprs. llvm-svn: 67268
* Introduce a representation for types that we referred to via aDouglas Gregor2009-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qualified name, e.g., foo::x so that we retain the nested-name-specifier as written in the source code and can reproduce that qualified name when printing the types back (e.g., in diagnostics). This is PR3493, which won't be complete until finished the other tasks mentioned near the end of this commit. The parser's representation of nested-name-specifiers, CXXScopeSpec, is now a bit fatter, because it needs to contain the scopes that precede each '::' and keep track of whether the global scoping operator '::' was at the beginning. For example, we need to keep track of the leading '::', 'foo', and 'bar' in ::foo::bar::x The Action's CXXScopeTy * is no longer a DeclContext *. It's now the opaque version of the new NestedNameSpecifier, which contains a single component of a nested-name-specifier (either a DeclContext * or a Type *, bitmangled). The new sugar type QualifiedNameType composes a sequence of NestedNameSpecifiers with a representation of the type we're actually referring to. At present, we only build QualifiedNameType nodes within Sema::getTypeName. This will be extended to other type-constructing actions (e.g., ActOnClassTemplateId). Also on the way: QualifiedDeclRefExprs will also store a sequence of NestedNameSpecifiers, so that we can print out the property nested-name-specifier. I expect to also use this for handling dependent names like Fibonacci<I - 1>::value. llvm-svn: 67265
* The scope representation can now be either a DeclContext pointer or aDouglas Gregor2009-03-181-1/+1
| | | | | | | | | | Type pointer. This allows our nested-name-specifiers to retain more information about the actual spelling (e.g., which typedef did the user name, or what exact template arguments were used in the template-id?). It will also allow us to have dependent nested-name-specifiers that don't map to any DeclContext. llvm-svn: 67140
* Check for overflow and signedness problems with templateDouglas Gregor2009-03-141-10/+31
| | | | | | arguments. Eliminates a FIXME. llvm-svn: 66993
OpenPOWER on IntegriCloud