Re: [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters

[Cary Coutant <ccoutant@google.com>]

Ping. I'm getting more reports of this bug internally, and it would be
nice to have the fix upstream.

-cary


On Mon, Oct 13, 2014 at 11:43 AM, Cary Coutant <ccoutant@google.com> wrote:
> Ping. Jason, do you still think the special-case for conversion ops is
> inappropriate?
>
> -cary
>
>
> On Fri, Jul 25, 2014 at 2:16 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 07/24/2014 11:35 PM, Cary Coutant wrote:
>>>> It seems that the problem here is more general; a template argument list is
>>>> not in scope within that same template argument list.  Can't we fix that
>>>> without special-casing conversion ops?
>>>
>>> I think conversion ops really are a special case.
>>
>> Thanks Cary.  FWIW, I agree.
>>
>> (GDB 7.8 hasn't been released yet, though it's close.  If this
>> patch is approved as is, we'll be able to have the crash
>> fixed there.  If this requires a significant rewrite though,
>> I'm afraid I might not be able to do it myself anytime soon.)
>>
>>> It's the only case
>>> where the template parameters refer to the template argument list from
>>> the cast operator's enclosing template. In a cast expression, like
>>> anywhere else you might have a template parameter, the template
>>> parameter refers to the template argument list of the immediately
>>> enclosing template.
>>>
>>> I think this note from Section 5.1.3 (Operator Encodings) of the ABI
>>> is what makes this a special case (it's an informative comment in the
>>> document, but seems to me to be normative):
>>>
>>> "For a user-defined conversion operator the result type (i.e., the
>>> type to which the operator converts) is part of the mangled name of
>>> the function. If the conversion operator is a member template, the
>>> result type will appear before the template parameters. There may be
>>> forward references in the result type to the template parameters."
>>>
>>
>> --
>> Thanks,
>> Pedro Alves
>>