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 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.

Tested x86_64-pc-linux-gnu, applying to trunk.

Attachment: 71569.diff
Description: Text document