commit 3d01b0aac3b5f143a2ccbefa8f9339272e1591a4
author Paul Berry <paulberry@google.com> Tue Feb 07 18:24:54 2023 +0000
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Feb 07 18:24:54 2023 +0000
tree 441242d5ec210cd026a380ce19b00a16d85d8f9a
parent 145b6c4a8ca09a55bd9f4ba5089d71e8f7e56048

Flow analysis: add support for constant patterns.

Since matching a constant pattern implicitly performs an equality
check, we do the same flow analysis for constant patterns that we
would have done for an explicit equality test.  There are only two
user-visible behaviours:

- If the constant pattern is a `null` literal, then in the code path
  where the pattern fails to match, the scrutinee is promoted to a
  non-nullable.

- If the constant pattern and the scrutinee are both `null` literals,
  the pattern match is known to always succeed (so the code path where
  the pattern fails to match is marked as unreachable).

The first of these two behaviours is genuine useful to the user, since
it allows things like:

    switch (expr) {
      case null:
        ...
      ...
      default:
        // expr is known to be non-`null`.
    }

The second behaviour is not so useful, but seemed worth doing to
maximize code sharing and to keep the behaviour consistent between
pattern matching and explicit null checks.

Making this work required extracting some of the logic that was
formerly in `_FlowAnalysisImpl.equalityOperation_end` into a method
`_equalityCheck`, which understands how to analyze an equality check
regardless of whether it's an explicit equality expression or an
implicit part of a pattern.  It returns an `_EqualityCheckResult`,
which `equalityOperation_end` examines to determine exactly what needs
to be done to for an equality test in an expression context;
similarly, `_FlowAnalysisImpl.constantPattern_end` now calls
`_equalityCheck` and then does the right thing for patterns.

It was also necessary to extract the logic from
`nullCheckOrAssertPattern_begin` for handling null checks in patterns;
that logic is now in `_nullCheckPattern`, which is also called by
`constantPattern_end`.

In the process of testing this change, I discovered (and fixed) a
minor bug: when analyzing a switch statement or switch expression, we
were re-capturing the value of the scrutinee before visiting each
pattern.  This meant, for example, that we would analyze the following
code incorrectly:

    int? i = ...;
    switch (i) {
      case _ when f(i = ...):
        ...
      case null:
        ...
      default:
        // `i` should *not* be promoted to non-null here, because it's
        // not guaranteed to be the same as the value matched by `case
        // null` above.
    }

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