Factor out `ConstraintSystem::getExplicitCaughtErrorType` from
`getCaughtErrorType`. Then use this for the contextual
type for a `throw` syntactic element.
rdar://139000351
Make sure we set the correct DeclContext for CSGen
of multi-statement closure captures, since
otherwise the DeclContext is set to the closure
itself, which is wrong.
Use `simplifyType` instead with the new parameter
for getting an interface type. Also avoid using
`resolveInterfaceType` in CSApply since we don't
need the opened generic parameter mapping behavior.
Instead of using `one-way` constraints, just like in closure contexts
for-in statements should type-check their `where` clauses separately.
This also unifies and simplifies for-in preamble handling in the
solver.
Instead, ensure we walk into expressions in
SyntacticDiagnosticWalker, allowing
`performStmtDiagnostics` to be called there for
all statements present in the target. This avoids
a case where we'd double diagnose.
While here, inherit the walker from
BaseDiagnosticWalker.
`participatesInInference` is now always true for
a non-empty body, remove it along with the separate
type-checking logic such that empty bodies are
type-checked together with the context.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
If closure appears inside of a pack expansion, the elements
that reference pack elements have to bring expansion's shape
type in scope to make sure that the shapes match.
Track the implied result exprs in the constraint
system, and allow arbitrary propagation of
implied results down if/switch expression
branches. This is required for allowing implied
results in non-single-expression closures.
Currently we don't insert an intermediate
`SyntacticElement` locator element for the `if`
statement in a SingleValueStmtExpr, which leads
to an assertion failure when attempting to simplify
a following `TernaryBranch` element.
Move the insertion of the `SyntacticElement` locator
element for the statement into the
SingleValueStmtExpr constraint generation function,
and remove it from the statement visitors themselves.
For the other cases, the `SyntacticElement` was
already being inserted for children of a BraceStmt,
so we were actually previously ending up with
duplicated elements in a couple of places.
Unify the implementation between single-expression
and multi-statement closures. Because we're now
storing a contextual type for single expression
closure returns, update a code completion test to
bring its behavior inline with the multi-statement
case.
This wasn't consistently used, and consequently
could result in some expressions getting their
parents invalidated. Instead, replace it with a
query to make sure we don't try and add an
expression we've already computed the parent info
for.
This models the conversion from an uninhabited
value to any type, and allows us to get rid of
a couple of places where we'd attempt to drop
the return statement instead.
Remove this bit from function decls and closures.
Instead, for closures, infer it from the presence
of a single return or single expression AST node
in the body, which ought to be equivalent, and
automatically takes result builders into
consideration. We can also completely drop this
query from AbstractFunctionDecl, replacing it
instead with a bit on ReturnStmt.
Most clients only want to set one of the two
parameters, split it into `setPattern` and
`setInitContext` (the latter of which now
handles calling `setBinding`).
Use the PatternBindingInitializer context if we
have one. This also uncovered a parser issue where
we would mistakenly create a
PatternBindingInitializer in top-level code after
parsing the initializers.
