Problem(s) which caused `ErrorExpr` to be added to AST should be
diagnosed already and solver wouldn't be able to produce a viable
solution in such case anyway.
If one of the parameters represents a destructured tuple
e.g. `{ (x: Int, (y: Int, z: Int)) in ... }` let's fail
inference and not attempt to solve the constraint system because:
a. Destructuring has already been diagnosed by the parser;
b. Body of the closure would have error expressions for
each incorrect parameter reference and solver wouldn't
be able to produce any viable solutions.
This general notion of wiring up the types of variables that occur
within a pattern to the types in the produced pattern type is useful
outside of function builders, too.
Sink the constraint generation for initialization patterns, including all
of the logic for property wrappers, from the high-level entry point
`typeCheckBinding` down into the lower-level constraint generation for
solution application targets.
Move more constraint generation logic for an expression target into a
new generateConstraints() on a solution target, so we can further
generalize the main “solve” logic.
Set the contextual type of conditional expressions (to Bool) with the
"condition" purpose so we get customized diagnostics for mistakes such
as
if x.property = y { }
Prior to this, we'd get generic "() isn't convertible to Bool"
diagnostic. Now we get
use of '=' in a boolean context, did you mean '=='?
Move constraint generation for statement conditions onto the
constraint system; it doesn't really have any reason to be located
within the function builder transform.
Collect all references to parameters whose types involve type variables,
including in closures that aren’t single-expression. This fixes a type
checker assertion that occurs when the constraint graph can get disconnected
with the combination of delayed constraint generation for single-expression
closures and the use of function builders.
Fixes rdar://problem/58695803.
When generating constraints in the context of the "old" diagnostic
path that type-checks subexpressions independently, we might not have
types for closure parameters. Cope with the case with a narrower form
of the original hack.
Both multi- and single-statement closures now behave the same way
when it comes to constraint generation, because the body is opened
only once contextual type becomes available or it's impossible
to find one e.g. `_ = { 1 }`.
Attempt to infer a closure type based on its parameters and body
and put it aside until contextual type becomes available or it
has been determined that there is no context.
Once all appropriate conditions are met, generate constraints for
the body of the closure and bind it the previously inferred type.
Doing so makes it possible to pass single-statement closures as
an argument to a function builder parameter.
Resolves: SR-11628
Resolves: rdar://problem/56340587
Separate closure from top-level constraint generation because
its body shouldn't be considered when it comes to parent/weight
computation, otherwise top expression in body is going to get
disconnected from the closure.
Rather than mutating the parameter pattern in place and separately
return whether an error occurred, return the new pattern or NULL if an
error occurred. While here, switch over to ContextualPattern for the
input.
And get rid of that infernal "goto".
Contextual pattern describes a particular pattern with enough
contextual information to determine its type. Use this to simplify
TypeChecker::typeCheckPattern()'s interface in a manner that will
admit request'ification.
Make TypeChecker::typeCheckPattern() return the computed type, rather
than returning an "error" flag. More importantly, make it functional,
so that it doesn't set the type it computes on the pattern.
Use UnresolvedType as a placeholder for types that need to be
inferred, rather than a null type. This allows us to produce
structural types involving types that need to be inferred.
Note that with this change as-is, we get a number of duplicated
diagnostics, because typeCheckPattern() will be called multiple times
for the same pattern and will emit some diagnostics each time. This
will be addressed in a subsequent commit.
Curry thunks create AutoClosureExprs with parameters, and we can't just
fold those away.
Also, remove an older AutoClosureExpr cleanup that seems to be
redundant.
It might be either impossible to infer the base because there is
no contextual information e.g. `_ = .foo` or there is something
else wrong in the expression which disconnects member reference
from its context.
Rather than setting up the constraint solver with a single expression
(that gets recorded for parents/depths), record each expression that
goes through constraint generation.
