This saves us from needing to re-match args to params in CSApply and is also
useful for a forthcoming change migrating code completion in argument position
to use the solver-based typeCheckForCodeCompletion api.
rdar://76581093
Just like generic overloads, `shrink` should always avoid any solutions
with implicit conversions.
Reducing disjunction domains becaused on solutions with implicit
conversions could have negative performance impact due to the
increase in total number of solutions that have to be examined
as a result.
Not all of the unary operators have `CGFloat` overloads,
so in order to preserve previous behavior (and overall
best solution) with implicit Double<->CGFloat conversion
we need to allow attempting generic operators for such cases.
```swift
let _: CGFloat = -.pi / 2
```
`-` doesn't have `CGFloat` overload (which might be an oversight),
so in order to preserve type-checking behavior solver can't be
allowed to pick `-(Double) -> Double` based on overload of `/`,
the best possible solution would be with `/` as `(CGFloat, CGFloat) -> CGFloat`
and `-` on a `FloatingPoint` protocol.
for arithmetic operators.
Only sort overloads that are related, e.g. Sequence
overloads. Further, choose which generic overloads
to attempt first based on whether any known argument types
conform to one of the standard arithmetic protocols.
attempt the most specific choices first. Then, if the solver finds
a solution with one choice, it can skip any subsequent choices that
can be unconditionally used in place of the successful chioce and produce
the same solution.
Doing so streamlines access to the information associated with literal
protocol requirements and allows to add more helpers.
Also cache default type in the struct itself for easy access.
As a step towards making binding inference more incremental, let's
make producer responsible for adding hole type binding instead of
doing so in `finalize`.
Replaces `InvolvesTypeVariables` flag with a set of adjacent type
variables found during binding inference.
This approach is more suitable for incremental binding computation
because it allows to maintain a list of type variables that affect
ranking and check whether something has been resolved without having
to re-evaluate constraints associated with the given type variable.
Instead of exposing archetypes during solution generation, let's
do that based on solution data when a type of code completion
expression is requested by code completion callback.
This fallback to `typeCheckExpression` is triggered when it's
determined that code completion expression is located inside
of a multi-statement closure and its body is going going to
participate in type-check.
Using `SolutionApplicationTarget` make it easier to propage
contextual information and avoid mistakes of using incorrect
accessors for constraint generation.
