https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103901
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |jason at gcc dot gnu.org,
| |ppalka at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If it is valid, I think e.g.
--- gcc/cp/parser.c.jj 2022-01-04 09:59:37.297641779 +0100
+++ gcc/cp/parser.c 2022-01-04 20:56:19.065070397 +0100
@@ -11046,6 +11046,9 @@ cp_parser_lambda_expression (cp_parser*
bool save_in_consteval_if_p = in_consteval_if_p;
in_consteval_if_p = false;
+ int saved_processing_template_parmlist = processing_template_parmlist;
+ processing_template_parmlist = 0;
+
/* By virtue of defining a local class, a lambda expression has access to
the private variables of enclosing classes. */
@@ -11078,6 +11081,7 @@ cp_parser_lambda_expression (cp_parser*
in_consteval_if_p = save_in_consteval_if_p;
in_discarded_stmt = discarded;
+ processing_template_parmlist = saved_processing_template_parmlist;
parser->num_template_parameter_lists = saved_num_template_parameter_lists;
parser->in_statement = in_statement;
should fix that. But as the stack-overflow link says, it is unclear.
Also, we still reject even with the above patch
decltype ([]{ struct A {} ; return 1; }) a;
(guess that is PR101911).
