[cxx-abi-dev] Mangling of generic lambda

[Richard Smith]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20161208/09c8e9d9/attachment.html>