On Tue, 23 Jan 2024, Jason Merrill wrote:
> 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?
Oops, yes. I thought that the function is symmetric with respect to
member lookup so it should suffice to check the first recursive call,
but member lookup is only performed for the first argument type, and
arguments are swapped for the second recursive call.
>
> Please also add return value documentation to the comment before the function.
Will do, thanks!
>
> OK with those changes.
>
> Jason
>
>
