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.
