PR44721: Don't consider overloaded operators for built-in comparisons
when building a defaulted comparison. As a convenient way of asking whether `x @ y` is valid and building it, we previouly always performed overload resolution and built an overloaded expression, which would both end up picking a builtin operator candidate when given a non-overloadable type. But that's not quite right, because it can result in our finding a user-declared operator overload, which we should never do when applying operators non-overloadable types. Handle this more correctly: skip overload resolution when building `x @ y` if the operands are not overloadable. But still perform overload resolution (considering only builtin candidates) when checking validity, as we don't have any other good way to ask whether a binary operator expression would be valid. (cherry picked from commit 1f3f8c36)
Loading
Please register or sign in to comment