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.
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.
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.
Example:
```swift
func foo(_ x: UnsafePointer<Int>) {}
var arr: [Float] = [0, 1, 2]
foo(&arr) // Cannot convert [Float] to UnsafePointer<Int> because of Float vs. Int
```
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.
Currently we only produce a fix if function type doesn't have any
parameters, but it should also account for function having defaults
for all of its parameters which would still allow for nullary call.
Instead of keeping two locators in the fix let's store only the
original locator and simplify it later in process of emitting
a diagnostic. That helps to avoid some duplicate work as well
as makes sure that locators supplied to the diagnostic always
have an anchor.
Resolves: rdar://problem/53344815
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.
