summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/TemplateBase.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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