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
Try to fix constraint system in a way where member
reference is going to be defined in terms of its use,
which makes it seem like parameters match arguments
exactly. Such helps to produce solutions and diagnose
failures related to missing members precisely.
These changes would be further extended to diagnose use
of unavailable members and other structural member failures.
Resolves: rdar://problem/34583132
Resolves: rdar://problem/36989788
Resolved: rdar://problem/39586166
Resolves: rdar://problem/40537782
Resolves: rdar://problem/46211109
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.
Fix to use subscript operator instead of spelled out name helps
to produce a solution, that makes it much easier to diagnose
problems precisely and provide proper fix-its, it also helps to
diagnose ambiguous cases, and stacks up nicely with other errors.
Detect and fix situations when (force) unwrap is used on
a non-optional type, this helps to diagnose invalid unwraps
precisely and provide fix-its.
Resolves: [SR-8977](https://bugs.swift.org/browse/SR-8977)
Resolves: rdar://problem/45218255
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.
Suggest to add `()` (form a call) to correctly forward argument function
originated from `@autoclosure` parameter to function parameter itself
marked as `@autoclosure`.
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.
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.
