Neither direct protocol conformance checking nor `checkRequirements`
verifies that produced conformance is available. The optimizer shouldn't
be favoring overload choices that would result in use of unavailable
conformances (just like it doesn't for unavailable declarations).
Resolves: rdar://175981146
This change restores pre-6.3 operator overload selection behavior.
The same is done for cases when candidate matches all of the requirements
placed on the generic parameter and optional injections because operators
historically favored exact/subtype matches in concrete overloads above all
else.
If a disjunction has zero or one choices remaining, there's nothing
to lose by attempting it. This will become a more common occurrence
once disjunction pruning is enabled.
In 7bcbe1b3f0, I forgot to scale the
value by 100 in one place. This wasn't caught by our test suite,
but it regressed the new test case I'm adding. We would select the
UnicodeScalar.init() overload taking an UInt8, and complain that
the scalar doesn't fit.
I'm uncomfortable with the use of floating point arithmetic here.
Even though this is a performance heuristic, it actually impacts
solver behavior because of how choice favoring works, and because
disjunction selection order indirectly affects other broken solver
behaviors.
The constants used, like 0.01, 0.1, 0.7, etc. are not exactly
representable, so when they get added up the result might differ
from the "actual" result by a small amount.
Because of that, we don't want any "load bearing" behaviors where
someone's expression type checks quickly or in a certain way because
of pecularities of floating point arithmetic.
Instead, scale everything up by a factor of 100 and use integers.
The firstScore and secondScore bindings were references, so the
assignments to those were mutating the DenseMap unintentionally.
Refactor this code a bit, we don't want to just change the
bindings to rvalues because then we would copy the FavoredChoices
vector, so instead bind a const reference to the DisjunctionInfo
and dereference its fields instead.
The existing check is no-op because it would never produce a null for
`paramType` under the conditions in `else` branch. A better
API it use here is `conformsToKnownProtocol` just like in other cases.
`??` operator is overloaded on optionality of its result. When the
first argument matches exactly, the ranking is going to be skewed
towards selecting an overload choice that returns a non-optional type.
This is not always correct i.e. when operator is involved in optional
chaining. To avoid producing an incorrect favoring, let's skip the this
disjunction when constraints associated with result type indicate
that it should be optional.
Simply adding it as a binding won't work because if the second argument
is non-optional the overload that returns `T?` would still have a lower
score.
Resolves: rdar://164201746
This is a fix for the ported "calls with a single unlabeled argument"
hack. If overload doesn't match context on async effect, let's not favor
it because that is more important than defaulted parameters.
Resolves: rdar://164269641
Update special favoring logic for unlabeled unary calls to support
non-overloads member references in argument positions.
The original hack missed a case where a type of a member is known
in advance (i.e. a property without overloads) because there as
another hack (shrink) for that.
This helps in situations like `Double(x)` where `x` is a property
of some type that is referenced using an implicit `self.` injected
by the compiler.
Resolves: rdar://161419917
This type is only intended for pattern matching against `nil`
and the solver shouldn't early attempt to infer this type for
`nil` for arguments of `==` and `!=` operators it should instead
be inferred from other argument or result.
Resolves: rdar://158063151
Pavel Yaskevich
Slava Pestov
elsa
Hamish Knight
Pavel Yaskevich
Clack Cole