`ContextualFailure` is the main beneficiary of additional information
associated with `ContextualType` element because it no longer has to
query solution for "purpose" of the contextual information.
Resolves: rdar://68795727
Having purpose attached to the contextual type element makes it much
easier to diagnose contextual mismatches without involving constraint
system state.
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
Restrict filtering in `simplifyAppliedOverloadsImpl` to disable
overload set for operators only, because other calls e.g. regular
functions or subscripts could be filtered on labels and are less
overloaded.
Filtering non-operator calls could also lead to incorrect diagnostics
because first choice could have all sorts of different issues e.g.
incorrect labels and number of parameters.
Resolves: rdar://55369704
If left-hand side of a conversion that requires l-value is a placeholder type,
let's fix that by propagating placeholder to the order side (to allow it to
infer a placeholder if needed) without recording a fix since placeholder can
be converted to `inout` and/or l-value and already indicates existence of a
problem at some other spot in the expression.
Resolves: rdar://76250381
It's not always clear what generic parameter type implicit conversion to pointer
is going to have, and its safer to check direct conformance in `simplifyTransitivelyConformsTo`
and let parameter handle the rest.
Performance optimization to help rule out generic overload choices sooner.
This is based on an observation of the constraint solver behavior,
consider following example:
```swift
func test<U: ExpressibleByStringLiteral>(_: U) {}
test(42)
```
Constraint System for call to `test` is going to look like this:
```
$T_test := ($T_U) -> $T_U
$T_U <conforms to> ExpressibleByStringLiteral
$T_42 <argument conversion> $T_U
$T_42 <literal conforms to> ExpressibleByIntegerLiteral
```
Currently to find out that `test` doesn't match, solver would have
to first find a binding for `$T_42`, then find a binding for `$T_U`
(through `<argument conversion>` constraint) and only later fail
while checking conformance of `Int` to `ExpressibleByStringLiteral`.
Instead of waiting for parameter to be bound, let's transfer conformance
requirements through a conversion constraint directly to an argument type,
since it has to conform to the same set of protocols as parameter to
be convertible (restrictions apply i.e. protocol composition types).
With that change it's possible to verify conformances early and reject
`test<U: ExpressibleByStringLiteral>` overload as soon as type of an
argument has been determined. This especially powerful for chained calls
because solver would only have to check as deep as first invald argument
binding.
Conformance constraints could be transferred through conversions,
but that would also require checking implicit conversions
such as optional and pointer promotions for conformance is the
type itself doesn't conform, for that let's add a special constraint
`TransitivelyConformsTo`.
I couldn't come up with an isolated test-case to add to the suite,
but it's possible that `getProtocol` returns `nullptr` for invalid
or missing protocol so there has to be a check for that otherwise
compiler is going to crash trying to access `getDeclaredType()`.
Resolves: rdar://76187450
Performance optimization.
If there is a concrete contextual type we could use, let's bind
it to the external type right away because internal type has to
be equal to that type anyway (through `BindParam` on external type
i.e. <internal> bind param <external> conv <concrete contextual>).
```swift
func test(_: ([String]) -> Void) {}
test { $0 == ["a", "b"] }
```
Without this optimization for almost all overloads of `==`
expect for one on `Equatable` and one on `Array` solver would
have to repeatedly try the same `[String]` type for `$0` and
fail, which does nothing expect hurts performance.
Resolves: rdar://19836070
Resolves: rdar://19357292
Resolves: rdar://75476311
One can convert from a function value without a global actor to a
similar function type that does have a global actor, but one cannot
remove or change a global actor on a function type.
Change the conversion rule to favor any number of widenings (CGFloat -> Double)
over even a single narrowing conversion and if there is no way to avoid narrowing
(due to contextual requirements) attempt it as late as possible (the deeper in
the AST that conversion is located the higher its score).
This is a generally better rule when it comes to rounding and information
loss that would result from narrowing conversions.
Allow Double <-> CGFloat conversion if the associated locator is
simplifiable down to a AST node (e.g. expression) this limits
applications of such conversions to e.g. argument-to-parameter,
contextual conversions and forbids conversions in generic arguments,
function result, collection elements etc.
