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.
This lets us add a constraint to the system with an associated fix.
Unlike `addUnsolvedConstraint`, this will attempt to immediately
simplify the constraint, producing an unsolved constraint if necessary.
Array-to-pointer should only be used for such conversions. This isn't
currently an issue as we short-circuit disjunctions upon successfully
solving an array-to-pointer conversion. However this would become an
issue if only inout-to-pointer was viable.
We would previously consider the VarDecls bound by a particular pattern
binding initializer context when performing overload resolution. This
would lead to circular validation. Validation was tacitly breaking the
cycle by returning an error type (but, crucially, not setting that
interface type). Instead, pre-reject circular candidates.
This greatly improves the diagnostic we emit here in truly circular
cases since we can ride on `UR_InstanceMemberOnType` to yield
struct PatternBindingWithTwoVars2 { var x = y, y = 3 }
// cannot use instance member 'y' within property initializer; property initializers run before 'self' is available
Currently absence of `subtyping` is the only problem detected and diagnosed specifically
for `inout` parameters, but there could be type mismatches in `inout` positions as well
and we can use `argument-to-parameter mismatch fix to detect and diagnose them.
When it comes to `@autoclosure` parameters we only detect and diagnose
mismatches related to invalid implicit conversions to pointer types. But
`@autoclosure` parameters just like regular ones can have type mismatches
as well which can be handled via recently introduced
`argument-to-parameter mismatch` fix.
In some situations where both the KeyPath and closure solutions for an expression with a keypath literal were valid, the type checker could not choose between them and Swift would emit an “ambiguous use” error. This change increase the typechecking score of the closure solution so that the typechecker will favor the KeyPath solution, preserving source compatibility for existing APIs.
Fixes rdar://problem/56131416.
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
```
