On Sun, Feb 11, 2024 at 02:54:18PM +1100, Nathaniel Shead wrote:
> Bootstrapped and regtested (so far just modules.exp and dg.exp) on
> x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
>
> (Also I noticed I forgot to add the PR to the changelog in my last
> patch, I've fixed that locally.)
>
> -- >8 --
>
> After fixing PR111710, I noticed that we currently ICE when declaring a
> type that derives from 'decltype([]{})'. As far as I can tell this
> should be legal code, since by [basic.link] p15.2 a lambda defined in a
> class-specifier should not be TU-local.
>
> This patch also adds a bunch of tests for unevaluated lambdas in other
> contexts, which generally seem to work now.
>
> One interesting case is 'E::f' in the attached testcase: it appears to
> get a merge kind of 'MK_field', rather than 'MK_keyed' as most other
> lambdas do. I'm not entirely sure if this will cause issues in the
> future, but I haven't been able to construct a testcase that causes
> problems with this, and conversely wrapping the class body in
> 'start_lambda_scope' causes issues with symbol duplication in COMDAT
> groups, so I've left it as-is for now.
Hi Nathaniel,
> gcc/cp/ChangeLog:
>
> * module.cc (trees_out::key_mergeable): Also support TYPE_DECLs.
> (maybe_key_decl): Likewise.
> * parser.cc (cp_parser_class_head): Start a lambda scope when
> parsing base classes.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/modules/lambda-7_a.C:
> * g++.dg/modules/lambda-7_b.C:
sorry to be pointing out nits, but this CL entry is missing a description.
No need to repost the patch because of that, of couse.
Marek
