On 1/22/24 13:11, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13?
-- >8 --
Here we handle the operator expression u < v inconsistently: in a SFINAE
context (such as a requires-expression) we accept the it, and in a
non-SFINAE context we reject it with
error: request for member 'operator<=>' is ambiguous
as per [class.member.lookup]/6. This inconsistency is ultimately
because we neglect to propagate error_mark_node after recursing in
add_operator_candidates, fixed like so.
Shouldn't we do the same with the other recursive call?
Please also add return value documentation to the comment before the
function.
OK with those changes.
Jason
