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.
This commit moves the getNSObjectType and
getObjCSelectorType methods from TypeChecker
onto ASTContext. In addition, it moves the
FOR_KNOWN_FOUNDATION_TYPES macro into a separate
file to define each of the Obj-C type decls
we want to have access to.
