In cases like:
```
func test<T>(_: () -> T?) -> [T] {
...
}
test {
if ... {
return
}
...
}
```
Contextual return type would be first attempted as optional and
then unwrapped if the first attempt did not succeed. To avoid having
to solve the closure twice (which results in an implicit function conversion),
let's add an implicit empty tuple (`()`) to the `return` statement
and allow it be to injected into optional as many times as context
requires.
If one or more outer closure parameters used in the body of an
inner closure have not been resolved when conjunction is created,
let's reference them in the conjunction constraint to avoid
disconnecting conjunction from its context.
Attempting to pre-compute a set of referenced type variables
upfront is incorrect because parameter(s) and/or result type
could be bound before conjunction is attempted. Let's compute
a set of referenced variables before each element gets attempted.
It is possible that contextual type of a parameter
has been assigned to an anonymous of named argument
early, to facilitate closure type checking. Such a
type can have type variables inside e.g.
```swift
func test<T>(_: (UnsafePointer<T>) -> Void) {}
test { ptr in
...
}
```
Type variable representing `ptr` in the body of
this closure would be bound to `UnsafePointer<$T>`
in this case, where `$T` is a type variable for a
generic parameter `T`.
Let's delay solution application to multi-statement closure bodies,
because declarations found in the body of such closures may depend
on its `ExtInfo` flags e.g. no-escape is set based on parameter if
closure is used in a call.
Bodies of multi-statement closures should be handled in isolation
because they don't dependent on anything expect parameter/result
types from outer context.
when it has property wrapper parameters.
The property wrapper type will be replaced with either the wrapped-value
or projected-value type, depending on the argument label/parameter name,
and CSApply will build a thunk to construct the property wrapper and call
the function.
Reverse the polarity of the "checked in context" bit for ClosureExpr
to "separately checked", which simplifies the AST walker logic (to
"should we walk separately type-checked closure bodies?") and
eliminates single-expression closures as a separate case to consider.
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.
Introduce a new predicate, shouldTypeCheckInEnclosingExpression(), to
determine when the body of a closure should be checked as part of the
enclosing expression rather than separately, and use it in the various
places where "hasSingleExpressionBody()" was used for that purpose.
