aboutsummaryrefslogtreecommitdiff
path: root/lib/Sema/SemaTemplate.cpp
AgeCommit message (Collapse)Author
2009-05-11Encapsulate template arguments lists in a new class,Douglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71517 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-11Implement the notions of the "current instantiation" and "unknownDouglas Gregor
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 }; git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71471 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-10With the introduction of nullptr, a template argument that refers to a ↵Douglas Gregor
declaration can now be NULL. Use cast_or_null appropriately git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71412 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-10Implement the semantics of the injected-class-name within a classDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71408 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-10Implement C++0x nullptr.Sebastian Redl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71405 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-07Compute the canonical template name when building a templateDouglas Gregor
specialization type for a dependent template name. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71153 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-07Start canonicalizing template names. This is not yet complete, but itDouglas Gregor
improves type identity with dependent types. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71152 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-03One can use "class" and "struct" interchangeably to refer to a classDouglas Gregor
in C++. Fixes <rdar://problem/6815995>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70784 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-01Replace more release+static_cast with takeAs.Anders Carlsson
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70567 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-09Propagate the ASTContext to various AST traversal and lookup functions.Douglas Gregor
No functionality change (really). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68726 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-01Add some more code modification hintsDouglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68261 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-01Make parsing a semantic analysis a little more robust following SemaDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68251 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-01Parsing, semantic analysis, and template instantiation for typenameDouglas Gregor
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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68166 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-31Parsing and AST representation for dependent template names that occurDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68081 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-30Improve the representation of template names in the AST. ThisDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68074 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-28Introduce a new OpaquePtr<N> struct type, which is a simple POD wrapper for aChris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67952 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-27Initial implementation of parsing, semantic analysis, and templateDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67875 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-26Set the access specifier for templates inside classes.Anders Carlsson
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67726 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-26Handle parsing of templates in member declarations. Pass the AccessSpecifier ↵Anders Carlsson
all the way down to ActOnClassTemplate. Doug, Sebastian: Plz review! :) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67723 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-26The injected-class-name of class templates and class templateDouglas Gregor
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 }; git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67720 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-25In Parser::ParseClassSpecifier, don't conflate a NULL declaration withDouglas Gregor
failure to perform a declaration. Instead, explicitly note semantic failures that occur during template parsing with a DeclResult. Fixes PR3872. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67659 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-24Type::isObjectType now implements the (more sensible) C++ definitionDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67648 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-24Fix a few isObjectTypes that really need to be isIncompleteOrObjectDouglas Gregor
types; add another use of RequireCompleteType. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67644 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-19Introduce a new expression type, UnresolvedDeclRefExpr, that describesDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67308 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-19Extend the use of QualifiedNameType to the creation of class templateDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67268 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-19Introduce a representation for types that we referred to via aDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67265 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-18The scope representation can now be either a DeclContext pointer or aDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67140 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-14Check for overflow and signedness problems with templateDouglas Gregor
arguments. Eliminates a FIXME. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66993 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-14Make sure that the canonical representation of integral template arguments ↵Douglas Gregor
uses the bitwidth and signedness of the template parameter git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66990 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-13Implement template instantiation for several more kinds of expressions:Douglas Gregor
- C++ function casts, e.g., T(foo) - sizeof(), alignof() More importantly, this allows us to verify that we're performing overload resolution during template instantiation, with argument-dependent lookup and the "cached" results of name lookup from the template definition. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66947 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-12Store the type of the integral value within a TemplateArgument, so that we ↵Douglas Gregor
can more efficiently reconstruct an IntegerLiteral from it during template instantiation git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66833 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-10Extend the notion of active template instantiations to include theDouglas Gregor
context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66572 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-10Add pretty-printing for class template specializations, e.g.,Douglas Gregor
'struct A<double, int>' In the "template instantiation depth exceeded" message, print "-ftemplate-depth-N" rather than "-ftemplate-depth=N". An unnamed tag type that is declared with a typedef, e.g., typedef struct { int x, y; } Point; can be used as a template argument. Allow this, and check that we get sensible pretty-printing for such things. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66560 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-09Implement template instantiation for ClassTemplateSpecializationTypes,Douglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66509 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-09Mark a non-type template parameter invalid if there was a problem with its typeDouglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66422 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-03Implement the basics of implicit instantiation of class templates, inDouglas Gregor
response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65924 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-28Implement template instantiation for pointer, reference, and (some)Douglas Gregor
array types. Semantic checking for the construction of these types has been factored out of GetTypeForDeclarator and into separate subroutines (BuildPointerType, BuildReferenceType, BuildArrayType). We'll be doing the same thing for all other types (and declarations and expressions). As part of this, moved the type-instantiation functions into a class in an anonymous namespace. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65663 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27Implement the basic approach for instantiating types, with a lot of FIXME'dDouglas Gregor
stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65649 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27Clean up and document code modification hints.Douglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65641 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-26Make the type associated with a ClassTemplateSpecializationDecl be aDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65577 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-26Introduce code modification hints into the diagnostics system. When weDouglas Gregor
know how to recover from an error, we can attach a hint to the diagnostic that states how to modify the code, which can be one of: - Insert some new code (a text string) at a particular source location - Remove the code within a given range - Replace the code within a given range with some new code (a text string) Right now, we use these hints to annotate diagnostic information. For example, if one uses the '>>' in a template argument in C++98, as in this code: template<int I> class B { }; B<1000 >> 2> *b1; we'll warn that the behavior will change in C++0x. The fix is to insert parenthese, so we use code insertion annotations to illustrate where the parentheses go: test.cpp:10:10: warning: use of right-shift operator ('>>') in template argument will require parentheses in C++0x B<1000 >> 2> *b1; ^ ( ) Use of these annotations is partially implemented for HTML diagnostics, but it's not (yet) producing valid HTML, which may be related to PR2386, so it has been #if 0'd out. In this future, we could consider hooking this mechanism up to the rewriter to actually try to fix these problems during compilation (or, after a compilation whose only errors have fixes). For now, however, I suggest that we use these code modification hints whenever we can, so that we get better diagnostics now and will have better coverage when we find better ways to use this information. This also fixes PR3410 by placing the complaint about missing tokens just after the previous token (rather than at the location of the next token). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-25Improve location information on "reused" class template specializationDouglas Gregor
decls. Test and document the semantic location of class template specialization definitions that occur within a scope enclosing the scope of the class template. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65478 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-25Perform additional semantic checking of class templateDouglas Gregor
specializations. In particular: - Make sure class template specializations have a "template<>" header, and complain if they don't. - Make sure class template specializations are declared/defined within a valid context. (e.g., you can't declare a specialization std::vector<MyType> in the global namespace). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65476 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-25Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65467 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-20silence some warnings in no asserts mode.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65169 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-18Downgrade complaints about calling unavailable functions to a warningDouglas Gregor
(as GCC does), except when we've performed overload resolution and found an unavailable function: in this case, we actually error. Merge the checking of unavailable functions with the checking for deprecated functions. This unifies a bit of code, and makes sure that we're checking for unavailable functions in the right places. Also, this check can cause an error. We may, eventually, want an option to make "unavailable" warnings into errors. Implement much of the logic needed for C++0x deleted functions, which are effectively the same as "unavailable" functions (but always cause an error when referenced). However, we don't have the syntax to specify deleted functions yet :) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64955 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-17Implement basic parsing and semantic analysis for explicitDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64848 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-17Added ClassTemplateSpecializationDecl, which is a subclass ofDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64716 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-11Fix comment.Mike Stump
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64337 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-11Appease the language lawyersDouglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64321 91177308-0d34-0410-b5e6-96231b3b80d8