summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/TemplateBase.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Clean up some gross code in the printer here. No more string streamChandler Carruth2011-02-251-13/+5
| | | | | | | | | | silliness, and actually use the existing facilities of raw_ostream to do escaping. This will also hopefully fix an assert when building with signed char (MSVC I think). llvm-svn: 126505
* Improve bool and char integral template argument printing inChandler Carruth2011-02-191-1/+34
| | | | | | | | | diagnostics, resolving PR9227. Patch originally by Mihai Rusu and Stephen Hines with some minimal style tweaks from me. llvm-svn: 125999
* Teach template template argument pack expansions to keep track of theDouglas Gregor2011-01-141-2/+10
| | | | | | | number of expansions, when we know it, and propagate that information through Sema. llvm-svn: 123493
* Teach PackExpansionExpr to keep track of the number of pack expansionsDouglas Gregor2011-01-141-1/+1
| | | | | | it will expand to, if known. Propagate this information throughout Sema. llvm-svn: 123470
* Keep track of the number of expansions to be produced from a type packDouglas Gregor2011-01-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | expansion, when it is known due to the substitution of an out parameter pack. This allows us to properly handle substitution into pack expansions that involve multiple parameter packs at different template parameter levels, even when this substitution happens one level at a time (as with partial specializations of member class templates and the signatures of member function templates). Note that the diagnostic we provide when there is an arity mismatch between an outer parameter pack and an inner parameter pack in this case isn't as clear as the normal diagnostic for an arity mismatch. However, this doesn't matter because these cases are very, very rare and (even then) only typically occur in a SFINAE context. The other kinds of pack expansions (expression, template, etc.) still need to support optional tracking of the number of expansions, and we need the moral equivalent of SubstTemplateTypeParmPackType for substituted argument packs of template template and non-type template parameters. llvm-svn: 123448
* PR3558: mark "logically const" accessor methods in ASTContext as const,Jay Foad2011-01-121-1/+1
| | | | | | | and mark the fields they use as mutable. This allows us to remove a few const_casts. llvm-svn: 123314
* Add TemplateArgument::CreatePackCopy() to create a new parameter packDouglas Gregor2011-01-111-0/+12
| | | | | | | in ASTContext-allocated memory, copying the provided template arguments. Use this new routine where we can. No functionality change. llvm-svn: 123289
* When default-initializing a TemplateArgumentLocInfo, make sure that weDouglas Gregor2011-01-061-1/+9
| | | | | | | | | | initialize *all* of the bits to zero. Also, when the pattern of a template argument pack expansion, make sure to set the ellipsis location along all paths. This should clear up the valgrind failure that popped up in Clang. llvm-svn: 122931
* Replace the representation of template template argument packDouglas Gregor2011-01-051-38/+49
| | | | | | | | | | | | | expansions with something that is easier to use correctly: a new template argment kind, rather than a bit on an existing kind. Update all of the switch statements that deal with template arguments, fixing a few latent bugs in the process. I"m happy with this representation, now. And, oh look! Template instantiation and deduction work for template template argument pack expansions. llvm-svn: 122896
* Add semantic analysis for the creation of and an AST representationDouglas Gregor2011-01-051-31/+41
| | | | | | | | | | | | | | | | | | | | | for template template argument pack expansions. This allows fun such as: template<template<class> class ...> struct apply_impl { /*...*/ }; template<template<class> class ...Metafunctions> struct apply { typedef typename apply_impl<Metafunctions...>::type type; }; However, neither template argument deduction nor template instantiation is implemented for template template argument packs, so this functionality isn't useful yet. I'll probably replace the encoding of template template argument pack expansions in TemplateArgument so that it's harder to accidentally forget about the expansion. However, this is a step in the right general direction. llvm-svn: 122890
* Implement support for pack expansions whose pattern is a non-typeDouglas Gregor2011-01-031-6/+12
| | | | | | | | | | | | | | | | | template argument (described by an expression, of course). For example: template<int...> struct int_tuple { }; template<int ...Values> struct square { typedef int_tuple<(Values*Values)...> type; }; It also lays the foundation for pack expansions in an initializer-list. llvm-svn: 122751
* Implement template argument deduction for pack expansions whoseDouglas Gregor2010-12-221-0/+22
| | | | | | | | | | | pattern is a template argument, which involves repeatedly deducing template arguments using the pattern of the pack expansion, then bundling the resulting deductions into an argument pack. We can now handle a variety of simple list-handling metaprograms using variadic templates. See, e.g., the new "count" metaprogram. llvm-svn: 122439
* Add a hack to work around the lack of proper type-source info in a pack ↵Douglas Gregor2010-12-211-1/+8
| | | | | | expansion TypeLoc llvm-svn: 122367
* Implement basic support for template instantiation of pack expansionsDouglas Gregor2010-12-201-0/+64
| | | | | | | | | | | | | | | | | whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
* Clean up the handling of template argument packs, especially in theDouglas Gregor2010-12-201-4/+75
| | | | | | | area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
* Variadic templates: extend the Expr class with a bit that specifiesDouglas Gregor2010-12-151-0/+36
| | | | | | | | | | | | | | | | | | whether the expression contains an unexpanded parameter pack, in the same vein as the changes to the Type hierarchy. Compute this bit within all of the Expr subclasses. This change required a bunch of reshuffling of dependency calculations, mainly to consolidate them inside the constructors and to fuse multiple loops that iterate over arguments to determine type dependence, value dependence, and (now) containment of unexpanded parameter packs. Again, testing is painfully sparse, because all of the diagnostics will change and it is more important to test the to-be-written visitor that collects unexpanded parameter packs. llvm-svn: 121831
* Variadic templates: extend Type, NestedNameSpecifier, TemplateName,Douglas Gregor2010-12-131-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove broken support for variadic templates, along with the variousDouglas Gregor2010-11-071-19/+0
| | | | | | | | | | | | | abstractions (e.g., TemplateArgumentListBuilder) that were designed to support variadic templates. Only a few remnants of variadic templates remain, in the parser (parsing template type parameter packs), AST (template type parameter pack bits and TemplateArgument::Pack), and Sema; these are expected to be used in a future implementation of variadic templates. But don't get too excited about that happening now. llvm-svn: 118385
* fix a crash in RecursiveASTVisitor's child classes (PR8403); reviewed by ↵Zhanyong Wan2010-09-031-5/+8
| | | | | | chandlerc. llvm-svn: 113038
* operator<< on a DiagnosticBuilder should *always* output exactly one thing.John McCall2010-08-051-1/+3
| | | | | | | Null template arguments are bad, but they're better than crashing with an argument mismatch. llvm-svn: 110312
* Split DependentNameType into two types. DependentNameType represents theJohn McCall2010-06-111-0/+27
| | | | | | | | | | | | | | case of an elaborated-type-specifier like 'typename A<T>::foo', and DependentTemplateSpecializationType represents the case of an elaborated-type-specifier like 'typename A<T>::template B<T>'. The TypeLoc representation of a DependentTST conveniently exactly matches that of an ElaboratedType wrapping a TST. Kill off the explicit rebuild methods for RebuildInCurrentInstantiation; the standard implementations work fine because the nested name specifier is computable in the newly-entered context. llvm-svn: 105801
* Renamed misleading getSourceRange -> getLocalSourceRange and ↵Abramo Bagnara2010-05-201-1/+1
| | | | | | getFullSourceRange -> getSourceRange for TypeLoc. llvm-svn: 104220
* When printing a non-viable overload candidate that failed due toDouglas Gregor2010-05-081-0/+40
| | | | | | | | | | | | conflicting deduced template argument values, give a more specific reason along with those values, e.g., test/SemaTemplate/overload-candidates.cpp:4:10: note: candidate template ignored: deduced conflicting types for parameter 'T' ('int' vs. 'long') const T& min(const T&, const T&); ^ llvm-svn: 103339
* DeclaratorInfo -> TypeSourceInfo. Makes an effort to rename associated ↵John McCall2009-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | variables, but the results are imperfect. For posterity, I did: cat <<EOF > $cmdfile s/DeclaratorInfo/TypeSourceInfo/g s/DInfo/TInfo/g s/TypeTypeSourceInfo/TypeSourceInfo/g s/SourceTypeSourceInfo/TypeSourceInfo/g EOF find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \; find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \; find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \; llvm-svn: 90743
* Canonical template arguments that are template template parameters byDouglas Gregor2009-11-231-2/+12
| | | | | | | their template parameter depth and position, so that we can match redeclarations appropriately. Fixes PR5527 and PR5528. llvm-svn: 89654
* Fix speculative parsing of dependent template names inDouglas Gregor2009-11-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | nested-name-specifiers so that they don't gobble the template name (or operator-function-id) unless there is also a template-argument-list. For example, given T::template apply we would previously consume both "template" and "apply" as part of parsing the nested-name-specifier, then error when we see that there is no "<" starting a template argument list. Now, we parse such constructs tentatively, and back off if the "<" is not present. This allows us to parse dependent template names as one would use them for, e.g., template template parameters: template<typename T, template<class> class X = T::template apply> struct MetaSomething; Also, test default arguments for template template parameters. llvm-svn: 86841
* Introduce a new representation for template templateDouglas Gregor2009-11-111-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | parameters. Rather than storing them as either declarations (for the non-dependent case) or expressions (for the dependent case), we now (always) store them as TemplateNames. The primary change here is to add a new kind of TemplateArgument, which stores a TemplateName. However, making that change ripples to every switch on a TemplateArgument's kind, also affecting TemplateArgumentLocInfo/TemplateArgumentLoc, default template arguments for template template parameters, type-checking of template template arguments, etc. This change is light on testing. It should fix several pre-existing problems with template template parameters, such as: - the inability to use dependent template names as template template arguments - template template parameter default arguments cannot be instantiation However, there are enough pieces missing that more implementation is required before we can adequately test template template parameters. llvm-svn: 86777
* A few TemplateArgumentLoc clean-ups. Try to remember the Expr for a ↵John McCall2009-10-291-7/+7
| | | | | | | | declaration. Provide an API for getting the SourceRange of a TAL and use it judiciously. llvm-svn: 85520
* Track source information for template arguments and template specializationJohn McCall2009-10-291-5/+23
| | | | | | | types. Preserve it through template instantiation. Preserve it through PCH, although TSTs themselves aren't serializable, so that's pretty much meaningless. llvm-svn: 85500
* Extract TemplateArgument into a new header just for common templateJohn McCall2009-10-291-0/+79
classes. Move its implementation into a new module. This will seem marginally more justified in a bit. llvm-svn: 85499
OpenPOWER on IntegriCloud