maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/AST/TemplateBase.cpp

664 lines
19 KiB
C++
Raw Normal View History

Extract TemplateArgument into a new header just for common template classes. Move its implementation into a new module. This will seem marginally more justified in a bit. llvm-svn: 85499
2009-10-29 15:48:15 +08:00
//===--- TemplateBase.cpp - Common template AST class implementation ------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file implements common classes used throughout C++ template
// representations.
//
//===----------------------------------------------------------------------===//
#include "clang/AST/TemplateBase.h"
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
#include "clang/AST/ASTContext.h"
Extract TemplateArgument into a new header just for common template classes. Move its implementation into a new module. This will seem marginally more justified in a bit. llvm-svn: 85499
2009-10-29 15:48:15 +08:00
#include "clang/AST/DeclBase.h"
Canonical template arguments that are template template parameters by their template parameter depth and position, so that we can match redeclarations appropriately. Fixes PR5527 and PR5528. llvm-svn: 89654
2009-11-23 20:52:47 +08:00
#include "clang/AST/DeclTemplate.h"
Extract TemplateArgument into a new header just for common template classes. Move its implementation into a new module. This will seem marginally more justified in a bit. llvm-svn: 85499
2009-10-29 15:48:15 +08:00
#include "clang/AST/Expr.h"
Implement support for pack expansions whose pattern is a non-type 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
2011-01-04 01:17:50 +08:00
#include "clang/AST/ExprCXX.h"
Improve bool and char integral template argument printing in diagnostics, resolving PR9227. Patch originally by Mihai Rusu and Stephen Hines with some minimal style tweaks from me. llvm-svn: 125999
2011-02-19 08:21:00 +08:00
#include "clang/AST/Type.h"
Track source information for template arguments and template specialization 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
2009-10-29 16:12:44 +08:00
#include "clang/AST/TypeLoc.h"
When printing a non-viable overload candidate that failed due to 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
2010-05-09 01:41:32 +08:00
#include "clang/Basic/Diagnostic.h"
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
#include "llvm/ADT/FoldingSet.h"
Move a method from IdentifierTable.h out of line and remove the SmallString include. Fix all the transitive include users. llvm-svn: 149783
2012-02-04 21:45:25 +08:00
#include "llvm/ADT/SmallString.h"
Include pruning and general cleanup. llvm-svn: 169095
2012-12-02 01:12:56 +08:00
#include "llvm/Support/raw_ostream.h"
Add TemplateArgument::CreatePackCopy() to create a new parameter pack in ASTContext-allocated memory, copying the provided template arguments. Use this new routine where we can. No functionality change. llvm-svn: 123289
2011-01-12 07:09:57 +08:00
#include <algorithm>
Improve bool and char integral template argument printing in diagnostics, resolving PR9227. Patch originally by Mihai Rusu and Stephen Hines with some minimal style tweaks from me. llvm-svn: 125999
2011-02-19 08:21:00 +08:00
#include <cctype>
Extract TemplateArgument into a new header just for common template classes. Move its implementation into a new module. This will seem marginally more justified in a bit. llvm-svn: 85499
2009-10-29 15:48:15 +08:00
using namespace clang;
Improve bool and char integral template argument printing in diagnostics, resolving PR9227. Patch originally by Mihai Rusu and Stephen Hines with some minimal style tweaks from me. llvm-svn: 125999
2011-02-19 08:21:00 +08:00
/// \brief Print a template integral argument value.
///
/// \param TemplArg the TemplateArgument instance to print.
///
/// \param Out the raw_ostream instance to use for printing.
static void printIntegral(const TemplateArgument &TemplArg,
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
raw_ostream &Out) {
Improve bool and char integral template argument printing in diagnostics, resolving PR9227. Patch originally by Mihai Rusu and Stephen Hines with some minimal style tweaks from me. llvm-svn: 125999
2011-02-19 08:21:00 +08:00
const ::clang::Type *T = TemplArg.getIntegralType().getTypePtr();
Plug a long standing memory leak in TemplateArgument. The integral APSInt value is now stored in a decomposed form and the backing store for large values is allocated via the ASTContext. This way its not leaked as TemplateArguments are never destructed when they are allocated in the ASTContext. Since the integral data is immutable it is now shared between instances, making copying TemplateArguments a trivial operation. Currently getting the integral data out of a TemplateArgument requires creating a new APSInt object. This is cheap when the value is small but can be expensive if it's not. If this turns out to be an issue a more efficient accessor could be added. llvm-svn: 158150
2012-06-07 23:09:51 +08:00
const llvm::APSInt &Val = TemplArg.getAsIntegral();
Improve bool and char integral template argument printing in diagnostics, resolving PR9227. Patch originally by Mihai Rusu and Stephen Hines with some minimal style tweaks from me. llvm-svn: 125999
2011-02-19 08:21:00 +08:00
if (T->isBooleanType()) {
Plug a long standing memory leak in TemplateArgument. The integral APSInt value is now stored in a decomposed form and the backing store for large values is allocated via the ASTContext. This way its not leaked as TemplateArguments are never destructed when they are allocated in the ASTContext. Since the integral data is immutable it is now shared between instances, making copying TemplateArguments a trivial operation. Currently getting the integral data out of a TemplateArgument requires creating a new APSInt object. This is cheap when the value is small but can be expensive if it's not. If this turns out to be an issue a more efficient accessor could be added. llvm-svn: 158150
2012-06-07 23:09:51 +08:00
Out << (Val.getBoolValue() ? "true" : "false");
Improve bool and char integral template argument printing in diagnostics, resolving PR9227. Patch originally by Mihai Rusu and Stephen Hines with some minimal style tweaks from me. llvm-svn: 125999
2011-02-19 08:21:00 +08:00
} else if (T->isCharType()) {
Plug a long standing memory leak in TemplateArgument. The integral APSInt value is now stored in a decomposed form and the backing store for large values is allocated via the ASTContext. This way its not leaked as TemplateArguments are never destructed when they are allocated in the ASTContext. Since the integral data is immutable it is now shared between instances, making copying TemplateArguments a trivial operation. Currently getting the integral data out of a TemplateArgument requires creating a new APSInt object. This is cheap when the value is small but can be expensive if it's not. If this turns out to be an issue a more efficient accessor could be added. llvm-svn: 158150
2012-06-07 23:09:51 +08:00
const char Ch = Val.getZExtValue();
Clean up some gross code in the printer here. No more string stream 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
2011-02-26 04:09:13 +08:00
Out << ((Ch == '\'') ? "'\\" : "'");
Move a method from IdentifierTable.h out of line and remove the SmallString include. Fix all the transitive include users. llvm-svn: 149783
2012-02-04 21:45:25 +08:00
Out.write_escaped(StringRef(&Ch, 1), /*UseHexEscapes=*/ true);
Clean up some gross code in the printer here. No more string stream 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
2011-02-26 04:09:13 +08:00
Out << "'";
Improve bool and char integral template argument printing in diagnostics, resolving PR9227. Patch originally by Mihai Rusu and Stephen Hines with some minimal style tweaks from me. llvm-svn: 125999
2011-02-19 08:21:00 +08:00
} else {
Plug a long standing memory leak in TemplateArgument. The integral APSInt value is now stored in a decomposed form and the backing store for large values is allocated via the ASTContext. This way its not leaked as TemplateArguments are never destructed when they are allocated in the ASTContext. Since the integral data is immutable it is now shared between instances, making copying TemplateArguments a trivial operation. Currently getting the integral data out of a TemplateArgument requires creating a new APSInt object. This is cheap when the value is small but can be expensive if it's not. If this turns out to be an issue a more efficient accessor could be added. llvm-svn: 158150
2012-06-07 23:09:51 +08:00
Out << Val;
Improve bool and char integral template argument printing in diagnostics, resolving PR9227. Patch originally by Mihai Rusu and Stephen Hines with some minimal style tweaks from me. llvm-svn: 125999
2011-02-19 08:21:00 +08:00
}
}
Extract TemplateArgument into a new header just for common template classes. Move its implementation into a new module. This will seem marginally more justified in a bit. llvm-svn: 85499
2009-10-29 15:48:15 +08:00
//===----------------------------------------------------------------------===//
// TemplateArgument Implementation
//===----------------------------------------------------------------------===//
Plug a long standing memory leak in TemplateArgument. The integral APSInt value is now stored in a decomposed form and the backing store for large values is allocated via the ASTContext. This way its not leaked as TemplateArguments are never destructed when they are allocated in the ASTContext. Since the integral data is immutable it is now shared between instances, making copying TemplateArguments a trivial operation. Currently getting the integral data out of a TemplateArgument requires creating a new APSInt object. This is cheap when the value is small but can be expensive if it's not. If this turns out to be an issue a more efficient accessor could be added. llvm-svn: 158150
2012-06-07 23:09:51 +08:00
TemplateArgument::TemplateArgument(ASTContext &Ctx, const llvm::APSInt &Value,
QualType Type)
: Kind(Integral) {
// Copy the APSInt value into our decomposed form.
Integer.BitWidth = Value.getBitWidth();
Integer.IsUnsigned = Value.isUnsigned();
// If the value is large, we have to get additional memory from the ASTContext
Reuse APInt's getNumWords, which gets rounding right (my ad-hoc solution missed it). llvm-svn: 158151
2012-06-07 23:54:03 +08:00
unsigned NumWords = Value.getNumWords();
if (NumWords > 1) {
void *Mem = Ctx.Allocate(NumWords * sizeof(uint64_t));
std::memcpy(Mem, Value.getRawData(), NumWords * sizeof(uint64_t));
Plug a long standing memory leak in TemplateArgument. The integral APSInt value is now stored in a decomposed form and the backing store for large values is allocated via the ASTContext. This way its not leaked as TemplateArguments are never destructed when they are allocated in the ASTContext. Since the integral data is immutable it is now shared between instances, making copying TemplateArguments a trivial operation. Currently getting the integral data out of a TemplateArgument requires creating a new APSInt object. This is cheap when the value is small but can be expensive if it's not. If this turns out to be an issue a more efficient accessor could be added. llvm-svn: 158150
2012-06-07 23:09:51 +08:00
Integer.pVal = static_cast<uint64_t *>(Mem);
} else {
Integer.VAL = Value.getZExtValue();
}
Integer.Type = Type.getAsOpaquePtr();
}
Add TemplateArgument::CreatePackCopy() to create a new parameter pack in ASTContext-allocated memory, copying the provided template arguments. Use this new routine where we can. No functionality change. llvm-svn: 123289
2011-01-12 07:09:57 +08:00
TemplateArgument TemplateArgument::CreatePackCopy(ASTContext &Context,
const TemplateArgument *Args,
unsigned NumArgs) {
if (NumArgs == 0)
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
return getEmptyPack();
Add TemplateArgument::CreatePackCopy() to create a new parameter pack in ASTContext-allocated memory, copying the provided template arguments. Use this new routine where we can. No functionality change. llvm-svn: 123289
2011-01-12 07:09:57 +08:00
TemplateArgument *Storage = new (Context) TemplateArgument [NumArgs];
std::copy(Args, Args + NumArgs, Storage);
return TemplateArgument(Storage, NumArgs);
}
Variadic templates: extend the Expr class with a bit that specifies 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
2010-12-15 09:34:56 +08:00
bool TemplateArgument::isDependent() const {
switch (getKind()) {
case Null:
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Should not have a NULL template argument");
Variadic templates: extend the Expr class with a bit that specifies 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
2010-12-15 09:34:56 +08:00
case Type:
return getAsType()->isDependentType();
case Template:
return getAsTemplate().isDependent();
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case TemplateExpansion:
return true;
Variadic templates: extend the Expr class with a bit that specifies 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
2010-12-15 09:34:56 +08:00
case Declaration:
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
if (DeclContext *DC = dyn_cast<DeclContext>(getAsDecl()))
return DC->isDependentContext();
return getAsDecl()->getDeclContext()->isDependentContext();
case NullPtr:
Implement support for null non-type template arguments for non-type template parameters of pointer, pointer-to-member, or nullptr_t type in C++11. Fixes PR9700 / <rdar://problem/11193097>. llvm-svn: 154219
2012-04-07 06:40:38 +08:00
return false;
Variadic templates: extend the Expr class with a bit that specifies 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
2010-12-15 09:34:56 +08:00
case Integral:
// Never dependent
return false;
case Expression:
return (getAsExpr()->isTypeDependent() || getAsExpr()->isValueDependent());
case Pack:
for (pack_iterator P = pack_begin(), PEnd = pack_end(); P != PEnd; ++P) {
if (P->isDependent())
return true;
}
return false;
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148577
2012-01-21 05:50:17 +08:00
llvm_unreachable("Invalid TemplateArgument Kind!");
Variadic templates: extend the Expr class with a bit that specifies 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
2010-12-15 09:34:56 +08:00
}
Introduce the notion of instantiation dependence into Clang's AST. A 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
2011-07-01 09:22:09 +08:00
bool TemplateArgument::isInstantiationDependent() const {
switch (getKind()) {
case Null:
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Should not have a NULL template argument");
Introduce the notion of instantiation dependence into Clang's AST. A 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
2011-07-01 09:22:09 +08:00
case Type:
return getAsType()->isInstantiationDependentType();
case Template:
return getAsTemplate().isInstantiationDependent();
case TemplateExpansion:
return true;
case Declaration:
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
if (DeclContext *DC = dyn_cast<DeclContext>(getAsDecl()))
return DC->isDependentContext();
return getAsDecl()->getDeclContext()->isDependentContext();
case NullPtr:
Implement support for null non-type template arguments for non-type template parameters of pointer, pointer-to-member, or nullptr_t type in C++11. Fixes PR9700 / <rdar://problem/11193097>. llvm-svn: 154219
2012-04-07 06:40:38 +08:00
return false;
Introduce the notion of instantiation dependence into Clang's AST. A 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
2011-07-01 09:22:09 +08:00
case Integral:
// Never dependent
return false;
case Expression:
return getAsExpr()->isInstantiationDependent();
case Pack:
for (pack_iterator P = pack_begin(), PEnd = pack_end(); P != PEnd; ++P) {
if (P->isInstantiationDependent())
return true;
}
return false;
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148577
2012-01-21 05:50:17 +08:00
llvm_unreachable("Invalid TemplateArgument Kind!");
Introduce the notion of instantiation dependence into Clang's AST. A 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
2011-07-01 09:22:09 +08:00
}
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
bool TemplateArgument::isPackExpansion() const {
switch (getKind()) {
case Null:
case Declaration:
case Integral:
case Pack:
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case Template:
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
case NullPtr:
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
return false;
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case TemplateExpansion:
return true;
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
case Type:
Implement support for pack expansions whose pattern is a non-type 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
2011-01-04 01:17:50 +08:00
return isa<PackExpansionType>(getAsType());
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
case Expression:
Implement support for pack expansions whose pattern is a non-type 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
2011-01-04 01:17:50 +08:00
return isa<PackExpansionExpr>(getAsExpr());
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148577
2012-01-21 05:50:17 +08:00
llvm_unreachable("Invalid TemplateArgument Kind!");
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
}
Variadic templates: extend Type, NestedNameSpecifier, TemplateName, 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
2010-12-14 06:49:22 +08:00
bool TemplateArgument::containsUnexpandedParameterPack() const {
switch (getKind()) {
case Null:
case Declaration:
case Integral:
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case TemplateExpansion:
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
case NullPtr:
Variadic templates: extend Type, NestedNameSpecifier, TemplateName, 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
2010-12-14 06:49:22 +08:00
break;
case Type:
if (getAsType()->containsUnexpandedParameterPack())
return true;
break;
case Template:
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
if (getAsTemplate().containsUnexpandedParameterPack())
Variadic templates: extend Type, NestedNameSpecifier, TemplateName, 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
2010-12-14 06:49:22 +08:00
return true;
break;
case Expression:
if (getAsExpr()->containsUnexpandedParameterPack())
return true;
break;
case Pack:
for (pack_iterator P = pack_begin(), PEnd = pack_end(); P != PEnd; ++P)
if (P->containsUnexpandedParameterPack())
return true;
break;
}
return false;
}
Teach template template argument pack expansions to keep track of the number of expansions, when we know it, and propagate that information through Sema. llvm-svn: 123493
2011-01-15 07:41:42 +08:00
llvm::Optional<unsigned> TemplateArgument::getNumTemplateExpansions() const {
assert(Kind == TemplateExpansion);
if (TemplateArg.NumExpansions)
return TemplateArg.NumExpansions - 1;
return llvm::Optional<unsigned>();
}
Extract TemplateArgument into a new header just for common template classes. Move its implementation into a new module. This will seem marginally more justified in a bit. llvm-svn: 85499
2009-10-29 15:48:15 +08:00
void TemplateArgument::Profile(llvm::FoldingSetNodeID &ID,
PR3558: mark "logically const" accessor methods in ASTContext as const, and mark the fields they use as mutable. This allows us to remove a few const_casts. llvm-svn: 123314
2011-01-12 17:06:06 +08:00
const ASTContext &Context) const {
Extract TemplateArgument into a new header just for common template classes. Move its implementation into a new module. This will seem marginally more justified in a bit. llvm-svn: 85499
2009-10-29 15:48:15 +08:00
ID.AddInteger(Kind);
switch (Kind) {
case Null:
break;
case Type:
getAsType().Profile(ID);
break;
case Declaration:
ID.AddPointer(getAsDecl()? getAsDecl()->getCanonicalDecl() : 0);
break;
Introduce a new representation for template template 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
2009-11-11 09:00:40 +08:00
case Template:
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case TemplateExpansion: {
TemplateName Template = getAsTemplateOrTemplatePattern();
Canonical template arguments that are template template parameters by their template parameter depth and position, so that we can match redeclarations appropriately. Fixes PR5527 and PR5528. llvm-svn: 89654
2009-11-23 20:52:47 +08:00
if (TemplateTemplateParmDecl *TTP
= dyn_cast_or_null<TemplateTemplateParmDecl>(
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
Template.getAsTemplateDecl())) {
Canonical template arguments that are template template parameters by their template parameter depth and position, so that we can match redeclarations appropriately. Fixes PR5527 and PR5528. llvm-svn: 89654
2009-11-23 20:52:47 +08:00
ID.AddBoolean(true);
ID.AddInteger(TTP->getDepth());
ID.AddInteger(TTP->getPosition());
Add semantic analysis for the creation of and an AST representation 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
2011-01-06 01:40:24 +08:00
ID.AddBoolean(TTP->isParameterPack());
Canonical template arguments that are template template parameters by their template parameter depth and position, so that we can match redeclarations appropriately. Fixes PR5527 and PR5528. llvm-svn: 89654
2009-11-23 20:52:47 +08:00
} else {
ID.AddBoolean(false);
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
ID.AddPointer(Context.getCanonicalTemplateName(Template)
.getAsVoidPointer());
Canonical template arguments that are template template parameters by their template parameter depth and position, so that we can match redeclarations appropriately. Fixes PR5527 and PR5528. llvm-svn: 89654
2009-11-23 20:52:47 +08:00
}
Introduce a new representation for template template 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
2009-11-11 09:00:40 +08:00
break;
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
}
Introduce a new representation for template template 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
2009-11-11 09:00:40 +08:00
Extract TemplateArgument into a new header just for common template classes. Move its implementation into a new module. This will seem marginally more justified in a bit. llvm-svn: 85499
2009-10-29 15:48:15 +08:00
case Integral:
Plug a long standing memory leak in TemplateArgument. The integral APSInt value is now stored in a decomposed form and the backing store for large values is allocated via the ASTContext. This way its not leaked as TemplateArguments are never destructed when they are allocated in the ASTContext. Since the integral data is immutable it is now shared between instances, making copying TemplateArguments a trivial operation. Currently getting the integral data out of a TemplateArgument requires creating a new APSInt object. This is cheap when the value is small but can be expensive if it's not. If this turns out to be an issue a more efficient accessor could be added. llvm-svn: 158150
2012-06-07 23:09:51 +08:00
getAsIntegral().Profile(ID);
Extract TemplateArgument into a new header just for common template classes. Move its implementation into a new module. This will seem marginally more justified in a bit. llvm-svn: 85499
2009-10-29 15:48:15 +08:00
getIntegralType().Profile(ID);
break;
case Expression:
getAsExpr()->Profile(ID, Context, true);
break;
case Pack:
ID.AddInteger(Args.NumArgs);
for (unsigned I = 0; I != Args.NumArgs; ++I)
Args.Args[I].Profile(ID, Context);
}
}
Track source information for template arguments and template specialization 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
2009-10-29 16:12:44 +08:00
Split DependentNameType into two types. DependentNameType represents the 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
2010-06-11 08:33:02 +08:00
bool TemplateArgument::structurallyEquals(const TemplateArgument &Other) const {
if (getKind() != Other.getKind()) return false;
switch (getKind()) {
case Null:
case Type:
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case Expression:
case Template:
case TemplateExpansion:
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
case NullPtr:
Split DependentNameType into two types. DependentNameType represents the 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
2010-06-11 08:33:02 +08:00
return TypeOrValue == Other.TypeOrValue;
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
case Declaration:
return getAsDecl() == Other.getAsDecl() &&
isDeclForReferenceParam() && Other.isDeclForReferenceParam();
Split DependentNameType into two types. DependentNameType represents the 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
2010-06-11 08:33:02 +08:00
case Integral:
return getIntegralType() == Other.getIntegralType() &&
Plug a long standing memory leak in TemplateArgument. The integral APSInt value is now stored in a decomposed form and the backing store for large values is allocated via the ASTContext. This way its not leaked as TemplateArguments are never destructed when they are allocated in the ASTContext. Since the integral data is immutable it is now shared between instances, making copying TemplateArguments a trivial operation. Currently getting the integral data out of a TemplateArgument requires creating a new APSInt object. This is cheap when the value is small but can be expensive if it's not. If this turns out to be an issue a more efficient accessor could be added. llvm-svn: 158150
2012-06-07 23:09:51 +08:00
getAsIntegral() == Other.getAsIntegral();
Split DependentNameType into two types. DependentNameType represents the 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
2010-06-11 08:33:02 +08:00
case Pack:
if (Args.NumArgs != Other.Args.NumArgs) return false;
for (unsigned I = 0, E = Args.NumArgs; I != E; ++I)
if (!Args.Args[I].structurallyEquals(Other.Args.Args[I]))
return false;
return true;
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148577
2012-01-21 05:50:17 +08:00
llvm_unreachable("Invalid TemplateArgument Kind!");
Split DependentNameType into two types. DependentNameType represents the 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
2010-06-11 08:33:02 +08:00
}
Implement template argument deduction for pack expansions whose 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
2010-12-23 05:19:48 +08:00
TemplateArgument TemplateArgument::getPackExpansionPattern() const {
assert(isPackExpansion());
switch (getKind()) {
Add semantic analysis for the creation of and an AST representation 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
2011-01-06 01:40:24 +08:00
case Type:
return getAsType()->getAs<PackExpansionType>()->getPattern();
case Expression:
return cast<PackExpansionExpr>(getAsExpr())->getPattern();
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case TemplateExpansion:
Teach template template argument pack expansions to keep track of the number of expansions, when we know it, and propagate that information through Sema. llvm-svn: 123493
2011-01-15 07:41:42 +08:00
return TemplateArgument(getAsTemplateOrTemplatePattern());
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
Add semantic analysis for the creation of and an AST representation 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
2011-01-06 01:40:24 +08:00
case Declaration:
case Integral:
case Pack:
case Null:
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case Template:
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
case NullPtr:
Add semantic analysis for the creation of and an AST representation 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
2011-01-06 01:40:24 +08:00
return TemplateArgument();
Implement template argument deduction for pack expansions whose 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
2010-12-23 05:19:48 +08:00
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148577
2012-01-21 05:50:17 +08:00
llvm_unreachable("Invalid TemplateArgument Kind!");
Implement template argument deduction for pack expansions whose 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
2010-12-23 05:19:48 +08:00
}
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
void TemplateArgument::print(const PrintingPolicy &Policy,
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
raw_ostream &Out) const {
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
switch (getKind()) {
case Null:
Out << "<no value>";
break;
case Type: {
Objective-ARC++: infer template type arguments of ownership-unqualified retainable object type as __strong. This allows us to write, e.g., std::vector<id> and we'll infer that the vector's element types have __strong ownership semantics, which is far nicer than requiring: std::vector<__strong id> Note that we allow one to override the ownership qualifier of a substituted template type parameter, e.g., given template<typename T> struct X { typedef __weak T type; }; X<id> is treated the same as X<__strong id>. At instantiation type, the __weak in "__weak T" overrides the (inferred or specified) __strong on the template argument type, so that we can still provide metaprogramming transformations. This is part of <rdar://problem/9595486>. llvm-svn: 133303
2011-06-18 06:11:49 +08:00
PrintingPolicy SubPolicy(Policy);
SubPolicy.SuppressStrongLifetime = true;
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
std::string TypeStr;
Objective-ARC++: infer template type arguments of ownership-unqualified retainable object type as __strong. This allows us to write, e.g., std::vector<id> and we'll infer that the vector's element types have __strong ownership semantics, which is far nicer than requiring: std::vector<__strong id> Note that we allow one to override the ownership qualifier of a substituted template type parameter, e.g., given template<typename T> struct X { typedef __weak T type; }; X<id> is treated the same as X<__strong id>. At instantiation type, the __weak in "__weak T" overrides the (inferred or specified) __strong on the template argument type, so that we can still provide metaprogramming transformations. This is part of <rdar://problem/9595486>. llvm-svn: 133303
2011-06-18 06:11:49 +08:00
getAsType().getAsStringInternal(TypeStr, SubPolicy);
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
Out << TypeStr;
break;
}
case Declaration: {
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
NamedDecl *ND = cast<NamedDecl>(getAsDecl());
if (ND->getDeclName()) {
// FIXME: distinguish between pointer and reference args?
Out << *ND;
Implement support for null non-type template arguments for non-type template parameters of pointer, pointer-to-member, or nullptr_t type in C++11. Fixes PR9700 / <rdar://problem/11193097>. llvm-svn: 154219
2012-04-07 06:40:38 +08:00
} else {
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
Out << "<anonymous>";
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
}
break;
}
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
Added forgotten break. llvm-svn: 165298
2012-10-05 12:43:29 +08:00
case NullPtr:
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
Out << "nullptr";
Added forgotten break. llvm-svn: 165298
2012-10-05 12:43:29 +08:00
break;
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case Template:
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
getAsTemplate().print(Out, Policy);
break;
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case TemplateExpansion:
getAsTemplateOrTemplatePattern().print(Out, Policy);
Out << "...";
break;
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
case Integral: {
Improve bool and char integral template argument printing in diagnostics, resolving PR9227. Patch originally by Mihai Rusu and Stephen Hines with some minimal style tweaks from me. llvm-svn: 125999
2011-02-19 08:21:00 +08:00
printIntegral(*this, Out);
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
break;
}
Add semantic analysis for the creation of and an AST representation 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
2011-01-06 01:40:24 +08:00
case Expression:
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
getAsExpr()->printPretty(Out, 0, Policy);
break;
case Pack:
Out << "<";
bool First = true;
for (TemplateArgument::pack_iterator P = pack_begin(), PEnd = pack_end();
P != PEnd; ++P) {
if (First)
First = false;
else
Out << ", ";
P->print(Policy, Out);
}
Out << ">";
break;
}
}
Track source information for template arguments and template specialization 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
2009-10-29 16:12:44 +08:00
//===----------------------------------------------------------------------===//
// TemplateArgumentLoc Implementation
//===----------------------------------------------------------------------===//
When default-initializing a TemplateArgumentLocInfo, make sure that we 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
2011-01-06 08:33:28 +08:00
TemplateArgumentLocInfo::TemplateArgumentLocInfo() {
Silence more -Wnon-pod-memset given its current implementation. I may be able to revert these based on a patch I'm working on, but no reason for people to be spammed with warnings in the interim. llvm-svn: 130394
2011-04-28 16:19:45 +08:00
memset((void*)this, 0, sizeof(TemplateArgumentLocInfo));
When default-initializing a TemplateArgumentLocInfo, make sure that we 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
2011-01-06 08:33:28 +08:00
}
A few TemplateArgumentLoc clean-ups. Try to remember the Expr for a declaration. Provide an API for getting the SourceRange of a TAL and use it judiciously. llvm-svn: 85520
2009-10-30 02:45:58 +08:00
SourceRange TemplateArgumentLoc::getSourceRange() const {
Track source information for template arguments and template specialization 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
2009-10-29 16:12:44 +08:00
switch (Argument.getKind()) {
case TemplateArgument::Expression:
A few TemplateArgumentLoc clean-ups. Try to remember the Expr for a declaration. Provide an API for getting the SourceRange of a TAL and use it judiciously. llvm-svn: 85520
2009-10-30 02:45:58 +08:00
return getSourceExpression()->getSourceRange();
fix a crash in RecursiveASTVisitor's child classes (PR8403); reviewed by chandlerc. llvm-svn: 113038
2010-09-04 07:50:56 +08:00
Track source information for template arguments and template specialization 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
2009-10-29 16:12:44 +08:00
case TemplateArgument::Declaration:
A few TemplateArgumentLoc clean-ups. Try to remember the Expr for a declaration. Provide an API for getting the SourceRange of a TAL and use it judiciously. llvm-svn: 85520
2009-10-30 02:45:58 +08:00
return getSourceDeclExpression()->getSourceRange();
fix a crash in RecursiveASTVisitor's child classes (PR8403); reviewed by chandlerc. llvm-svn: 113038
2010-09-04 07:50:56 +08:00
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
case TemplateArgument::NullPtr:
return getSourceNullPtrExpression()->getSourceRange();
A few TemplateArgumentLoc clean-ups. Try to remember the Expr for a declaration. Provide an API for getting the SourceRange of a TAL and use it judiciously. llvm-svn: 85520
2009-10-30 02:45:58 +08:00
case TemplateArgument::Type:
fix a crash in RecursiveASTVisitor's child classes (PR8403); reviewed by chandlerc. llvm-svn: 113038
2010-09-04 07:50:56 +08:00
if (TypeSourceInfo *TSI = getTypeSourceInfo())
return TSI->getTypeLoc().getSourceRange();
else
return SourceRange();
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case TemplateArgument::Template:
Push nested-name-specifier source location information into template template arguments. I believe that this is the last place in the AST where we were storing a source range for a nested-name-specifier rather than a proper nested-name-specifier location structure. (Yay!) There is still a lot of cleanup to do in the TreeTransform, which doesn't take advantage of nested-name-specifiers with source-location information everywhere it could. llvm-svn: 126844
2011-03-03 01:09:35 +08:00
if (getTemplateQualifierLoc())
return SourceRange(getTemplateQualifierLoc().getBeginLoc(),
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
getTemplateNameLoc());
return SourceRange(getTemplateNameLoc());
case TemplateArgument::TemplateExpansion:
Push nested-name-specifier source location information into template template arguments. I believe that this is the last place in the AST where we were storing a source range for a nested-name-specifier rather than a proper nested-name-specifier location structure. (Yay!) There is still a lot of cleanup to do in the TreeTransform, which doesn't take advantage of nested-name-specifiers with source-location information everywhere it could. llvm-svn: 126844
2011-03-03 01:09:35 +08:00
if (getTemplateQualifierLoc())
return SourceRange(getTemplateQualifierLoc().getBeginLoc(),
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
getTemplateEllipsisLoc());
return SourceRange(getTemplateNameLoc(), getTemplateEllipsisLoc());
Track source information for template arguments and template specialization 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
2009-10-29 16:12:44 +08:00
case TemplateArgument::Integral:
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
return getSourceIntegralExpression()->getSourceRange();
Track source information for template arguments and template specialization 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
2009-10-29 16:12:44 +08:00
case TemplateArgument::Pack:
case TemplateArgument::Null:
A few TemplateArgumentLoc clean-ups. Try to remember the Expr for a declaration. Provide an API for getting the SourceRange of a TAL and use it judiciously. llvm-svn: 85520
2009-10-30 02:45:58 +08:00
return SourceRange();
Track source information for template arguments and template specialization 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
2009-10-29 16:12:44 +08:00
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148577
2012-01-21 05:50:17 +08:00
llvm_unreachable("Invalid TemplateArgument Kind!");
Track source information for template arguments and template specialization 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
2009-10-29 16:12:44 +08:00
}
When printing a non-viable overload candidate that failed due to 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
2010-05-09 01:41:32 +08:00
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
TemplateArgumentLoc
TemplateArgumentLoc::getPackExpansionPattern(SourceLocation &Ellipsis,
Keep track of the number of expansions to be produced from a type pack 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
2011-01-15 01:04:44 +08:00
llvm::Optional<unsigned> &NumExpansions,
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
ASTContext &Context) const {
assert(Argument.isPackExpansion());
switch (Argument.getKind()) {
case TemplateArgument::Type: {
Add a hack to work around the lack of proper type-source info in a pack expansion TypeLoc llvm-svn: 122367
2010-12-22 06:10:26 +08:00
// FIXME: We shouldn't ever have to worry about missing
// type-source info!
TypeSourceInfo *ExpansionTSInfo = getTypeSourceInfo();
if (!ExpansionTSInfo)
ExpansionTSInfo = Context.getTrivialTypeSourceInfo(
getArgument().getAsType(),
Ellipsis);
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
PackExpansionTypeLoc Expansion
Add a hack to work around the lack of proper type-source info in a pack expansion TypeLoc llvm-svn: 122367
2010-12-22 06:10:26 +08:00
= cast<PackExpansionTypeLoc>(ExpansionTSInfo->getTypeLoc());
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
Ellipsis = Expansion.getEllipsisLoc();
TypeLoc Pattern = Expansion.getPatternLoc();
Keep track of the number of expansions to be produced from a type pack 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
2011-01-15 01:04:44 +08:00
NumExpansions = Expansion.getTypePtr()->getNumExpansions();
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
// FIXME: This is horrible. We know where the source location data is for
// the pattern, and we have the pattern's type, but we are forced to copy
// them into an ASTContext because TypeSourceInfo bundles them together
// and TemplateArgumentLoc traffics in TypeSourceInfo pointers.
TypeSourceInfo *PatternTSInfo
= Context.CreateTypeSourceInfo(Pattern.getType(),
Pattern.getFullDataSize());
memcpy(PatternTSInfo->getTypeLoc().getOpaqueData(),
Pattern.getOpaqueData(), Pattern.getFullDataSize());
return TemplateArgumentLoc(TemplateArgument(Pattern.getType()),
PatternTSInfo);
}
Implement support for pack expansions whose pattern is a non-type 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
2011-01-04 01:17:50 +08:00
case TemplateArgument::Expression: {
When default-initializing a TemplateArgumentLocInfo, make sure that we 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
2011-01-06 08:33:28 +08:00
PackExpansionExpr *Expansion
= cast<PackExpansionExpr>(Argument.getAsExpr());
Expr *Pattern = Expansion->getPattern();
Ellipsis = Expansion->getEllipsisLoc();
Teach PackExpansionExpr to keep track of the number of pack expansions it will expand to, if known. Propagate this information throughout Sema. llvm-svn: 123470
2011-01-15 05:20:45 +08:00
NumExpansions = Expansion->getNumExpansions();
Implement support for pack expansions whose pattern is a non-type 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
2011-01-04 01:17:50 +08:00
return TemplateArgumentLoc(Pattern, Pattern);
}
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case TemplateArgument::TemplateExpansion:
When default-initializing a TemplateArgumentLocInfo, make sure that we 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
2011-01-06 08:33:28 +08:00
Ellipsis = getTemplateEllipsisLoc();
Teach template template argument pack expansions to keep track of the number of expansions, when we know it, and propagate that information through Sema. llvm-svn: 123493
2011-01-15 07:41:42 +08:00
NumExpansions = Argument.getNumTemplateExpansions();
Add semantic analysis for the creation of and an AST representation 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
2011-01-06 01:40:24 +08:00
return TemplateArgumentLoc(Argument.getPackExpansionPattern(),
Push nested-name-specifier source location information into template template arguments. I believe that this is the last place in the AST where we were storing a source range for a nested-name-specifier rather than a proper nested-name-specifier location structure. (Yay!) There is still a lot of cleanup to do in the TreeTransform, which doesn't take advantage of nested-name-specifiers with source-location information everywhere it could. llvm-svn: 126844
2011-03-03 01:09:35 +08:00
getTemplateQualifierLoc(),
Add semantic analysis for the creation of and an AST representation 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
2011-01-06 01:40:24 +08:00
getTemplateNameLoc());
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
case TemplateArgument::Declaration:
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
case TemplateArgument::NullPtr:
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
case TemplateArgument::Template:
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
case TemplateArgument::Integral:
case TemplateArgument::Pack:
case TemplateArgument::Null:
return TemplateArgumentLoc();
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148577
2012-01-21 05:50:17 +08:00
llvm_unreachable("Invalid TemplateArgument Kind!");
Implement basic support for template instantiation of pack expansions 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
2010-12-21 06:05:00 +08:00
}
When printing a non-viable overload candidate that failed due to 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
2010-05-09 01:41:32 +08:00
const DiagnosticBuilder &clang::operator<<(const DiagnosticBuilder &DB,
const TemplateArgument &Arg) {
switch (Arg.getKind()) {
case TemplateArgument::Null:
operator<< on a DiagnosticBuilder should *always* output exactly one thing. Null template arguments are bad, but they're better than crashing with an argument mismatch. llvm-svn: 110312
2010-08-05 12:58:04 +08:00
// This is bad, but not as bad as crashing because of argument
// count mismatches.
return DB << "(null template argument)";
When printing a non-viable overload candidate that failed due to 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
2010-05-09 01:41:32 +08:00
case TemplateArgument::Type:
return DB << Arg.getAsType();
case TemplateArgument::Declaration:
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
return DB << Arg.getAsDecl();
case TemplateArgument::NullPtr:
Implement support for null non-type template arguments for non-type template parameters of pointer, pointer-to-member, or nullptr_t type in C++11. Fixes PR9700 / <rdar://problem/11193097>. llvm-svn: 154219
2012-04-07 06:40:38 +08:00
return DB << "nullptr";
When printing a non-viable overload candidate that failed due to 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
2010-05-09 01:41:32 +08:00
case TemplateArgument::Integral:
Plug a long standing memory leak in TemplateArgument. The integral APSInt value is now stored in a decomposed form and the backing store for large values is allocated via the ASTContext. This way its not leaked as TemplateArguments are never destructed when they are allocated in the ASTContext. Since the integral data is immutable it is now shared between instances, making copying TemplateArguments a trivial operation. Currently getting the integral data out of a TemplateArgument requires creating a new APSInt object. This is cheap when the value is small but can be expensive if it's not. If this turns out to be an issue a more efficient accessor could be added. llvm-svn: 158150
2012-06-07 23:09:51 +08:00
return DB << Arg.getAsIntegral().toString(10);
When printing a non-viable overload candidate that failed due to 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
2010-05-09 01:41:32 +08:00
case TemplateArgument::Template:
Replace the representation of template template argument pack 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
2011-01-06 02:58:31 +08:00
return DB << Arg.getAsTemplate();
case TemplateArgument::TemplateExpansion:
return DB << Arg.getAsTemplateOrTemplatePattern() << "...";
When printing a non-viable overload candidate that failed due to 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
2010-05-09 01:41:32 +08:00
case TemplateArgument::Expression: {
// This shouldn't actually ever happen, so it's okay that we're
// regurgitating an expression here.
// FIXME: We're guessing at LangOptions!
Basic: import SmallString<> into clang namespace (I was going to fix the TODO about DenseMap too, but that would break self-host right now. See PR11922.) llvm-svn: 149799
2012-02-05 10:13:05 +08:00
SmallString<32> Str;
When printing a non-viable overload candidate that failed due to 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
2010-05-09 01:41:32 +08:00
llvm::raw_svector_ostream OS(Str);
LangOptions LangOpts;
LangOpts.CPlusPlus = true;
PrintingPolicy Policy(LangOpts);
Arg.getAsExpr()->printPretty(OS, 0, Policy);
return DB << OS.str();
}
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
case TemplateArgument::Pack: {
// FIXME: We're guessing at LangOptions!
Basic: import SmallString<> into clang namespace (I was going to fix the TODO about DenseMap too, but that would break self-host right now. See PR11922.) llvm-svn: 149799
2012-02-05 10:13:05 +08:00
SmallString<32> Str;
Clean up the handling of template argument packs, especially in the area of printing template arguments. The functionality changes here are limited to cases of variadic templates that aren't yet enabled. llvm-svn: 122250
2010-12-21 00:52:59 +08:00
llvm::raw_svector_ostream OS(Str);
LangOptions LangOpts;
LangOpts.CPlusPlus = true;
PrintingPolicy Policy(LangOpts);
Arg.print(Policy, OS);
return DB << OS.str();
}
When printing a non-viable overload candidate that failed due to 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
2010-05-09 01:41:32 +08:00
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148577
2012-01-21 05:50:17 +08:00
llvm_unreachable("Invalid TemplateArgument Kind!");
When printing a non-viable overload candidate that failed due to 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
2010-05-09 01:41:32 +08:00
}
Don't use TemplateArgumentListInfo inside AST nodes because it may leak. Use ASTTemplateArgumentListInfo instead. llvm-svn: 140331
2011-09-23 04:07:09 +08:00
const ASTTemplateArgumentListInfo *
ASTTemplateArgumentListInfo::Create(ASTContext &C,
const TemplateArgumentListInfo &List) {
Fix overallocation and underalignment of ASTTemplateArgumentListInfo objects. llvm-svn: 161918
2012-08-15 09:22:58 +08:00
std::size_t size = ASTTemplateArgumentListInfo::sizeFor(List.size());
Don't use TemplateArgumentListInfo inside AST nodes because it may leak. Use ASTTemplateArgumentListInfo instead. llvm-svn: 140331
2011-09-23 04:07:09 +08:00
void *Mem = C.Allocate(size, llvm::alignOf<ASTTemplateArgumentListInfo>());
ASTTemplateArgumentListInfo *TAI = new (Mem) ASTTemplateArgumentListInfo();
TAI->initializeFrom(List);
return TAI;
}
void ASTTemplateArgumentListInfo::initializeFrom(
const TemplateArgumentListInfo &Info) {
LAngleLoc = Info.getLAngleLoc();
RAngleLoc = Info.getRAngleLoc();
NumTemplateArgs = Info.size();
TemplateArgumentLoc *ArgBuffer = getTemplateArgs();
for (unsigned i = 0; i != NumTemplateArgs; ++i)
new (&ArgBuffer[i]) TemplateArgumentLoc(Info[i]);
}
void ASTTemplateArgumentListInfo::initializeFrom(
const TemplateArgumentListInfo &Info,
bool &Dependent,
bool &InstantiationDependent,
bool &ContainsUnexpandedParameterPack) {
LAngleLoc = Info.getLAngleLoc();
RAngleLoc = Info.getRAngleLoc();
NumTemplateArgs = Info.size();
TemplateArgumentLoc *ArgBuffer = getTemplateArgs();
for (unsigned i = 0; i != NumTemplateArgs; ++i) {
Dependent = Dependent || Info[i].getArgument().isDependent();
InstantiationDependent = InstantiationDependent ||
Info[i].getArgument().isInstantiationDependent();
ContainsUnexpandedParameterPack
= ContainsUnexpandedParameterPack ||
Info[i].getArgument().containsUnexpandedParameterPack();
new (&ArgBuffer[i]) TemplateArgumentLoc(Info[i]);
}
}
void ASTTemplateArgumentListInfo::copyInto(
TemplateArgumentListInfo &Info) const {
Info.setLAngleLoc(LAngleLoc);
Info.setRAngleLoc(RAngleLoc);
for (unsigned I = 0; I != NumTemplateArgs; ++I)
Info.addArgument(getTemplateArgs()[I]);
}
std::size_t ASTTemplateArgumentListInfo::sizeFor(unsigned NumTemplateArgs) {
return sizeof(ASTTemplateArgumentListInfo) +
sizeof(TemplateArgumentLoc) * NumTemplateArgs;
}
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
void
ASTTemplateKWAndArgsInfo::initializeFrom(SourceLocation TemplateKWLoc,
const TemplateArgumentListInfo &Info) {
Base::initializeFrom(Info);
setTemplateKeywordLoc(TemplateKWLoc);
}
void
ASTTemplateKWAndArgsInfo
::initializeFrom(SourceLocation TemplateKWLoc,
const TemplateArgumentListInfo &Info,
bool &Dependent,
bool &InstantiationDependent,
bool &ContainsUnexpandedParameterPack) {
Base::initializeFrom(Info, Dependent, InstantiationDependent,
ContainsUnexpandedParameterPack);
setTemplateKeywordLoc(TemplateKWLoc);
}
void
ASTTemplateKWAndArgsInfo::initializeFrom(SourceLocation TemplateKWLoc) {
// No explicit template arguments, but template keyword loc is valid.
assert(TemplateKWLoc.isValid());
LAngleLoc = SourceLocation();
RAngleLoc = SourceLocation();
NumTemplateArgs = 0;
setTemplateKeywordLoc(TemplateKWLoc);
}
std::size_t
ASTTemplateKWAndArgsInfo::sizeFor(unsigned NumTemplateArgs) {
// Add space for the template keyword location.
Fix overallocation and underalignment of ASTTemplateArgumentListInfo objects. llvm-svn: 161918
2012-08-15 09:22:58 +08:00
// FIXME: There's room for this in the padding before the template args in
// 64-bit builds.
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
return Base::sizeFor(NumTemplateArgs) + sizeof(SourceLocation);
Don't use TemplateArgumentListInfo inside AST nodes because it may leak. Use ASTTemplateArgumentListInfo instead. llvm-svn: 140331
2011-09-23 04:07:09 +08:00
}