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.
