aee4925507
Based on post-commit review discussion on2bd8493847with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in277623f4d5Reverted inf9ad1d1c77due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
23 lines
993 B
C++
23 lines
993 B
C++
// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify %s
|
|
|
|
template<class ... Types> void f(Types ... args);
|
|
|
|
void test() {
|
|
f();
|
|
f(1);
|
|
f(2, 1.0);
|
|
}
|
|
|
|
// Test simple recursive variadic function template
|
|
template<typename Head, typename ...Tail>
|
|
void recurse_until_fail(const Head &, const Tail &...tail) { // expected-note{{candidate function template not viable: requires at least 1 argument, but 0 were provided}}
|
|
recurse_until_fail(tail...); // expected-error{{no matching function for call to 'recurse_until_fail'}} \
|
|
// expected-note{{in instantiation of function template specialization 'recurse_until_fail<char[7]>' requested here}} \
|
|
// expected-note{{in instantiation of function template specialization 'recurse_until_fail<double, char[7]>' requested here}}
|
|
}
|
|
|
|
void test_recurse_until_fail() {
|
|
recurse_until_fail(1, 3.14159, "string"); // expected-note{{in instantiation of function template specialization 'recurse_until_fail<int, double, char[7]>' requested here}}
|
|
|
|
}
|