Flow analysis. The body of `while(false)...` is dead code

[sgrekhov]

Thanks to @eernstg for helping with finding this issue. No expected error below in either CFE or the analyzer.

main() {
  late int n;
  while (false) {
    n = 42;
  }
  n;  // Definitely unassigned but no expected error
//^
// [analyzer] unspecified
// [cfe] unspecified
}

Dart SDK version: 3.8.0-174.0.dev (dev) (Mon Mar 10 21:06:07 2025 -0700) on "windows_x64"

[johnniwinther]

cc @stereotype441

[stereotype441]

Flow analysis is behaving as expected (and as specified).

Background: to avoid compromising compilation speed, flow analysis has been designed so that it only requires a single pass through the user's code. This means that whenever there is incoming control flow from a backwards branch, flow analysis has to perform a conservative approximation.

In the example:

main() {
  late int n;
  while (false) {
    n = 42;
  }
  n;
}

The control flow looks like this:

flowchart TD
    Start --> id1[late int n]
    id1 --> id2@{ shape: f-circ }
    id2 --> id3{"loop condition:
false"}
    id3 -->|if true| id4[n = 42]
    id4 --> id2
    id3 -->|if false| id5[n]
    id5 --> End

Loading

When flow analysis reaches the join point at the top of the while loop, n is in the "definitely unassigned" state. (In the terminology used in https://github.com/dart-lang/language/blob/main/resources/type-system/flow-analysis.md#models, its VariableModel is VariableModel(declaredType=int, promotedTypes=[], tested=[], assigned=false, unassigned=true, writeCaptured=false).

Since there is incoming control flow from a backwards branch (coming from the bottom of the while loop), flow analysis computes conservativeJoin(before(N), assignedIn(N), capturedIn(N)), where N represents the while statement (see https://github.com/dart-lang/language/blob/main/resources/type-system/flow-analysis.md#statements). assignedIn(N) is a set contaning the single variable n, so as a result flow analysis sets unassigned=false, putting n in the "potentially assigned" state.

This all happens in spite of the fact that the loop condition is false, because at this point flow analysis hasn't yet reached loop condition.

Later, when flow analysis does reach the loop condition, it uses the fact that it is false to figure out that the body of the loop is unreachable, and the code that follows the loop is reachable. But at that point it is too late to un-do the effects of the conservativeJoin, so n is still considered to be potentially assigned.

As a result, when flow analysis reaches the reference to n, it doesn't know whether n has been assigned or not, so since it's a late variable, it issues no error.

[sgrekhov]

Thank you for the detailed explanation!