[cxx-abi-dev] Mangling of generic lambda

[Jason Merrill]

On Thu, Dec 8, 2016 at 5:31 PM, Richard Smith <richardsmith at googlers.com> wrote:
> On 8 December 2016 at 10:41, Jason Merrill <jason at redhat.com> wrote:
>>
>> How should 'auto' parameters in a generic lambda be mangled?  Mangling
>> them as normal template parameters doesn't really work, as they can
>> end up with the same mangling as the template parameter for which they
>> are an argument.
>>
>> template<typename T>
>> T &&forward (T &v)
>> {
>>   return static_cast<T &&>(v);
>> }
>>
>> template<typename FN>
>>   void indirect (FN &&handler)
>> {
>>   forward<FN> (handler);
>> }
>>
>> inline void Foo ()
>> {
>>   auto lambda = [](auto &) { };
>>
>>   forward (lambda);
>>   indirect (lambda);
>> }
>>
>> void (*p)() = Foo;
>>
>> For this GCC and Clang both currently produce
>>
>> _Z7forwardIZ3FoovEUlRT_E_EOS0_S1_
>>
>> where the T_ refers to the template parameter currently being
>> described, causing the demangler to crash due to infinite recursion
>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78252).
>>
>> Nathan proposes to change the parameters to mangle using Da, which
>> seems reasonable.  I'm not sure how that will extend to concepts, but
>> concepts mangling as a whole is an unsolved problem.
>>
>> Any thoughts?
>
>
> Are there cases where the current scheme causes mangling collisions (where
> T_ can actually be interpreted two different ways)? It seems to me that, so
> long as we continue to be careful to restrict lambda-expressions from
> appearing in a signature (either directly or via an alias template), T_
> within the scope of Ul...E can /only/ mean the template parameter of the
> lambda-expression itself, and not an enclosing template parameter.
>
> Of note is the repeated suggestion to allow explicit template parameter
> lists in lambdas (at this point, I'd give this a very solid chance of being
> part of C++20):
>
>   auto lambda = []<typename T>(T a, T b) {};
>
> We would presumably need to mangle that as UlT_T_E even with the Da
> suggestion, so it seems that demanglers are just going to need to cope with
> Ul introducing a new template parameter scope.

Makes sense.

Jason