On 5/14/24 13:24, Andi Kleen wrote:
Hi Jason,
On Mon, May 06, 2024 at 11:02:20PM -0400, Jason Merrill wrote:
@@ -30189,7 +30207,7 @@ cp_parser_std_attribute (cp_parser *parser, tree
attr_ns)
/* Maybe we don't expect to see any arguments for this attribute. */
const attribute_spec *as
= lookup_attribute_spec (TREE_PURPOSE (attribute));
- if (as && as->max_length == 0)
+ if ((as && as->max_length == 0) || is_attribute_p ("musttail", attr_id))
I'd prefer to add an attribute to the table, rather than special-case it
here; apart from consistency, it seems likely that someone will later want
to apply it to a function.
Just to clarify. I can add it to the table, but it would be a nop there
for now because the table is not used for statement attributes by
the current parser.
Agreed.
You need a template testcase; I expect it doesn't work in templates with the
current patch. It's probably enough to copy it in tsubst_expr where we
currently propagate CALL_EXPR_OPERATOR_SYNTAX.
I tried it with the appended test case, everything seems to work without
changes.
Does it cover the cases you were concerned about?
Not fully; this testcase doesn't seem to check for errors if tail-call
fails, only whether the syntax is accepted. So it would pass if the
attribute were simply ignored.
Did you also see this comment?
It seems to me that if we were to pass &std_attrs to cp_parser_jump_statement, we could handle this entirely in that function rather than adding a flag to finish_return_stmt and check_return_stmt.
Jason
