public inbox for
 help / color / mirror / Atom feed
From: Jason Merrill <>
To: Nathan Sidwell <>, GCC Patches <>
Cc: patrick Palka <>
Subject: Re: c++: Lambda context mangling
Date: Fri, 7 Oct 2022 11:22:52 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 

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

      reply	other threads:[~2022-10-07 15:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 12:27 Nathan Sidwell
2022-10-07 15:22 ` Jason Merrill [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).