[CP] Flow analysis: Use extension type erasure for implicit is reachability.

[stereotype441]

Commit(s) to merge

97edad1

Target

Beta

Prepared changelist for beta/stable

https://dart-review.googlesource.com/c/sdk/+/348200

Issue Description

When the type of the expression in a switch statement is an extension type, but a pattern used in the switch statement matches the corresponding representation type, the switch is exhaustive (because patterns are matched using runtime type checks, and extension types are erased at runtime). The exhaustiveness verifier understands this, but flow analysis does not. This can result in confusing "catch-22" situations where flow analysis leads to an error or warning, but attempting to correct that error or warning results in an "unreachable case" warning from the exhaustiveness verifier. For a detailed example of such a catch-22, see dart-lang/language#3534 (comment).

The opposite situation can also occur (if the type of the switch expression is the representation type and a pattern used in the switch statement matches the corresponding extension type).

What is the fix

To fix this issue, flow analysis was updated to take into account extension type erasure when determining reachability based on implicit is checks that occur as part of pattern matching.

Why cherry-pick

Since the problem is an interaction between extension types and patterns, and extension types have not been released, cherry-picking the fix will ensure that no stable version of Dart ships with the bug. Accordingly, the fix doesn't have to be classified as a breaking change.

If Dart 3.3 ships without the cherry pick, then we have three possible scenarios:

• We could decide to cherry pick the fix to a patch release of Dart 3.3, resulting in the possibility that users who have already started using the "extension types" feature, and have inadvertently relied on the broken flow analysis behavior, will experience a code breakage when they upgrade their Dart installation. Fortunately, the breakage will be a compile-time error rather than a runtime error, so it is unlikely to result in users accidentally shipping buggy products.
• We could do nothing, in which case users will experience a code breakage when Dart 3.4 is released. Furthermore, users who develop a package using Dart 3.4 and publish it on pub may find that their package has a compile time error when used with Dart 3.3 (even if the package author's SDK constraint indicates that their package should be compatible with Dart 3.3). This could be quite frustrating for package authors.
• We could modify the existing fix so that it is conditioned on language version; this would avoid problems with packages published on pub, and it would ensure that any compile-time errors only occur when the user deliberately changes their language version (a time when there is some expectation of having to fix compile-time errors). But it would have the downside that we would be forced to maintain both the new and old behaviors in the codebase for years to come.

Note that all of these theoretical breakage scenarios will only occur if the user attempts to mix extension types and their corresponding representation types using pattern matching. This probably won't happen very often to begin with, because it's not a terribly good idea. So one could argue that the "do nothing" option isn't that bad. However, the inherent risk incurred by doing the cherry-pick is low for the same reason. So I would argue that the cherry-pick is worth doing irregardless.

Risk

low

Issue link(s)

dart-lang/language#3534

Extra Info

No response

[itsjustkevin]

@leafpetersen could you take a look at this cherry-pick request?

[leafpetersen]

I'm in favor of taking this in 3.3 if we can, otherwise in the first patch release. I think it's quite low risk.