On 1/16/25 7:24 PM, Nathaniel Shead wrote:
On Thu, Jan 16, 2025 at 07:09:33PM -0500, Jason Merrill wrote:
On 1/6/25 7:22 AM, Nathaniel Shead wrote:
I'm not 100% sure I've handled this properly, any feedback welcome.
In particular, maybe should I use `DECL_IMPLICIT_TYPEDEF_P` in the
mangling logic instead of `!TYPE_DECL_ALIAS_P`?  They both seem to work
in this case but not sure which would be clearer.

I also looked into trying do a limited form of 'start_decl' before
parsing the type but there were too many circular dependencies for me to
work through, so I think any such changes would have to wait till GCC16
(if they're even possible at all).

-- >8 --

This adds mangling support for lambdas with a mangling context of an
alias template, and gives that context when instantiating such a lambda.

I think this is wrong, an alias is not an entity so it is not a definable
item.

The ABI change proposal also doesn't mention aliases.

Ah right, I see; I'd treated https://eel.is/c++draft/basic.def.odr#1.5
as being any template, but I see now it's "any templated entity" which
is different (since as you say an alias isn't an entity).

In that case, how do you think we should handle class-scope alias
templates of lambdas?  Such a class is surely a definable item, and so
e.g.

   struct S {
     template <int I>
     using X = decltype([]{ return I; });
   };
   using L1 = S::X<1>;
   using L2 = S::X<2>;

should this work and declare L1 to be the same type across TUs?

Hmm, I suppose it should. So then using the alias template name in the mangling is then not because it's a definable item, but just as a convenient label to indicate where it appears in the class and what the template arguments apply to.

But even with that understanding, many of the changes in this patch to make aliases more special seem wrong, we shouldn't need those just to push/pop lambda scope?

Jason

Reply via email to