Re: [C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Jason Merrill <jason at redhat dot com>]

On Thu, Mar 1, 2018 at 11:00 AM, Jason Merrill <jason@redhat.com> wrote:
> On Thu, Mar 1, 2018 at 9:41 AM, Jason Merrill <jason@redhat.com> wrote:
>> On Wed, Feb 28, 2018 at 4:04 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>>> On 28/02/2018 20:20, Jason Merrill wrote:
>>>>
>>>> Hmm, the test seems wrong; the diagnostic talks about specializing the
>>>> arguments, but the actual test is checking whether the enclosing scope
>>>> is fully specialized.  It looks like you'll give the same error for
>>>>
>>>> template <class T>
>>>> struct A {
>>>>    template <class U>
>>>>    static const U u;
>>>> };
>>>>
>>>> template <class T>
>>>> template <class U>
>>>> const U* A<T>::u<U*> = nullptr;
>>>>
>>>> which does specialize the argument; since we accept
>>>>
>>>> template <class T>
>>>> struct A {
>>>>    template <class U>
>>>>    struct B;
>>>> };
>>>>
>>>> template <class T>
>>>> template <class U>
>>>> struct A<T>::B<U*> { };
>>>>
>>>> we ought to accept the above as well.
>>>>
>>>> So, we could reject the testcase with this error, but we would need to
>>>> test for it using the same check as in process_partial_specialization.
>>>
>>> I see. Doing that seems relatively easy - I have a draft which appears to
>>> work - but then we have immediately to change the gcc_assert at the
>>> beginning of determine_specialization to let such specializations through
>>> (of course it still uses the wrong test!!).  I'm not sure about the best way
>>> to do that... But that seems also doable.
>>
>> That test is correct for functions, I think we just want to restrict
>> that block to functions.
>>
>>> The next problem is
>>> duplicate_decls which apparently misses a bit of code to understand that the
>>> new declaration does not conflict with the old one near line #1650... So,
>>> frankly, I think that even with your great guidance I would need a few
>>> iterations to get right the whole package and we are so damn close to the
>>> release. What do you think? Do you want to take this over, or maybe you see
>>> us restricting a bit what we'll have working in this area for 8.1.0?
>>
>> Yeah, I'll take it.
>
> Ah, needed to fix the code in start_decl that checks for a variable
> template specialization to consider that a specialization can be a
> template.

And this fixes the other testcase in comment 6.

Attachment: 71569-2.diff
Description: Text document