On 8/5/24 2:44 PM, Marek Polacek wrote:
On Mon, Aug 05, 2024 at 12:00:04PM -0400, Jason Merrill wrote:
I think we also want to adjust the 'concept bool' handling in
cp_parser_decl_specifier_seq:
/* Warn for concept as a decl-specifier. We'll rewrite these
as
concept declarations later. */
{
cp_token *next = cp_lexer_peek_token (parser->lexer);
if (next->keyword == RID_BOOL)
=> permerror (next->location, "the %<bool%> keyword is not "
"allowed in a C++20 concept definition");
else
error_at (token->location, "C++20 concept definition syntax "
"is %<concept <name> = <expr>%>");
}
After the permerror let's skip the 'bool' token and continue trying to parse
a concept declaration. I think that should allow us to remove more of the
code in grokfndecl/grokvardecl?
If by skip you mean cp_lexer_consume_token, then that results in worse
diagnostics for e.g.
concept bool f3();
where it adds the extra "with no type" error:
Ah, yeah, cp_parser_decl_specifier_seq is too late for what I was
thinking. How about in cp_parser_template_declaration_after_parameters:
else if (flag_concepts
&& cp_lexer_next_token_is_keyword (parser->lexer, RID_CONCEPT)
&& cp_lexer_nth_token_is (parser->lexer, 2, CPP_NAME))
/* -fconcept-ts 'concept bool' syntax is handled below, in
cp_parser_single_declaration. */
decl = cp_parser_concept_definition (parser);
What happens if we remove the CPP_NAME check, so we commit to concept
parsing as soon as we see the keyword?
Jason
