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
```
Note that in all cases it was either nullptr or ctx.getLazyResolver().
While passing in nullptr might appear at first glance to mean something
("don't type check anything"), in practice we would check for a nullptr
value and pull out ctx.getLazyResolver() instead. Furthermore, with
the lazy resolver going away (at least for resolveDeclSignature() calls),
it won't make sense to do that anymore anyway.
Since this kind of failure is really a conversion failure, let's
inherit from `Contextual{Mismatch, Failure}` which also helps with
storage for from/to types and their resolution.
Also let's use original types involved in conversion to form
this fix, which helps to perserve all of the original sugar.
This commit replaces the `getValue()` and `getValue2()` members on
`ConstraintLocator::PathElement` with specific accessors for each
expected path component kind. IMO this adds some clarity to the call
sites, especially for `getArgIdx()` and `getParamIdx()`.
In addition, this commit adds a private `getValue` member that can
access a value at a given index, which will make it easier to add a
third value in the future.
Previously in situations like:
```swift
protocol P {}
struct S<T: P> {
var value: T
}
_ = S(value: 42)
```
Diagnostic has reported a problem as related to "reference" to `init`
but the failing generic type requirement belongs to `S`, so a
better diagnostic in such case should mention `generic struct S`.
Make `InvalidUseOfAddressOf` a `ContextualFailure`, make `ReturnAddressOf`
a `ContextualMismatch`, and extend this failure to cover using `&` with a
non-inout argument.
If the only difference between two functions is `throws` and it
is not a subtype relationship, let's repair the problem by dropping
`throws` attribute and letting solver continue to search for
a solution, which would later be diagnosed.
If contextual failure is detected in sub-expression (through
type-check call via CSDiag), let's make sure that fix-it
is always anchored at semantic expression otherwise it could be
attached to the paren representing whole argument list.
