Use the generalized constraint generation and binding for patterns to
introduce support for if-let and if-case in function builders, handling
arbitrary patterns.
Part of function builder generalization, rdar://problem/50426203.
Rather than re-walk the pattern to create type bindings for the variables
that show up in the pattern, assign types to each of the variables as part
of constraint generation for the pattern. Only do this in contexts
where we will need the types, e.g., function builders.
Extend the constraint system’s diagnostics with specific handling for
matching an enum element pattern that has a subpattern (i.e., to capture
associated values) against an enum case that does not have any associated
value. This brings diagnostics for the new code path on par with the existing
diagnostics of coercePatternToType.
Generate a complete set of constraints for EnumElement patterns, e.g.,
case let .something(x, y)
Most of the complication here comes from the implicit injection of optionals,
e.g., this case can be matched to an optional of the enum type of which
`something` is a member. To effect this change, introduce a locator for
pattern matching and use it to permit implicit unwrapping during member
lookup without triggering an error.
Note also labels are dropped completely when performing the match,
because labels can be added or removed when pattern matching. Label
conflict are currently diagnosed as part of coercePatternToType, which
suffices so long as overloading cases based on argument labels is not
permitted.
The primary observable change from this commit is in diagnostics: rather
than diagnostics being triggered by `TypeChecker::coercePatternToType`,
diagnostics for matching failures here go through the diagnostics machinery
of the constraint solver. This is currently a regression, because
there are no custom diagnostics for pattern match failures within the
constraint system. This regression will be addressed in a subsequent
commit; for now, leave those tests failing.
Generate a checked-cast constraint for an “is” pattern, which otherwise
doesn’t change the type. This is hard to validate because checked-cast
constraints never actually fail.
Currently constraint solver is only capable of detecting universally unavailable
overloads but that's insufficient because it's still possible to pick a contextually
unavailable overload choice which could be better than e.g. generic overload, or
one with defaulted arguments, marked as disfavored etc.
Let's introduce `ConstraintSystem::isDeclUnavailable` which supports both universal
and contextual unavailability and allow constraint solver to rank all unavailable
overload choices lower than any other possible choice(s).
Resolves: rdar://problem/59056638
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 }`.
