commit 5b234e4b0d407337ced1d1b8c1e3da0b4432ad3c
author Paul Berry <paulberry@google.com> Mon Jan 09 18:22:51 2023 +0000
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> Mon Jan 09 18:22:51 2023 +0000
tree fb44d9fabc6b5d590157026ceb90c2748ce24fcb
parent 773bd2f6948fb3ed318c0605180e8dc61d86ca8c

Flow analysis: properly model if/else nature of switches.

A switch statement like this one:

    switch (E) {
      case P1 when G1:
        S1;
      case P2 when G2:
        S2;
      case P3 when G3:
    }

Is equivalent to an if/else chain like this:

    var tmp = E;
    if (tmp case P1 when G1) {
      S1;
    } else if (tmp case P2 when G2) {
      S2;
    } else if (tmp case P3 when G3) {
      S3;
    }

Therefore, if the failure of a particular pattern/guard combination to
match implies a type promotion, it makes sense for that promotion to
be carried into later cases.  For example:

    int? x = ...;
    switch (E) {
      case _ when x == null:
        break;
      default:
        x.isEven; // OK because `x` known to be non-null.
    }

This enabled some more thorough testing of type promotion in switches,
which then caught a bug introduced in a previous CL: when the switch
scrutinee is a variable reference, and we are trying to determine
whether it is safe for a pattern to promote the scrutinee variable, we
were checking the wrong SSA node to determine whether the variable had
been reassigned.  For example:

    Object x;
    switch (x) {
      case _ when f(x = ...);
        break;
      case int _:
        // `x` is not promoted to `int` because it is no longer the
	// same as the cached scrutinee.
        break;
    }

Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: Ie8d6cf0fc662aa5ef0ac81eb2343952028dd2abb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278533
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>