[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 Patrick Palka ppalka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #8 from Patrick Palka ppalka at gcc dot gnu.org --- Fixed.
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 --- Comment #7 from Patrick Palka ppalka at gcc dot gnu.org --- Author: ppalka Date: Wed Jul 1 01:07:35 2015 New Revision: 225220 URL: https://gcc.gnu.org/viewcvs?rev=225220root=gccview=rev Log: Fix PR c++/66686 (dependent template template substitution) gcc/cp/ChangeLog: PR c++/66686 * pt.c (coerce_template_template_parm) [PARM_DECL]: Don't return 0 if tsubst returns a dependent type. gcc/testsuite/ChangeLog: PR c++/66686 * g++.dg/template/pr66686.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/pr66686.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 Martin Sebor msebor at gcc dot gnu.org changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor msebor at gcc dot gnu.org --- The code doesn't look valid to me: Y is not a valid template argument for the template template parameter C. Of the compilers I tried GCC, EDG eccp, and IBM XLC++ all reject it (the latter two with a clear error message confirming the above). Clang is the only one that accepts it.
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 --- Comment #2 from Patrick Palka ppalka at gcc dot gnu.org --- (In reply to Martin Sebor from comment #1) The code doesn't look valid to me: Y is not a valid template argument for the template template parameter C. But once struct X gets instantiated like in the very last line, doesn't it become a valid template argument? There, B is set to int, thus the template parameter C gets the type template int class which is exactly the type of the template Y.
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 --- Comment #3 from Patrick Palka ppalka at gcc dot gnu.org --- (In reply to Patrick Palka from comment #2) (In reply to Martin Sebor from comment #1) The code doesn't look valid to me: Y is not a valid template argument for the template template parameter C. But once struct X gets instantiated like in the very last line, doesn't it become a valid template argument? There, B is set to int, thus the template parameter C gets the type template int class which is exactly the type of the template Y. Err, I meant the parameter Z gets the type template int class which is exactly the type of the template Y. So it seems that early-rejecting this template definition is too pessimistic because there exist template arguments that make the instantiated code valid.
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686
--- Comment #4 from Martin Sebor msebor at gcc dot gnu.org ---
Y takes a non-type template argument which isn't provided and can't be deduced
in the instantiation (i.e., what would the value of N be in YN?)
Modifying the test case a bit to see the type Clang gives a.a shows that it
winds up instantiating an object of type AY even though no such type exists,
indicating it's a Clang bug.
$ cat t.cpp /build/llvm-3.6.0/bin/clang++ -Wall -Wextra -Wpedantic
t.cpptemplate template int class struct A { };
template int struct Y { };
template class, class B, template template B class class C
struct X { CY a; };
Xint, int, A a;
template class T void foo (T);
int main () { foo (a.a); }
/tmp/t-310f66.o: In function `main':
t.cpp:(.text+0x9): undefined reference to `void fooAY (AY)'
clang-3.6: error: linker command failed with exit code 1 (use -v to see
invocation)
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686
--- Comment #5 from Patrick Palka ppalka at gcc dot gnu.org ---
(In reply to Martin Sebor from comment #4)
Y takes a non-type template argument which isn't provided and can't be
deduced in the instantiation (i.e., what would the value of N be in YN?)
Can't you say that for all templates passed as arguments to template template
parameters?
Modifying the test case a bit to see the type Clang gives a.a shows that it
winds up instantiating an object of type AY even though no such type
exists, indicating it's a Clang bug.
I'm not sure I understand when you say that the type AY does not exist. I
can declare the variable AY zzz; just fine, and I can declare a function
that takes an AY as an argument, for example. AY seems like a standard
template.
$ cat t.cpp /build/llvm-3.6.0/bin/clang++ -Wall -Wextra -Wpedantic
t.cpptemplate template int class struct A { };
template int struct Y { };
template class, class B, template template B class class C
struct X { CY a; };
Xint, int, A a;
template class T void foo (T);
int main () { foo (a.a); }
/tmp/t-310f66.o: In function `main':
t.cpp:(.text+0x9): undefined reference to `void fooAY (AY)'
clang-3.6: error: linker command failed with exit code 1 (use -v to see
invocation)
Sorry for my misunderstanding, I can't quite see the problem here.
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 --- Comment #6 from Martin Sebor msebor at gcc dot gnu.org --- The misunderstanding was mine -- I had forgotten that a template template can be instantiated on a template without providing or deducing the arguments for the latter. Please disregard my comment #4.
