On 7/7/26 6:16 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/16?
-- >8 --
We trip on the assert in lvalue_kind/MODOP_EXPR whose comment says
that we expect to see MODOP_EXPRs only during template processing.
In this test we get there with processing_template_decl==0. The
MODOP_EXPR is created in:
/* Parse the requirement body. */
++processing_template_decl;
reqs = cp_parser_requirement_body (parser);
--processing_template_decl;
but we're not in a template when calling maybe_convert_cond which
calls verify_sequence_points which ends up calling lvalue_p on
the MODOP_EXPR. verify_sequence_points is a c-family/ function
so we couldn't make it stop recursing on REQUIRES_EXPR, so I suppose
we can do the following.
Eh, this just looks like a workaround for a single testcase.
I see several problems here:
1) We're retaining template trees in a non-template function,
2) verify_sequence_points is walking the unevaluated operand of a
requires because verify_tree assumes that all unknown expressions are
evaluated, and
3) REQURES_EXPR looks like a normal expression (tcc_expression).
I think the right way to approach this would be to attack 3 by changing
REQUIRES_EXPR to tcc_exceptional. Then 1 doesn't matter because the
generic code (such as verify_tree) sees that it's magic and doesn't try
to walk into it.
We could also attack 2 by defining unevaluated_p in the C front-end as
well, and checking it in verify_tree. 2 also affects other unevaluated
codes like NOEXCEPT_EXPR, potentially leading to wrong -Wsequence-point
results.
Jason
