[sound flow analysis] Implement behaviors for equality comparisons.

This change updates the flow analysis logic for `==` and `!=`
expressions, `==` and `!=` patterns, and constant patterns, so that
when the language feature `sound-flow-analysis` is enabled, the static
types of the two expressions being compared are checked for
nullability. If one of the types is non-nullable and the other type is
`Null`, then it is known that the values will be unequal.

Note that these new behaviors break assumptions made by several
pre-existing flow analysis tests. I was able to adjust some of the
tests to preserve their old behavior, either by adjusting expectations
or running the test with `sound-flow-analysis` disabled. Some other
tests became redundant, so I removed them.

There is no behavioral change if the feature `sound-flow-analysis` is
disabled.

Bug: #60438
Change-Id: Ib65477e064bb8dcd761542ebe187843fe265a24b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420463
Commit-Queue: Paul Berry <[email protected]>
Reviewed-by: Chloe Stefantsova <[email protected]>

Author: stereotype441

pkg/_fe_analyzer_shared/lib/src/flow_analysis/flow_analysis.dart

@@ -4693,6 +4693,11 @@ class _FlowAnalysisImpl<Node extends Object, Statement extends Node,
         // whole expression behaves equivalently to a boolean (either `true` or
         // `false` depending whether the check uses the `!=` operator).
         booleanLiteral(wholeExpression, !notEqual);
+      case _GuaranteedNotEqual():
+        // Both operands are known by flow analysis to compare unequal, so the
+        // whole expression behaves equivalently to a boolean (either `true` or
+        // `false` depending whether the check uses the `!=` operator).
+        booleanLiteral(wholeExpression, notEqual);
 
       // SAFETY: we can assume `reference` is a `_Reference<Type>` because we
       // require clients not to mix data obtained from different
@@ -5770,10 +5775,15 @@ class _FlowAnalysisImpl<Node extends Object, Statement extends Node,
                 TypeClassification.nullOrEquivalent &&
             leftOperandTypeClassification == TypeClassification.nonNullable)) {
       // In strong mode the test is guaranteed to produce a "not equal" result,
-      // but weak mode it might produce an "equal" result.  We don't want flow
-      // analysis behavior to depend on mode, so we conservatively assume that
-      // either result is possible.
-      return const _NoEqualityInformation();
+      // but weak mode it might produce an "equal" result. If sound flow
+      // analysis is enabled, we assume that the user isn't running in weak mode
+      // and so we propagate the known "not equal" result. Otherwise, we
+      // conservatively assume that either result is possible.
+      if (typeAnalyzerOptions.soundFlowAnalysisEnabled) {
+        return const _GuaranteedNotEqual();
+      } else {
+        return const _NoEqualityInformation();
+      }
     } else if (lhsInfo != null && lhsInfo.isNull) {
       return new _EqualityCheckIsNullCheck(
           rhsInfo is _Reference<Type> ? rhsInfo : null,
@@ -6012,16 +6022,30 @@ class _FlowAnalysisImpl<Node extends Object, Statement extends Node,
       case _GuaranteedEqual():
         if (notEqual) {
           // Both operands are known by flow analysis to compare equal, so the
-          // constant pattern is guaranteed *not* to match.
+          // pattern is guaranteed *not* to match.
           _unmatched = _join(_unmatched!, _current);
           _current = _current.setUnreachable();
         } else {
           // Both operands are known by flow analysis to compare equal, so the
-          // constant pattern is guaranteed to match.  Since our approach to
-          // handling patterns in flow analysis uses "implicit and" semantics
-          // (initially assuming that the pattern always matches, and then
-          // updating the `_current` and `_unmatched` states to reflect what
-          // values the pattern rejects), we don't have to do any updates.
+          // pattern is guaranteed to match.  Since our approach to handling
+          // patterns in flow analysis uses "implicit and" semantics (initially
+          // assuming that the pattern always matches, and then updating the
+          // `_current` and `_unmatched` states to reflect what values the
+          // pattern rejects), we don't have to do any updates.
+        }
+      case _GuaranteedNotEqual():
+        if (notEqual) {
+          // Both operands are known by flow analysis to compare unequal, so the
+          // pattern is guaranteed to match.  Since our approach to handling
+          // patterns in flow analysis uses "implicit and" semantics (initially
+          // assuming that the pattern always matches, and then updating the
+          // `_current` and `_unmatched` states to reflect what values the
+          // pattern rejects), we don't have to do any updates.
+        } else {
+          // Both operands are known by flow analysis to compare unequal, so the
+          // pattern is guaranteed *not* to match.
+          _unmatched = _join(_unmatched!, _current);
+          _current = _current.setUnreachable();
         }
     }
   }
@@ -6382,6 +6406,16 @@ class _GuaranteedEqual extends _EqualityCheckResult {
   const _GuaranteedEqual() : super._();
 }
 
+/// Specialization of [_EqualityCheckResult] used as the return value for
+/// [_FlowAnalysisImpl._equalityCheck] when it is determined that the two
+/// operands are guaranteed to be not equal to one another, so the code path
+/// that results from an equal result should be marked as unreachable.  (This
+/// happens if one operands has type `Null` and the other has a non-nullable
+/// type, and [TypeAnalyzerOptions.soundFlowAnalysisEnabled] is `true`).
+class _GuaranteedNotEqual extends _EqualityCheckResult {
+  const _GuaranteedNotEqual() : super._();
+}
+
 /// [_FlowContext] representing an `if` statement.
 class _IfContext<Type extends Object> extends _BranchContext<Type> {
   /// Flow model associated with the state of program execution after the `if`