Expression patterns (and cast patterns) don't actually contribute to
the exhaustivity of a switch statement---if you're matching against a
String, matching "abc" doesn't meaningfully reduce the full space of
the values you have to match. This was already handled, but didn't do
the right thing in a particular case involving a tuple payload in an
enum after the Space Engine (exhaustivity checker) optimizations that
went out in Swift 5.
https://bugs.swift.org/browse/SR-10301
In light of the invocation limits placed on space subtraction, this grossly incorrect check is being dropped.
Resolves a source of miscompiles in mostly machine-generated code
including SR-6652 and SR-6316.
Without this, the compiler ended up complaining about missing cases
that can't actually occur, like `Optional<Never>.some(_)`. This was a
regression from Swift 4.1.
https://bugs.swift.org/browse/SR-8125
Note that I said "warnings"; we're going to be more cautious about
rollout and just make this a warning in Swift 5 mode, with /no/
diagnostics in Swift 3 and 4. Users are still free to use `@unknown
default` in these modes, and they'll get a fatal run-time error if
they don't and an unexpected case actually shows up.
rdar://problem/29324688
At one point compiler wouldn't let you use them in matches, so people have
had to use catch-all cases instead. SILGen already handles this because of
@_downgrade_exhaustivity_check, as well as non-exhaustive enums in
Swift 4 mode.
rdar://problem/33246586
- Combine the common logic for editor mode and non-editor mode.
- Do a better job minimizing fix-its.
- If '@unknown' is the only missing case, put `fatalError()` in the
Xcode placeholder, since that's what the compiler would have done.
That is, when matching non-frozen enums at non-top-level positions:
switch (nonFrozenEnum1, nonFrozenEnum2) {
case (.singleKnownCase1, .singleKnownCase2): ...
unknown: ...
}
...it's sufficient to use '@unknown' to match
(.singleKnownCase1, .someFutureCase2)
(.someFutureCase1, .singleKnownCase2)
(.someFutureCase1, .someFutureCase2)
The other half of '@unknown' in Sema. Again, the diagnostics here
could be improved; rather than a generic "switch must be exhaustive",
it could say something about unknown case handling known cases.
One interesting detail here: '@unknown' is only supposed to match
/fully/ missing cases. If a case is /partly/ accounted for, not
handling the rest is still an error, even if an unknown case is
present.
This only works with switches over single enum values, not values that
contain an enum with unknown cases. That's coming in a later commit.
(It was easier to get this part working first.)
The first half of Sema support for '@unknown'. The other part is
handling when the user /does/ write '@unknown', which results in
/other/ things being downgraded to warnings.
The diagnostics here are still pretty minimal; they should explain
what's going on with '@unknown' to someone who hasn't read the Swift 5
release notes.
Warn in Swift 4 mode and error in Swift 5 mode when switching on a
non-frozen enum without providing a default case.
Note that this is a preliminary implementation, in order to test the
rest of the feature.
