summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Reduce the amount of stack space we use in SmallVectors duringDouglas Gregor2009-05-291-4/+4
| | | | | | | template instantiation. This helps reduce our stack footprint when performing deep template instantiations. llvm-svn: 72582
* Simplify, and improve the performance of, template instantiation forDouglas Gregor2009-05-271-6/+4
| | | | | | | | | | | declaration references. The key realization is that dependent Decls, which actually require instantiation, can only refer to the current instantiation or members thereof. And, since the current context during instantiation contains all of those members of the current instantiation, we can simply find the real instantiate that matches up with the "current instantiation" template. llvm-svn: 72486
* Initial stab at a generalized operation for determining theDouglas Gregor2009-05-271-9/+21
| | | | | | | | | | | | instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
* Template instantiation for "typeof" for both types and expressions.Douglas Gregor2009-05-261-6/+11
| | | | llvm-svn: 72440
* Make sure that CodeGen sees template instantiations.Douglas Gregor2009-05-261-0/+4
| | | | llvm-svn: 72433
* Use v.data() instead of &v[0] when SmallVector v might be empty.Jay Foad2009-05-211-2/+2
| | | | llvm-svn: 72210
* When instantiating the definition of a member function of a classDouglas Gregor2009-05-181-14/+28
| | | | | | | | | | | | | | 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-14/+10
| | | | llvm-svn: 71936
* Introduce basic support for instantiating the definitions of memberDouglas Gregor2009-05-141-0/+20
| | | | | | | functions of class templates. Only compound statements and expression statements are currently implemented. llvm-svn: 71814
* Implement explicit instantiations of member classes of class templates, e.g.,Douglas Gregor2009-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+51
| | | | | | | | 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-4/+20
| | | | | | | | | | | | | | | | 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-4/+6
| | | | | | | | 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-45/+22
| | | | | | | | 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
* Replace more release+static_cast with takeAs.Anders Carlsson2009-05-011-1/+1
| | | | llvm-svn: 70567
* Replace a bunch of static_cast + release with takeAs.Anders Carlsson2009-05-011-1/+1
| | | | llvm-svn: 70566
* ObjCQualifiedClass is dead, remove it.Chris Lattner2009-04-221-8/+0
| | | | llvm-svn: 69783
* Propagate the ASTContext to various AST traversal and lookup functions.Douglas Gregor2009-04-091-2/+3
| | | | | | No functionality change (really). llvm-svn: 68726
* Parsing, semantic analysis, and template instantiation for typenameDouglas Gregor2009-04-011-10/+24
| | | | | | | | | | | | | 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
* Some cleanup and renaming. No functionality changeDouglas Gregor2009-03-311-3/+2
| | | | llvm-svn: 68140
* Implement template instantiation for template names, including bothDouglas Gregor2009-03-311-4/+76
| | | | | | | | | | | 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
* Parsing and AST representation for dependent template names that occurDouglas Gregor2009-03-311-1/+1
| | | | | | | | | | | 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-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-5/+4
| | | | | | | | | | | | | | | | | | | | 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-9/+32
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Revamp our representation of C++ nested-name-specifiers. We now have aDouglas Gregor2009-03-261-27/+46
| | | | | | | | | | | uniqued representation that should both save some memory and make it far easier to properly build canonical types for types involving dependent nested-name-specifiers, e.g., "typename T::Nested::type". This approach will greatly simplify the representation of CXXScopeSpec. That'll be next. llvm-svn: 67799
* Fix notes regarding the instantiation of member classes (and test 'em).Douglas Gregor2009-03-251-2/+1
| | | | llvm-svn: 67708
* Instantiation for member classes of class templates. Note that onlyDouglas Gregor2009-03-251-66/+103
| | | | | | | | | | | the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. llvm-svn: 67707
* Move template instantiation for expressions into a separate fileDouglas Gregor2009-03-251-401/+0
| | | | llvm-svn: 67660
* Eliminate post-diagnostic hooks. Instead, implement a Sema-specificDouglas Gregor2009-03-201-8/+0
| | | | | | | variant of DiagnosticBuilder that emits the template instantiation backtrace when needed. llvm-svn: 67413
* Introduce a new expression type, UnresolvedDeclRefExpr, that describesDouglas Gregor2009-03-191-2/+55
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Introduce a representation for types that we referred to via aDouglas Gregor2009-03-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use the instantiated expressions to build the ConditionalOperator. This ↵Gabor Greif2009-03-181-8/+4
| | | | | | addresses the second part of review feedback. llvm-svn: 67259
* incorporate review comment (about the optimization when we have a ↵Gabor Greif2009-03-181-2/+18
| | | | | | non-typedependent expression) llvm-svn: 67226
* simplify logic, isInvalid check is redundantGabor Greif2009-03-181-8/+3
| | | | llvm-svn: 67216
* cleanup instantiation code, tighten testcaseGabor Greif2009-03-181-3/+0
| | | | llvm-svn: 67148
* instantiate ?: expressionsGabor Greif2009-03-181-1/+30
| | | | llvm-svn: 67145
* Refactor instantiation of declarations within a template into a muchDouglas Gregor2009-03-171-149/+12
| | | | | | | | | cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
* Implement instantiation of enums within class templates. This isn'tDouglas Gregor2009-03-171-2/+53
| | | | | | | | | | | | | | | quite as great as it sounds, because, while we can refer to the enumerator values outside the template, e.g., adder<long, 3, 4>::value we can't yet refer to them with dependent names, so no Fibonacci (yet). InstantiateClassTemplateSpecialization is getting messy; next commit will put it into a less-ugly state. llvm-svn: 67092
* Handle ImplicitCastExprs when instantiating templates.Anders Carlsson2009-03-171-1/+17
| | | | llvm-svn: 67063
* Fix a problem noticed by Anders, where we were creatingDouglas Gregor2009-03-161-1/+14
| | | | | | | | IntegerLiterals during instantiation when we should be creating either a boolean literal (CXXBoolLiteralExpr) or a character literal (CharacterLiteral). llvm-svn: 67061
* Almost complete implementation of rvalue references. One bug, and a few ↵Sebastian Redl2009-03-161-4/+14
| | | | | | unclear areas. Maybe Doug can shed some light on some of the fixmes. llvm-svn: 67059
* (Hopefully) instantiate dependent array types correctly.Anders Carlsson2009-03-151-3/+21
| | | | llvm-svn: 67032
* Handle static_asserts when instantiating structs.Anders Carlsson2009-03-151-0/+19
| | | | llvm-svn: 67031
* Add the ability to clone integer and string literals. Use it when ↵Anders Carlsson2009-03-151-5/+3
| | | | | | instantiating template expressions. llvm-svn: 67030
* Convert a bunch of actions to smart pointers, and also bring ↵Sebastian Redl2009-03-151-10/+12
| | | | | | PrintParserCallbacks a bit more in line with reality. llvm-svn: 67029
* Fix bitfield-instantiation ownership bug noticed by AndersDouglas Gregor2009-03-151-2/+1
| | | | llvm-svn: 67028
* Implement template instantiation for the prefix unary operators. AsDouglas Gregor2009-03-131-46/+100
| | | | | | | | always, refactored the existing logic to tease apart the parser action and the semantic analysis shared by the parser and template instantiation. llvm-svn: 66987
* Implement template instantiation for several more kinds of expressions:Douglas Gregor2009-03-131-6/+103
| | | | | | | | | | | | - 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. llvm-svn: 66947
* Remove an already-fixed FIXMEDouglas Gregor2009-03-131-3/+0
| | | | llvm-svn: 66924
OpenPOWER on IntegriCloud