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.
Instead, check them and their error handling right away.
In addition to fixing the crash in the radar, this also causes
us to emit unused variable warnings in functions containing
local functions.
Eventually, TC.definedFunctions should go away altogether.
Fixes <rdar://problem/53956342>.
If a syntax sugared type like Array had an unresolved type, it used to print as `[_]` in diagnostics, which could be confusing.
Instead, desugar these unresolved types before printing, so Array, for example, prints as `Array<_>`.
Currently this only applies to Array, Dictionary, and Optional.
Currently only valid way to form keypath subscript is to use `keyPath:`
label in subscript invocation, so let's avoid adding keypath overload
choice to every subscript lookup and instead only add it when it could
potentially match.
This among other things greatly helps diagnostics because sometimes
`keypath application` becomes the only choice even although it's
not really viable, which impedes member reference diagnostics.
This improves the diagnostic for trailing closures in statement conditions to catch cases where one or more trailing closures are used in a chain composed of multiple calls
Sema does not have enough information to diagnose these problems correctly.
Also, there was an unimplemented case in the analysis; if a closure did not
yet have computed captures, we'd add it to the ForwardCapturedFuncs list,
but nothing ever looked at that list.
Introduce a fix to detect and diagnose situations when omitted
generic arguments couldn't be deduced by the solver based on
the enclosing context.
Example:
```swift
struct S<T> {
}
_ = S() // There is not enough context to deduce `T`
```
Resolves: rdar://problem/51203824
Detect and diagnose a contextual mismatch between expected
collection element type and the one provided (e.g. source
of the assignment or argument to a call) e.g.:
```swift
let _: [Int] = ["hello"]
func foo(_: [Int]) {}
foo(["hello"])
```
We don't require or allow '&' for the mutable parameters in
operator calls, since we want to write 'x += 10' and not
'&x += 10'.
The constraint sovler accepted '&x += 10' though, and we had
a separate pass in MiscDiagnostics for rejecting it.
Instead, let's just reject this in the solver.
The main difficulty is that we must now be prepared to fail
certain OperatorArgumentConversion and ApplicableFunction
constraints even when both the LHS and RHS types are equal.
Enhance call-argument matching to reject trailing closures that match up
with parameters that cannot accept closures at all.
Fixes rdar://problem/50362170.
Detect situations where key path doesn't have capability required
by the context e.g. read-only vs. writable, or either root or value
types are incorrect e.g.
```swift
struct S { let foo: Int }
let _: WritableKeyPath<S, Int> = \.foo
```
Here context requires a writable key path but `foo` property is
read-only.
Currently `getPotentialBindingsForRelationalConstraint` doesn't
respect the fact that type of key path expression has to be a
form of `KeyPath`, instead it could eagerly try to bind it to
`Any` or other contextual type if it's only available
information.
This patch aims to fix this situation by filtering potential
bindings available for type variable representing type of
the key path expression.
Resolves: SR-10467
