Rather than computing these each time we need to solve an element that
has a reference to them, let's just set them up-front when we generate
constraints for the corresponding variable.
Introduce CustomAttrOwner that can store either a Decl for an
attached attribute, or a DeclContext for e.g a type or closure
attribute. Store this on CustomAttr such that we can query it from
the name lookup requests.
We still need to solve a branch with a ReturnStmt to avoid leaving
the contextual result type unbound. This isn't currently legal anyway,
so isn't likely to come up often in practice, but make sure we can
still solve.
Now that we wire up the parents up-front, this no longer needs to
set the parents. As such, remove the logic and rename to reflect the
fact that it now just diagnoses mutability mismatches.
We don't wire up the parent variables until after type-checking, and
`recordInferredSwitchCasePatternVars` already handles joining the
pattern types, so we can remove this.
Previously we would skip type-checking the result expression of a
`return` or the initialization expression of a binding if the contextual
type had an error, but that misses out on useful diagnostics and
prevents code completion and cursor info from working. Change the logic
such that we open ErrorTypes as holes and continue to type-check.
`return` statement withot an expression automatically gets an
implicit `()` which is allowed to be converted to types like
`()?` and `Any` or `Any?`. Let's remove a too strict assertion
that expected a contextual type to always be `()?` even
through in reality any type that `()` is convertible to is valid.
Resolves: rdar://152553143
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.
