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.
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
Due to the fact that `matchCallArgument` can't and
doesn't take types into consideration while matching
arguments to parameters, when both arguments are
un-labeled, it's impossible to say which one is missing:
func foo(_: Int, _: String) {}
foo("")
In this case first argument is missing, but we end up with
two fixes - argument mismatch (for #1) and missing argument
(for #2), which is incorrect so it has to be handled specially.
`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.
In cases when all of the fixed solutions have only one problem in
common - different overloads of a certain operator, let's
produce a tailored diagnostic and suggest matching partial
overloads along side diagnostic notes which point to each choice.
In absence of general argument conversion failures requirement
errors associated with operators couldn't be diagnosed properly,
now this restriction could be lifted.
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.
`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
```
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.
