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. > > Jason >
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? In which case it would need mangling to include the template arguments. Or because this is a template instantiation are there different rules? The alternative would of course be that such lambdas are TU-local, which is what I believe Clang currently does. Nathaniel
