Make sure that we're resolving types and patterns using the
PatternBindingDecl context, both for the type resolver context and the
contextual pattern used for pattern resolution.
Fixes a regression with implicitly-unwrapped options reported as
SR-11998 / rdar://problem/58455441.
Let's remove a side-effect from `ConstraintGenerator::inferClosureType`
and default result type to `Void` for multi-statement closures after
closure has been resolved.
Replace it with the "legacy semantic queries" bit. The remaining client
of this bit is SourceKit, which appears to require this bit be set
conditionally so certain semantic property wrapper requests return
a sentinel value.
We should migrate these requests to a syntactic interface as soon as
possible.
rdar://60516325
- optional object type of `.some` pattern ends with `OptionalPayload`
- type of sub-pattern used in a cast points to underlying sub-pattern declaration
- Enum element:
- parent type locator ends with `ParentType`
- member lookup constraint locator ends at `Member`
Wherever we have constraints that involve pattern matching, use the
PatternMatch locator element. Additionally, don't use the TupleElement
locator element for tuple patterns, because it violates assumptions used
for diagnostics.
The new test was crashing; now it has a terrible diagnostic for which I
need to think harder about a fix.
Implement support for switch statements within function builders. Cases can
perform arbitrary pattern matches, e.g.,
tuplify(true) { c in
"testSwitchCombined"
switch e {
case .a:
"a"
case .b(let i, _?), .b(let i, nil):
i + 17
}
}
subject to the normal rules of switch statements. Cases within function
builders cannot, however, include “fallthrough” statements, because those
(like “break” and “continue”) are control flow.
The translation of performed for `switch` statements is similar to that of
`if` statements, using `buildEither(first:)` and `buildEither(second:)` on
the function builder type.
This is the bulk of switch support, tracked by rdar://problem/50426203.
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.
