summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Refactor the way we handle operator overloading and templateDouglas Gregor2009-03-131-8/+55
| | | | | | | | | | | | | | | | | | | | | | | | | instantiation for binary operators. This change moves most of the operator-overloading code from the parser action ActOnBinOp to a new, parser-independent semantic checking routine CreateOverloadedBinOp. Of particular importance is the fact that CreateOverloadedBinOp does *not* perform any name lookup based on the current parsing context (it doesn't take a Scope*), since it has to be usable during template instantiation, when there is no scope information. Rather, it takes a pre-computed set of functions that are visible from the context or via argument-dependent lookup, and adds to that set any member operators and built-in operator candidates. The set of functions is computed in the parser action ActOnBinOp based on the current context (both operator name lookup and argument-dependent lookup). Within a template, the set computed by ActOnBinOp is saved within the type-dependent AST node and is augmented with the results of argument-dependent name lookup at instantiation time (see TemplateExprInstantiator::VisitCXXOperatorCallExpr). Sadly, we can't fully test this yet. I'll follow up with template instantiation for sizeof so that the real fun can begin. llvm-svn: 66923
* Improve the representation of operator expressions like "x + y" withinDouglas Gregor2009-03-131-0/+27
| | | | | | | | | | | | | | | | C++ templates. In particular, keep track of the overloaded operators that are visible from the template definition, so that they can be merged with those operators visible via argument-dependent lookup at instantiation time. Refactored the lookup routines for argument-dependent lookup and for operator name lookup, so they can be called without immediately adding the results to an overload set. Instantiation of these expressions is completely wrong. I'll work on that next. llvm-svn: 66851
* Implement template instantiation for builtin binary operatorsDouglas Gregor2009-03-121-1/+28
| | | | llvm-svn: 66835
* Store the type of the integral value within a TemplateArgument, so that we ↵Douglas Gregor2009-03-121-12/+4
| | | | | | can more efficiently reconstruct an IntegerLiteral from it during template instantiation llvm-svn: 66833
* Use StmtVisitor to handle the decoding of expressions forDouglas Gregor2009-03-121-36/+75
| | | | | | | instantiation. This is roughly the structure we want to expression instantiation. llvm-svn: 66816
* Straw man for instantiation of expressions. Use it to instantiate theDouglas Gregor2009-03-121-1/+66
| | | | | | | | | width of bitfields. I'll be burning this down and replacing it with a properly-dispatched implementation like the one used for types. llvm-svn: 66796
* Make sure that we set the access specifier for an instantiated FieldDecl, ↵Douglas Gregor2009-03-111-0/+1
| | | | | | and that the aggregate and POD flags for an instantiated class template are updated based on instantiation of a FieldDecl llvm-svn: 66701
* Implement basic template instantiation for fields. Reshuffle checkingDouglas Gregor2009-03-111-7/+42
| | | | | | | for FieldDecls so that the parser and the template instantiation make use of the same semantic checking module. llvm-svn: 66685
* Add basic, hackish support for instantiation of typedefs in a classDouglas Gregor2009-03-111-2/+33
| | | | | | | | | template. More importantly, start to sort out the issues regarding complete types and nested-name-specifiers, especially the question of: when do we instantiate a class template specialization that occurs to the left of a '::' in a nested-name-specifier? llvm-svn: 66662
* Extend the notion of active template instantiations to include theDouglas Gregor2009-03-101-16/+75
| | | | | | | | | | | | 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. llvm-svn: 66572
* If we run into multiple errors within the same template instantiation,Douglas Gregor2009-03-101-3/+7
| | | | | | | | | only print the template instantiation backtrace for the first error. Also, if a base class has failed to type-check during instantiation, just drop that base class and continue on to check other base classes. llvm-svn: 66563
* Add a notion of "post-diagnostic hooks", which are callbacks attachedDouglas Gregor2009-03-101-0/+24
| | | | | | | | | | | | | | | | | to a diagnostic that will be invoked after the diagnostic (if it is not suppressed). The hooks are allowed to produce additional diagnostics (typically notes) that provide more information. We should be able to use this to help diagnostic clients link notes back to the diagnostic they clarify. Comments welcome; I'll write up documentation and convert other clients (e.g., overload resolution failures) if there are no screams of protest. As the first client of post-diagnostic hooks, we now produce a template instantiation backtrace when a failure occurs during template instantiation. There's still more work to do to make this output pretty, if that's even possible. llvm-svn: 66557
* Limit the template instantiation depth to some user-configurable valueDouglas Gregor2009-03-101-0/+34
| | | | | | | | | | | | | | | | (default: 99). Beyond this limit, produce an error and consider the current template instantiation a failure. The stack we're building to track the instantiations will, eventually, be used to produce instantiation backtraces from diagnostics within template instantiation. However, we're not quite there yet. This adds a new Clang driver option -ftemplate-depth=NNN, which should eventually be generated from the GCC command-line operation -ftemplate-depth-NNN (note the '-' rather than the '='!). I did not make the driver changes to do this mapping. llvm-svn: 66513
* Implement template instantiation for ClassTemplateSpecializationTypes,Douglas Gregor2009-03-091-3/+38
| | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud