Referencing (instance or static) methods in the key path is not
currently allowed, solver should be responsible for early detection
and diagnosis of both standalone e.g. `\.foo` and chained
e.g. `\.foo.bar` (where foo is a method) references in key path
components.
```swift
struct S {
func foo() -> Int { return 42 }
}
let _: KeyPath<S, Int> = \.foo
```
Resolves: rdar://problem/49413561
Previously it was possible to create an invalid solution where
static members would be referenced in a key path, which is not
currently supported and would only be diagnosed while applying
such solution to AST e.g.
```swift
struct S {
static var foo: Int = 42
}
_ = \S.Type.foo
```
Detect and fix closure parameter destructuring where
it's not currently allowed e.g. free standing closures
with contextual type `let _: ((Int, Int)) -> Void = { $0 + $1 }`
While trying to match function types, detect and fix any missing
arguments (by introducing type variables), such arguments would
get type information from corresponding parameters and aid in
producing solutions which are much easier to diagnose.
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
This is a small access control cleanup where some of the
fixes had public constructors, which is not a preferred
way to create fixes, `create(...)` should be used instead.
Situations like:
```swift
struct S {}
func foo(_ s: S.Type) {
_ = s()
}
```
Used to be diagnosed in solution application phase, which means that
solver was allowed to formed an incorrect solution.
Currently invalid initializer references are detected and
diagnosed in solution application phase, but that's too
late because solver wouldn't have required information while
attempting to determine the best solution, which might result
in viable solutions being ignored in favour of incorrect ones e.g.
```swift
protocol P {
init(value: Int)
}
class C {
init(value: Int, _: String = "") {}
}
func make<T: P & C>(type: T.Type) -> T {
return T.init(value: 0)
}
```
In this example `init` on `C` would be preferred since it
comes from the concrete type, but reference itself is invalid
because it's an attempt to construct class object using
metatype value via non-required initalizer.
Situations like these should be recognized early and invalid
use like in case of `C.init` should be ranked lower or diagnosed
if that is the only possible solution.
Resolves: rdar://problem/47787705
* Make sure that base and unwrapped types aren't null
* Don't allocate `ForceOptional` fix if nothing has been unwrapped
in `simplifyApplicableFnConstraint`
* Add sugar reconstitution support to `FailureDiagnostic::resolveType`
* Format diagnostics a bit better
The intention here is to be able to detect warnings earlier and
move some of the logic from CSApply and MiscDiagnostics to solver.
Warning fixes still lead to solution being applied to AST.
If lookup couldn't find anything matching given name, let's try to
fake its presence based on how member is being used. This is going
to help (potentially) type-check whole expression and diagnose the
problem precisely.
If the base type is not optional, trying to unwrap it is
incorrect. Introduce a fix to make it look like base was
an optional type which leads solver to move forward
towards possible solution.
Let's keep track of type mismatch between type deduced
for the body of the closure vs. what is requested
contextually, it makes it much easier to diagnose
problems like:
```swift
func foo(_: () -> Int) {}
foo { "hello" }
```
Because we can pin-point problematic area of the source
when the rest of the system is consistent.
Resolves: rdar://problem/40537960
Since `ConstraintFix` references `ConstraintSystem` directly now,
we can get `SourceManager` from `ASTContext` associated with that
`ConstraintSystem` instead of passing it in every time.
There is no longer any reason to attach solution to `ConstraintFix`
because solution applied to the constraint system before any of the
related fixes are diagnosed, so instead let's attach `ConstraintSystem`
to `ConstraintFix` directly, because it would have all of the required
information.
Since constraint fix life span is tightly coupled with particular
constraint system, it makes sense to allocate fixes using the same
allocator as used for constraints.
Make is so `FixKind` lives in the new `CSFix` header and
all new `ConstraintFix` classes get a kind. That's useful
when trying to identify if locator has multiple fixes of
the same kind attached to it.
A fix is related to one of the constraints through its locator,
and contains information required to "fix" a failure associated with
given constraint, each of the fixes also includes diagnostic.
