Disable non-Optional "assumption" warning for ambiguities related to a
static member lookup in generic context because it's possible to declare
a member with the same name on a concrete type and in an extension of a
protocol that type conforms to e.g.:
```swift
struct S : P { static var test: S { ... }
extension P where Self == S { static var test: { ... } }
```
And use that in an optional context e.g. passing `.test`
to a parameter of expecting `S?`.
Resolves: rdar://77700261
Not all of the pre-check errors could be diagnosed by re-running
`PreCheckExpression` e.g. key path expressions are mutated to
a particular form after an error has been produced.
To make the behavior consistent, let's allow pre-check to emit
diagnostics and unify pre-check and constraint generation fixes.
Resolves: rdar://77466241
A type representing a closure expression is always bound to its
"inferred" type based on the body, so contextual bindings just
serve as a trigger to "resolve" a closure. Let's not attempt any
subtype/supertype inference for a type variable representing a
closure since if "direct" bindings have failed, it wouldn't be bound
to such types regardless.
Resolves: rdar://problem/77022842
When `nil` is passed as an argument to call with multiple overloads
it's possible that this would result in ambiguity where matched
expected argument type doesn't conform to `ExpressibleByNilLiteral`.
To handle situations like this locator for contextual mismatch
has to be adjusted to point to the call where `nil` is used, so
`diagnoseAmbiguityWithFixes` can identify multiple overloads and
produce a correct ambiguity diagnostic.
Resolves: rdar://75514153
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
Restrict filtering in `simplifyAppliedOverloadsImpl` to disable
overload set for operators only, because other calls e.g. regular
functions or subscripts could be filtered on labels and are less
overloaded.
Filtering non-operator calls could also lead to incorrect diagnostics
because first choice could have all sorts of different issues e.g.
incorrect labels and number of parameters.
Resolves: rdar://55369704
If left-hand side of a conversion that requires l-value is a placeholder type,
let's fix that by propagating placeholder to the order side (to allow it to
infer a placeholder if needed) without recording a fix since placeholder can
be converted to `inout` and/or l-value and already indicates existence of a
problem at some other spot in the expression.
Resolves: rdar://76250381
We assume that presence of `ErrorExpr` means that the problem has
been diagnosed early (i.e. by parser), so the fix is going to return
`true` if diagnostic engine has emitted an error.
Resolves: rdar://76246526
If there is a contextual mismatch associated with a closure body,
make sure that the diagnostic is attached to the closure even
if the body is empty or implicit.
Resolves: rdar://52204608
Performance optimization.
If there is a concrete contextual type we could use, let's bind
it to the external type right away because internal type has to
be equal to that type anyway (through `BindParam` on external type
i.e. <internal> bind param <external> conv <concrete contextual>).
```swift
func test(_: ([String]) -> Void) {}
test { $0 == ["a", "b"] }
```
Without this optimization for almost all overloads of `==`
expect for one on `Equatable` and one on `Array` solver would
have to repeatedly try the same `[String]` type for `$0` and
fail, which does nothing expect hurts performance.
Resolves: rdar://19836070
Resolves: rdar://19357292
Resolves: rdar://75476311
If closure parameter has an explicit type, type resolution
would diagnose the issue and cache the resulting error type for
future use. Invalid types currently fail constraint generation,
which doesn't play well with result builders because constraint
generation for their bodies happens during solving.
Let's handle invalid parameters gracefully, replace them with
placeholders and let constraint generation proceed.
Resolves: rdar://75409111
