Now that the generic signature is computable on demand, this predicate is doubly useless. All of the callers intended to ask "hasInterfaceType" anyways.
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`
```
Expand tuple into N arguments to cover expect parameters.
This covers cases like this:
```swift
func foo(_: (Int, Int) -> Void) {}
foo { (bar: (Int, Int)) in } // used a single tuple type `(Int, Int)`
// instead of two distinct arguments
```
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.
Impact is higher if the base is expected to be inferred from context,
because a failure to find a member ultimately means that base type is
not a match in this case.
This allows better diagnostics in cases where collection element
is a generic parameter which is supposed to be inferred from argument e.g.
```swift
func foo<T>(_: [T]) {}
foo(1) // Missing brackets, so error should be about [Int] vs. Int
```
Some spots of constraint simplification logic are too eager to
fail right away without giving repair logic to run in diagnostic
mode and attempt to fix the problem. Failing early in diagnostic
mode means solver wouldn't be able to reach some possible
solutions which leads to subpar diagnostics.
Currently in cases where dependent member types cannot be resolved
properly due to invalid base type they do not fail comparison, but
instead result in a new "inactive" constraint which is incorrect.
In absence of general argument conversion failures requirement
errors associated with operators couldn't be diagnosed properly,
now this restriction could be lifted.
Impact of conformance failure should be rated based on use of
associated generic parameter, because a single failure could
span multiple parameters and a result.
Originally score was only increased once for conformance failure.
That is not good enough in cases when conformance is associated
with an overload choice, because in that case we can have an argument
mismatch in other choice which would have the same score impact.
There is logic in `matchTypes` which would unwrap l-value if other
type is not an `inout`, which is not great for cases where parameter
type is a pointer and argument is an l-value which requires explicit
`&` to be converted.
This removes all calls to typesSatisfyConstraint() except for the
isConvertibleTo() check at the beginning, in the process making the
analysis a little bit more accurate.
Now that we associate argument labels for key path
subscript components, remove the special logic for
it. In addition, we can now search for callees
directly by using `getCalleeLocator`, as it should
now be able to find all the correct callees that
`getCalleeDeclAndArgs` does.
By using `getCalleeLocator`, we now also correctly
resolve callees for operator calls, meaning that
we can now use them with function builders. In
addition, we no longer incorrectly resolve callees
for calls made on SubscriptExprs.
Resolves SR-11439 & SR-11440.
mismatches in function types.
This improves the diagnostic in cases where we have argument-to-parameter
conversion failures or contextual type mismatches due to inout attribute
mismatches.
This makes it possible to diagnose all implicit pointer
conversions in argument positions with a better error
message which preserves enclosing types, and allows to
share base type matching logic across all pointer conversions.
This helps us to filter out cases like operator overloads where
`Self` type comes from e.g. default for collection element -
`[1, "hello"].map { $0 + 1 }`. Main problem here is that
collection type couldn't be determined without unification to
`Any` and `+` failing for all numeric overloads is just a consequence.
