| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 1f3f8c369a5067a132c871f33a955a7feaea8534)
|
