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.
Rather than using various "applied function builder" and "is single
expression body" checks to determine whether a closure was
type-checked in its enclosing expression, record in the closure
expression whether it actually *was* type-checked as part of its
enclosing expression.
Introduce a statement visitor that applies a particular solution to
the body of a closure. This matches the mechanism used by function
builders (and is similar to how we handle expressions in general),
simplifying the logic for handling
conversion-to-void-returning-closures and
conversion-from-Never-returning-bodies. It is a stepping stone for
type inference of multi-statement closures.
Slim down CSApply.cpp by moving the logic for applying a solution to a
closure into CSClosure.cpp. Also, eliminate duplicated logic for applying
function builders to the body of a closure or function. This should
not change semantics at all.
In preparation for implementing support for multiple-statement closure
inference, switch closure constraint generation over to a statement
visitor. Only the subset of statements that correspond to
single-expression closures is currently handled; there is no way to
enable this for multiple-statement closures yet.
