summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/TemplateName.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Change operator<< for raw_ostream and NamedDecl to take a reference instead ↵Benjamin Kramer2011-10-141-2/+2
| | | | | | | | of a pointer. Passing a pointer was a bad idea as it collides with the overload for void*. llvm-svn: 141971
* remove unneeded llvm:: namespace qualifiers on some core types now that ↵Chris Lattner2011-07-231-1/+1
| | | | | | | | LLVM.h imports them into the clang namespace. llvm-svn: 135852
* Introduce the notion of instantiation dependence into Clang's AST. ADouglas Gregor2011-07-011-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | type/expression/template argument/etc. is instantiation-dependent if it somehow involves a template parameter, even if it doesn't meet the requirements for the more common kinds of dependence (dependent type, type-dependent expression, value-dependent expression). When we see an instantiation-dependent type, we know we always need to perform substitution into that instantiation-dependent type. This keeps us from short-circuiting evaluation in places where we shouldn't, and lets us properly implement C++0x [temp.type]p2. In theory, this would also allow us to properly mangle instantiation-dependent-but-not-dependent decltype types per the Itanium C++ ABI, but we aren't quite there because we still mangle based on the canonical type in cases like, e.g., template<unsigned> struct A { }; template<typename T> void f(A<sizeof(sizeof(decltype(T() + T())))>) { } template void f<int>(A<sizeof(sizeof(int))>); and therefore get the wrong answer. llvm-svn: 134225
* Preserve that a TemplateName was arrived at by substitutingJohn McCall2011-06-301-4/+27
| | | | | | | | | | | for a template template parameter. Uses to follow. I've also made the uniquing of SubstTemplateTemplateParmPacks use a ContextualFoldingSet as a minor space efficiency. llvm-svn: 134137
* Teach Sema::ActOnCXXNestedNameSpecifier and Sema::CheckTemplateIdTypeDouglas Gregor2011-03-041-0/+4
| | | | | | | | to cope with non-type templates by providing appropriate errors. Previously, we would either assert, crash, or silently build a dependent type when we shouldn't. Fixes PR9226. llvm-svn: 127037
* Introduce a new kind of TemplateName that captures a substitutedDouglas Gregor2011-01-151-6/+27
| | | | | | | | | | | | | | | template template parameter pack that cannot be fully expanded because its enclosing pack expansion could not be expanded. This form of TemplateName plays the same role as SubstTemplateTypeParmPackType and SubstNonTypeTemplateParmPackExpr do for template type parameter packs and non-type template parameter packs, respectively. We should now handle these multi-level pack expansion substitutions anywhere. The largest remaining gap in our variadic-templates support is that we cannot cope with non-type template parameter packs whose type is a pack expansion. llvm-svn: 123521
* Variadic templates: extend Type, NestedNameSpecifier, TemplateName,Douglas Gregor2010-12-131-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | and TemplateArgument with an operation that determines whether there are any unexpanded parameter packs within that construct. Use this information to diagnose the appearance of the names of parameter packs that have not been expanded (C++ [temp.variadic]p5). Since this property is checked often (every declaration, ever expression statement, etc.), we extend Type and Expr with a bit storing the result of this computation, rather than walking the AST each time to determine whether any unexpanded parameter packs occur. This commit is deficient in several ways, which will be remedied with future commits: - Expr has a bit to store the presence of an unexpanded parameter pack, but it is never set. - The error messages don't point out where the unexpanded parameter packs were named in the type/expression, but they should. - We don't check for unexpanded parameter packs in all of the places where we should. - Testing is sparse, pending the resolution of the above three issues. llvm-svn: 121724
* Fix C++ PCH issues.Argyrios Kyrtzidis2010-09-081-2/+8
| | | | | | | | | | | PCH got a severe beating by the boost-using test case reported here: http://llvm.org/PR8099 Fix issues like: -When PCH reading, make sure Decl's getASTContext() doesn't get called since a Decl in the parent hierarchy may be initializing. -In ASTDeclReader::VisitFunctionDecl VisitRedeclarable should be called before using FunctionDecl's isCanonicalDecl() -In ASTDeclReader::VisitRedeclarableTemplateDecl CommonOrPrev must be initialized before anything else. llvm-svn: 113391
* Initial support for writing templates to PCH.Argyrios Kyrtzidis2010-06-191-0/+11
| | | | llvm-svn: 106391
* Add raw_ostream operators to NamedDecl for convenience. Switch over all ↵Benjamin Kramer2010-04-171-2/+2
| | | | | | | | users of getNameAsString on a stream. The next step is to print the name directly into the stream, avoiding a temporary std::string copy. llvm-svn: 101632
* When a template (without arguments) is passed as a template typeJeffrey Yasskin2010-04-081-0/+14
| | | | | | | parameter, explicitly ask the user to give it arguments. We used to complain that it wasn't a type and expect the user to figure it out. llvm-svn: 100729
* Push overloaded function templates through the parser using a totally differentJohn McCall2009-12-021-26/+2
| | | | | | | leaked data structure than before. This kills off the last remaining explicit uses of OverloadedFunctionDecl in Sema. llvm-svn: 90306
* Implement support for parsing dependent template-ids that refer toDouglas Gregor2009-11-041-3/+6
| | | | | | | | overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-11/+11
| | | | llvm-svn: 81346
* Initial stab at implement dependent member references to memberDouglas Gregor2009-09-091-1/+1
| | | | | | | | | | | | | templates, e.g., x.template get<T> We can now parse these, represent them within an UnresolvedMemberExpr expression, then instantiate that expression node in simple cases. This allows us to stumble through parsing LLVM's Casting.h. llvm-svn: 81300
* [llvm up]Douglas Gregor2009-07-291-5/+31
| | | | | | | | | A template name can refer to a set of overloaded function templates. Model this in TemplateName, which can now refer to an OverloadedFunctionDecl that contains function templates. This removes an unspeakable hack in Sema::isTemplateName. llvm-svn: 77488
* Key decisions about 'bool' vs '_Bool' to be based on a new flag in langoptions.Chris Lattner2009-06-301-3/+5
| | | | | | | | | | | | This is simple enough, but then I thought it would be nice to make PrintingPolicy get a LangOptions so that various things can key off "bool" and "C++" independently. This spiraled out of control. There are many fixme's, but I think things are slightly better than they were before. One thing that can be improved: CFG should probably have an ASTContext pointer in it, which would simplify its clients. llvm-svn: 74493
* Create a new PrintingPolicy class, which we pass down through the ASTDouglas Gregor2009-05-291-4/+9
| | | | | | | | | printing logic to help customize the output. For now, we use this rather than a special flag to suppress the "struct" when printing "struct X" and to print the Boolean type as "bool" in C++ but "_Bool" in C. llvm-svn: 72590
* add TemplateName.cpp/h to the xcode project, minor tidying.Chris Lattner2009-04-021-1/+1
| | | | llvm-svn: 68301
* Parsing, semantic analysis, and template instantiation for typenameDouglas Gregor2009-04-011-3/+5
| | | | | | | | | | | | | 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-11/+5
| | | | llvm-svn: 68140
* Implement template instantiation for template names, including bothDouglas Gregor2009-03-311-0/+10
| | | | | | | | | | | 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
* Improve the representation of template names in the AST. ThisDouglas Gregor2009-03-301-0/+54
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
OpenPOWER on IntegriCloud