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
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
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
When constructing requirement failures make sure that requirement
kind provided by the caller matches information about requirement
stored in the locator.
Merge logic from `diagnoseAssignmentFailure` and `diagnoseSubElementFailure`
into new `AssignmentFailure`, together with their support functions, which
decouples `CSDiagnostics` from `CSDiag` and scrubs latter from some functionality.
The flag is used to indicate that caller is interested in
diagnostic to be a note instead of an error, it's useful
when trying to diagnose ambiguities.
This is going to make adding same-type and superclass requirement
failures might easier, because they only have to supply custom
diagnostic messages and substituted types.
Change logic to traverse the chain of declaration contexts
starting for "affected" declaration's parent and check if the
requirement is satisfied by one of them, if so return it as
requirement's declaration context.
Extract this logic into a method on `RequirementFailure` to make
it accessible for other types of requirement failure diagnostics.
