This commit changes `getArgumentExprFor` to take
a ConstraintLocator argument from which to find
the argument list. This lets us properly handle
the case where we have a key path subscript
locator. In addition, this commit renames the
member to `getArgumentListExprFor` to make it
clear we're returning the argument list expression
rather than a single argument.
Resolves SR-11562.
Instead of materializing locator twice from the same builder per
missing argument, do it only once and use result to create argument
type variable and its "defaults to Any" constraint.
Conformance requirements get their fixes attached directly where
other requirements have to use (for now) `repairFailure` mechanism.
Regardless of _how_ fixes get recorded there should be a single
way to assess impact of a particular requirement failure.
The rules are:
- If this is a requirement associated with an operator, impact
is based on use of the type which failed the requirement;
- If this requirement is from conditional extension,
it is considered a very high impact because failing such
requirement makes referenced member de facto invisible.
Resolves: rdar://problem/55593998
Resolves: [SR-11491](https://bugs.swift.org/browse/SR-11491)
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.
