https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124781
--- Comment #4 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
(In reply to Marcel Laverdet from comment #3)
> Thank you for the lightning-fast responses Nathaniel!
>
> I have another one which probably shouldn't fail. This is not a regression
> and also fails on gcc-15.
>
> I would expect both exports to be `int`
>
> -----
>
> export module test;
>
> template <auto Value>
> using decltype_t = decltype(Value);
>
> constexpr auto fn = [] { return 0; };
>
> // this is fine
> export template <class>
> using xx = decltype_t<fn()>;
>
> // this is not
> export template <class>
> using yy = decltype_t<[] { return 0; }()>;
>
> -----
>
> root[01:18:16] [/workspace] $ g++ -std=c++26 -Wall -fmodules -c a.cc
> a.cc:4:7: error: ‘using decltype_t = decltype (<lambda>())’ exposes TU-local
> entity ‘template<class> struct<lambda()>’
> 4 | using decltype_t = decltype(Value);
> | ^~~~~~~~~~
> a.cc:14:24: note: ‘<lambda()>’ has no name and cannot be differentiated from
> similar lambdas in other TUs
> 14 | using yy = decltype_t<[] { return 0; }()>;
> | ^
I'm tracking this problem as the last remaining issue in PR116568. I agree
that this should probably compile; unfortunately, my hands are somewhat tied
because the Itanium ABI gives no mangling for this lambda, which is the
mechanism we use to distinguish lambdas across imported TUs. And strictly
following the wording in the standard (https://eel.is/c++draft/basic.link#15.2)
this is a TU-local type, so a diagnostic is required.
'xx' works because the lambda has been keyed to 'fn' for name mangling
purposes, and so we can generate a mangled name for it:
_ZNKW4test2fnMS_UlvE_clEv. But there's no good entity to bind a lambda
declared within the alias template 'zz', as we don't want to expose alias names
within mangled names. And using an internal name can cause some havoc if there
are collisions with other imported/newly declared lambda types, and especially
once we try to merge matching lambda instantiations imported in different TUs.
Perhaps in this specific case we could exploit that the lambda type itself
doesn't actually escape the 'decltype', as done for concepts (see CWG2988), but
I'm not currently sure how to do that safely.
