* [CSDiagnostics] Adjusting MemberAccessOnOptionalBaseFailure to be able to handle key path component member base types
* [tests] Adding regression tests for SR-5688
* [CSDiagnostics] Adjusting source range to diagnose/insert the fixes in correct location
* [tests] Adjusting regression tests to handle the fixits
* [AST] Creating an helper getSourceRange function for KeyPathExpr::Component
* [ConstraintSystem] Store member base type when recording UnwrapOptionalBase fix
* [AST] Creating a new diagnostic note for removing optional from written type
* [CSDiagnostics] Adjusting logic around MemberAccessOnOptionalBaseFailure to emit the correct diagnostics and fixes
* [tests] Adjusting regression tests to add subscript and key path root cases with respective diagnostics
* [Diagnostics] Adjusting message to mention base type
* [CSDiagnostics] Better naming for method/variable that represents base source range
* [CSDiagnostics] Adjusting to use the stored base member only when member is a key path component.
* [Diagnostics] Adjusting minor typos and code
* [AST] Adjusting keypath root diagnostic note message for use unwrapped type
* [CSDiagnostics] Adjusments in MemberAccessOnOptionalBaseFailure diagnostics as per suggestion
* [tests] Adding more test cases for SR-5688
* [CSDiagnostics] Adjusting fixits for key path root and range for diagnostics
* [CSSimplify] Attempt to diagnose InsertExplicitCall for optional function return types when possible on simplifyOptionalObjectConstraint
* [tests] Adding TODO to improve the diagnostics refering to key path root infered as optional types
* [CSDiagnostics] Adjusting comments
* [CSSimplify] Adjusting logic on simplifyOptionalObjectConstraint to attempt InsertCall fix before remove unwrap
* [CSDiagnostics] Adjust the logic to use resolveType on MemberAccessOnOptionalBaseFailure construction
If the problem is related to an operator and argument is an enum
with associated values mention that conformances to `Equatable`
and `Comparable` are not synthesized in such cases.
Single-expression closures have always been traversed differently
from multi-statement closures. The former were traversed as if the
expression was their only child, skipping the BraceStmt and implicit
return, while the later was traversed as a normal BraceStmt.
Unify on the latter treatment, so that traversal
There are a few places where we unintentionally relied on this
expression-as-child behavior. Clean those up to work with arbitrary
closures, which is an overall simplification in the logic.
Diagnose an attempt to pass raw representable type where its raw value
is expected instead.
```swift
enum E : Int {
case one = 1
}
let _: Int = E.one
```
`E.one` has to use `.rawValue` to match `Int` expected by pattern binding.
Diagnose an attempt to initialize raw representable type or convert to it
a value of some other type that matches its `RawValue` type.
```swift
enum E : Int {
case a, b, c
}
let _: E = 0
```
`0` has to be wrapped into `E(rawValue: 0)` and either defaulted via `??` or
force unwrapped to constitute a valid binding.
In situations where left-hand side requires value-to-optional
promotion which ends up in type mismatch let's not mention
optionals in the diagnostic because they are unrelated e.g.
```swift
func test(_: UnsafePointer<Int>??) {}
var value: Float = 0
test(&value)
```
In this example `value` gets implicitly wrapped into a double optional
before `UnsafePointer<Float>` could be matched against `UnsafePointer<Int>`
associated with the parameter.
Diagnostic is about generic argument mismatch `Float` vs. `Int`
and shouldn't mention any optionals.
If closure is an argument to a call to a missing member or invalid
contextual member reference let's not diagnose problems related to
inability to infer parameter types because root issue is that context
for closure inference couldn't be established.
Annotate the covered switches with `llvm_unreachable` to avoid the MSVC
warning which does not recognise the covered switches. This allows us
to avoid a spew of warnings.
When simplifying a keypath constraint with a function type binding, single-parameter functions have the parameter type and the return type matched against the keypath root and value; whereas multiple-parameter functions cause an ambiguous failure (in `simplifyKeyPathConstraint`).
Resolves rdar://problem/57930643
This is useful when diagnostic needs to check something about type
variables involved in a particular type e.g. whether type variable
has been defaulted.
