On 11/30/25 6:02 AM, Egas Ribeiro wrote:
On 2025-11-29 15:30, Jason Merrill wrote:
Once we enter cp_parser_placeholder_type_specifier with
parser->auto_is_implicit_function_template_parm_p we know we're dealing with
an abbreviated function template, no need to wait until we actually see the
'auto'.
In the meantime I think it'd be good to document in tsubst_expr that
TARGET_EXPR is deliberately not handled since it's not a valid templated
tree.
Indeed. Perhaps with a separate gcc_unreachable case.
Thanks for the input Jason!
I tried this in cp_parser_simple_type_specifier but the lambda still
becomes a TARGET_EXPR:
+ if (parser->auto_is_implicit_function_template_parm_p)
+ ++processing_template_decl;
cp_parser_parse_tentatively (parser);
type = cp_parser_template_id (parser,
/*template_keyword_p=*/false,
/*check_dependency_p=*/true,
none_type,
/*is_declaration=*/false);
+ if (parser->auto_is_implicit_function_template_parm_p)
+ --processing_template_decl;
Additionally, when cp_parser_placeholder_type_specifier receives the
TEMPLATE_ID_EXPR, it already contains the semantic TARGET_EXPR tree.
I looked around for alternative fixes, but I'm not sure how to force the
lambda to be parsed as a syntactic tree, or how to convert the current
TARGET_EXPR tree into a syntactic form.
Any suggestions on the right approach?
Ah, right, we parse it in the cp_parser_template_id call in
cp_parser_simple_type_specifier. So we'd need to enter template scope
as soon as cp_parser_template_name in cp_parser_template_id finds a
concept-name. And from there it's not clear where we could put a
matching --ptd. I guess we need to split the creation of
parser->implicit_template_scope out of synthesize_implicit_template_parm
so we can create that scope before we are ready to actually add a parm
to it.
Jason
