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.
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.
Add constraint fix `AllowAutoClosurePointerConversion` and corresponding diagnostic
`AutoClosurePointerConversionFailure`. When we discover that we're trying to do an
inout-to-pointer conversion in `matchTypes`, add the constraint fix, which tries to do the
conversion as if the pointer type is a regular function argument.
Since all of the specific diagnostics which constitute requirement
failure now operate on types, their interfaces could be simplified
and associated requirement types could be stored in RequirementFailure.
Each candidate with incorrect labels (but everything else lined up)
gets a note on its declarationm which says what is expected and what
has been given.
Diagnose situation when a single "tuple" parameter is given N arguments e.g.
```swift
func foo<T>(_ x: (T, Bool)) {}
foo(1, false) // foo exptects a single argument of tuple type `(1, false)`
```
Additionally, refactor some of the logic for the original add $ diagnostic
so that a lot of logic can be shared between the two. Also rename the
original fix and diagnostic to better reflect their purpose.
