[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- --- Comment #15 from Markus Trippelsdorf --- OK. Thanks. I will let Jason decide.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #14 from Alexander Kondratskiy --- Stackoverflow question/answer: http://stackoverflow.com/questions/35875829/template-parameters-not-deducible-in-partial-specialization-in-gcc6-for-a-case
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comment #13 from Barry Revzin ---
Markus - note that clang warns about the specialization, but compiles the
example anyway which actually requires the selection of the supposedly
unselectable specialization.
This example:
template struct X {};
template struct X {};
isn't related, since here T is a non-deduced context (nested-name-specifier),
but OP's example is:
template
struct predicate::template inner>
U is not in the nested-name-specifier, T is... but T isn't being deduced.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #12 from Alexander Kondratskiy --- Ok, I will ask stackoverflow. Thanks.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #11 from Markus Trippelsdorf --- (In reply to Alexander Kondratskiy from comment #10) > My issue is that this code was accepted since gcc 4.8 completely fine. > Unless there is a specific line in the standard that prevents this from > working, I don't understand how appealing to potential failures in other > compilers is a valid argument. The standard is available, e.g.: http://eel.is/c++draft/. You may ask on stackoverflow for pointers to the specific line. The burden of proof is on your side. If your testcase would be accepted by all compilers except gcc-6 then you have a valid case.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #10 from Alexander Kondratskiy --- My issue is that this code was accepted since gcc 4.8 completely fine. Unless there is a specific line in the standard that prevents this from working, I don't understand how appealing to potential failures in other compilers is a valid argument.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #9 from Markus Trippelsdorf --- There is really no need to take another look. When your testcase generates a warning under clang and also gets rejected by MSVC, it is obvious that there is something wrong with it.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
--- Comment #8 from Alexander Kondratskiy ---
I'm sorry Markus, but "clang issues a warning" is not a good enough reason to
mark this invalid. By the same token, the warning in clang could have been
introduced "because gcc issues an error". What happened to independent
implementations?
The example you gave:
template struct X {};
template struct X {};
is not the same situation as I posted originally. Here, the nested type foo is
nested inside a type trying to be deduced. I would never expect this to work,
and I agree with clang that it should be an error
My original example is closer to something like:
struct outer{ template struct foo { }; };
template struct X {};
template struct X {};
The outer type is concrete here, and in my original example.
Please, take another look.
Thank you.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
--- Comment #7 from Alexander Kondratskiy ---
To add some color, maybe this is related to non-deduced contexts from
14.8.2.5p5 in the standard:
The non-deduced contexts are:
— The nested-name-specifier of a type that was specified using a qualified-id.
So I agree that this should not work for code like the following, where the T
in outer is being deduced:
template
struct outer
{
template
struct inner
{
};
};
// doesn't work, because non-deduced context
template
void foo(typename outer::template inner val)
{ }
void bar()
{
foo(typename outer::template inner{});
}
But in the situation mentioned here, outer is a concrete type, so anything
within it should be deducible. If I get rid of the template parameter on outer,
everything works fine, and the following code compiles:
// no outer template!
struct outer
{
template
struct inner
{
};
};
struct is_inner_for
{
template
struct predicate
{
static constexpr bool value = false;
};
template
struct predicate
{
static constexpr bool value = true;
};
};
static_assert(
is_inner_for::predicate<
outer::inner
>::value,
"Yay!"
);
This simplified case where outer has no template parameter, in my mind should
not be any different from the original problem - it's just that we had a
template parameter but it was fully specified.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||trippels at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #6 from Markus Trippelsdorf ---
template struct X {};
template struct X {};
is another example were clang just warns, but an error is clearly indicated.
Closing bug as invalid.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #2 from Alexander Kondratskiy --- Looking at the diffs in r229628 linked by Jakub, I find the changes to lines 8791 and 8793 in pt.c to be kinda fishy: https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/pt.c?r1=229628=229627=229628
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P3 --- Comment #5 from Jakub Jelinek --- Setting back P3, until we agree if this is a compiler bug or not.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #3 from Alexander Kondratskiy --- Sorry, I take the "fishy" comment back. I'm not familiar enough with the code.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
--- Comment #4 from Markus Trippelsdorf ---
I'm not sure this is a compiler bug at all.
Even clang warns:
foo.ii:10:32: warning: class template partial specialization contains a
template parameter that cannot be deduced; this partial specialization will
never be used
template struct predicate::template inner>
{
^~~
foo.ii:10:22: note: non-deducible template parameter 'U'
template struct predicate::template inner>
{
^
1 warning generated.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-08 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r229628.
