Re: c++: Lambda context mangling

[Jason Merrill <jason@redhat.com>]

On 10/7/22 08:27, Nathan Sidwell wrote:
> VAR and FIELD decls can become part of a lambda context, when the
> lambda is 'attached' to that entity (It's a C++20 ODR thing that was
> discovered with modules, but is actually separate.)  We were not
> marking those decls as substitution candidates, leading to demangling
> failures and compiler variance.
> 
> The alternative I chose is to bump the ABI, and add them to the
> substitution table.  I think this is the intent of the ABI.

Agreed: <closure-prefix> is a <prefix>, and <prefix>es are substitution 
candidates.

> The other alternative would be for the demangler to pop off the most
> recent substitution when it saw the 'M'.  But we'd have to change [at
> least] the libiberty demangler[*] and the clang demangler and the clang
> mangler, which seems a bigger challenge.
> 
> I'll commit this next week, unless y'all have comments.
> 
> We have other divergence from clang, with templated lambdas.  Clang 
> added new manglings [Ty, Tn, Tt] for the lambda's template head (Richard 
> has a pull request, but it's not merged 
> https://github.com/itanium-cxx-abi/cxx-abi/issues/31).  Without that, we 
> consider all the template args to be auto when demangling (which is 
> going to look odd for non-type template args).  This divergence in 
> signature also affects the lambda numbering, as gcc & clang differ in 
> their opinions about 'same lamda signature'.   thoughts on addressing 
> that to in this cycle?

That sounds good: From looking over the issue and pull request, it seems 
pretty well baked.

> I have some demangler fixes coming up.
> 
> nathan
> 
> [*] the demangler already seems to have a bug with 'M' handling.
>