Identify problems like:
```swift
func foo(_ x: Int, _ y: String) {}
func bar(a: Int, b: String) {
foo(b, a) // Instead of `foo(a, b)`
}
```
Where arguments are out-of-order and repair it by using OoO fix on the
parent locator.
Just like in cases where both sides are dependent member types
with resolved base that can't be simplified to a concrete type
let's ignore this mismatch and mark affected type variable as a hole
because something else has to be fixed already for this to happen.
When there is a conversion from e.g. `(A) -> Void` to `(B) -> Void`
matching between `A` and `B` is going to have a special locator which
doesn't end in `TupleElement`, so `repairFailures` has to account
for that and fix it just like regular argument mismatch.
Resolves: rdar://problem/59066040
Prioritize type mismatches over conformance failures when stdlib
types are involved because it wouldn't be appropriate to suggest
to add such a conformance, so the problem is most likely related
to something else e.g. other overload choice has a better fix.
Consider following example:
```swift
struct S {
init(_: Double) {}
init<T: BinaryInteger>(_: T) {}
}
_ = S(Double("0"))
```
In cases like that it's better to prefer failable initializer
which takes a `String` and returns `Double?` and diagnose a
problem related to missing optional unwrap instead of missing
conformances related to a `String` argument of other `Double`
initializer just because it returns a concrete type.
Since `simplifyRestrictedConstraintImpl` has both parent types and
does nested type matching it's a good place to diagnose top-level
contextual problems like mismatches in underlying types of optionals.
If parameter type is optional let's ignore that since argument could
be either optional itself or be injected into optional implicitly.
```swift
func foo(_: ((Int, Int) -> Void)!) {}
foo { _ in } // Missing second closure parameter
```
This helps to diagnose contextual mismatches like `Int? vs. Bool`
instead of suggesting to unwrap the optional which would still
produce an incorrect type.
Delay "fixing" contextual conversion failures until restriction is applied
this helps to tidy up logic for superclass and existential conversions.
Too bad we have to "fix" in `simplifyRestrictedConstraintImpl` now but
we can't really do much about that because diagnostics need both top-level
types to be useful.
Since opening closure body is now delayed until contextual type becomes
available it's possible to infer anonymous parameters as being variadic
based on context and propagate that information down to the closure body.
Resolves: rdar://problem/41416758
Fix a few related issues involving the interaction with
single-expression closures:
* A single-expression closure can have a "return" in it; in such
cases, disable the function-builder transform.
* Have the function builder constraint generator look through the
"return" statement in a single-expression closure the same way as
solution application does
Fixes rdar://problem/59045763, where we rejected some well-formed code
involving a single-expression closure with a "return" keyword.
If there are any requirement failures associated with result types
which are part of a function type conversion, let's record general
conversion mismatch in order for it to capture and display complete
function types.
Originally type mismatches associated with conversions between
function types were only covered for coercions and assignments
but fix coverage grew since then and now it makes sense
to remove special case and let `repairFailures` take care of it.
Originally type mismatches associated with metatypes were only covered
for coercions but fix coverage grew since then and now it makes sense
to remove special case and let `repairFailures` take care of it.
Stop filtering outer overload choices while trying to pre-check
expression, instead have it always fetch those and use new
fix to only attempt them in diagnostic mode (unless it's min/max
situation with conditional conformances).
where the base does not conform to the associated type's protocol.
We can only reach this case when the solver has already applied a fix for
the conformance failure.
If a type variable representing "function type" is a hole
or it could be bound to some concrete type with a help of
a fix, let's propagate holes to the "input" type. Doing so
provides more information to upcoming argument and result matching.
If type variable is allowed to be a hole and it can't be bound to
this particular (full resolved) type, just ignore this binding
instead of re-trying it later.
SolutionResult better captures what can happen when solving a constraint
system for the given expression occurs than the ad hoc SolutionKind return
& small vector of Solution results. Also, try to make this logic less
convoluted.
When requesting information about the contextual type of a constraint
system, do so using a given expression rather than treating it like
the global state that it is.
Delayed constraint generation for the body of the single-statement
closures regressed variadic parameter handling. Fix it by using
`FunctionType::Param::getParameterType` for "internal" version of
the parameter type which translates variadic/inout correctly.
Resolved: rdar://problem/58647769
Attempt to infer a closure type based on its parameters and body
and put it aside until contextual type becomes available or it
has been determined that there is no context.
Once all appropriate conditions are met, generate constraints for
the body of the closure and bind it the previously inferred type.
Doing so makes it possible to pass single-statement closures as
an argument to a function builder parameter.
Resolves: SR-11628
Resolves: rdar://problem/56340587
While resolving closure use contextual locator information to
determine whether given contextual type comes from a "function builder"
parameter and if so, use special `applyFunctionBuilder` to open
closure body instead of regular constraint generation.
