It might be either impossible to infer the base because there is
no contextual information e.g. `_ = .foo` or there is something
else wrong in the expression which disconnects member reference
from its context.
Argument-to-Parameter mismatch handles conformance failures
related to arguments, so the logic in `MissingConformanceFailure`
which wasn't entirely correct is now completely obsolete.
Resolves: rdar://problem/56234611
A "hole" is a type variable which type couldn't be determined
due to an inference failure e.g. missing member, ambiguous generic
parameter which hasn't been explicitly specified.
It is used to propagate information about failures and avoid
recording fixes which are a consequence of earlier failures e.g.
```swift
func foo<T: BinaryInteger>(_: T) {}
struct S {}
foo(S.bar) // Actual failure here is that `S` doesn't have a member
// `bar` but a consequence of that failure is that generic
// parameter `T` doesn't conform to `BinaryInteger`.
```
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`.
When diagnosing ApplyExpr, the existing implementation
tries to resolve the function subexpression independently
in the first place, without considering the argument
information. As a result, such resolved function type
may not produce the best diagnostic message.
This patch adds condideration of the number of arguments
to decide the better function subexpression for diagnostic
purpose.
Resolves: SR-7918, SR-7786, SR-7440, SR-7295, SR-5154.
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
