`MissingArgumentsFailure::diagnoseClosure` can actually diagnose both
closures in argument positions as well as when their type comes from
context e.g. `let _: (Int) -> Void = {}`.
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.
If missing conformance is between two stdlib defined types which
are used in operator invocation, let's produce a generic diagnostic
about operator reference and a note about missing conformance.
If expression is incorrect it most likely wouldn't be able to satisfy
`Equatable` or other requirements of `~=` operator overloads, but
at the same time the main problem is related to `case` expression
itself so let's not diagnose missing conformances.
In absence of general argument conversion failures requirement
errors associated with operators couldn't be diagnosed properly,
now this restriction could be lifted.
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.
Have FailureDiagnostic::getChoiceFor take a ConstraintLocator argument
which is passed through to getAnchormostCalleeLocator, and rename to
getAnchormostChoiceFor to make the semantics clear. In addition, add
a convenience getAnchormostChoice member for the common case of getting
the choice for the anchor of the failure's locator.
This change means we can now resolve callees for failures associated
with key path subscript components.
Resolves SR-11435.
In order to do this we need it to take a ConstraintLocator argument so
we can tell which component we want the callee for. To make it clear
that we're looking for a callee at the anchor, also rename the member
to getAnchormostCalleeLocator.
Given we can now find overloads for applies of optional functions,
adjust the logic so we look at the call's direct callee. In addition,
tweak the logic so we don't assert on a ForceTryExpr.
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.
These are defined with macros like errors/warnings/notes, and
make use of format strings and diagnostic arguments. The intent
is to leverage diagnostic arguments in the future to disambiguate
ambiguously spelled types.
Ported a few miscellaneous fix-its to the new system
`throw` statements are type-checked as having contextual `Error`
type to make sure that thrown type conforms to `Error` protocol.
Let's make sure that's correctly handled by new diagnostics framework.
```swift
func foo() throws {
throw 0 // `Int` doesn't conform to `Error` protocol.
}
```
Detect and diagnose contextual failures originating in an attempt
to convert `nil` to some other non-optional type e.g.
```swift
let _: Int = nil // can't initialize `Int` with `nil`
func foo() -> Int {
return nil // can't return `nil` from `foo`
}
_ = 1 + nil // there is no `+` overload which accepts `Int` and optional
```
