In situations like:
```swift
func foo<T>(x: T) {}
foo(a; 0, x: 42)
```
Let's not try to fix call to `foo` as a tuple splat because match is
in a middle of the argument list, it should be considered a regular
extraneous argument instead.
If there are more arguments than parameters, let's fix this by
ignoring (if possible) or removing extraneous arguments. Ignored
arguments could default to `Any` if they don't get any other
contextual type.
Currently single parameter tuple splat fix/diagnostic supports only
cases where parameter is a concrete tuple type, let's enhance that to
support generic parameters as well e.g.:
```swift
func foo<T>(_: T) {}
foo(0, 1, 2) // `T` expects arguments to form a tuple e.g. `foo((0, 1, 2))`
```
Introduce a fix/diagnostic when there is a contextual mismatch
between source and destination types of the assignment e.g.:
```swift
var x: Int = 0
x = 4.0 // destination expects an `Int`, but source is a `Double`
```
Instead of storing contextual function type in the fix/diagnostic,
let's fetch it from context (solution and/or locator) because it's
only used when it is a trailing closure missing some arguments anyway.
If there is an argument-to-parameter conversion which is associated with
`inout` parameter, subtyping is now permitted, types have to be identical.
```swift
protocol P {}
struct S : P {}
func foo(_: inout P) {}
var s = S()
foo(&s) // `s` has to be defined as `P` e.g. `var s: P = S()`
// to be used as an argument to `inout P` parameter.
```
Since this kind of failure is really a conversion failure, let's
inherit from `Contextual{Mismatch, Failure}` which also helps with
storage for from/to types and their resolution.
Also let's use original types involved in conversion to form
this fix, which helps to perserve all of the original sugar.
Make `InvalidUseOfAddressOf` a `ContextualFailure`, make `ReturnAddressOf`
a `ContextualMismatch`, and extend this failure to cover using `&` with a
non-inout argument.
If the only difference between two functions is `throws` and it
is not a subtype relationship, let's repair the problem by dropping
`throws` attribute and letting solver continue to search for
a solution, which would later be diagnosed.
This way it covers a lot more ground and doesn't conflict with
other fixes.
Another notable change is related to check for IUO associated
with source type, that covers cases like:
```swift
func foo(_ v: NSString!) -> String {
return v
}
```
Instead of general conversion failure check for IUO enables solver
to introduce force downcast fix.
Add constraint fix `AllowAutoClosurePointerConversion` and corresponding diagnostic
`AutoClosurePointerConversionFailure`. When we discover that we're trying to do an
inout-to-pointer conversion in `matchTypes`, add the constraint fix, which tries to do the
conversion as if the pointer type is a regular function argument.
Instead of keeping two locators in the fix let's store only the
original locator and simplify it later in process of emitting
a diagnostic. That helps to avoid some duplicate work as well
as makes sure that locators supplied to the diagnostic always
have an anchor.
Resolves: rdar://problem/53344815
Diagnose situation when a single "tuple" parameter is given N arguments e.g.
```swift
func foo<T>(_ x: (T, Bool)) {}
foo(1, false) // foo exptects a single argument of tuple type `(1, false)`
```
