Flow analysis. If `while` part of `do-while` is `Never` the code after the loop must be unreachable

[sgrekhov]

Errors below are not reported either by the analyzer or CFE.

test(Never n) {
  late int i;
  if (1 > 2) {
    do {
    } while (n);
    i = 42;
  }
  i; // Definitely unassigned but no error
}

Another example

test(Never n) {
  late int i;
  if (1 > 2) {
    do {
      i = 42;
    } while (n);
  }
  i; // Definitely unassigned but no error
}

Note that the code below works

test(Never n) {
  late int i;
  if (1 > 2) {
    do {
      i = 42;
      n;
    } while (false);
  }
  i; // Definitely unassigned. Ok, the error the is reported.
}

cc @stereotype441

Dart SDK version: 3.8.0-197.0.dev (dev) (Sat Mar 15 17:07:22 2025 -0700) on "windows_x64"

[lrhn]

I'd suggest to make everything downstream of an assignment to a Never variable be dead code, which includes the function entry assignment to the parameter here. The entire body is definitely dead.

For a non-parameter, we'd recognize Never x = e; to be invalid, or e have a bottom type, so the assignment would be recognized. The implicit assignments of foo(Never n) { ... } or for (Never n in ...) {...dead...} are more indirect, but they still imply that a Never-typed variable was assigned, which we know it wasnt.

[stereotype441]

I believe this issue is happening as a consequence of #60265 (When an expression with static type Never is used as a condition, flow analysis sometimes forgets that the code path is unreachable).

In the code:

test(Never n) {
  late int i;
  if (1 > 2) {
    do {
    } while (n);
    i = 42;
  }
  i; // Definitely unassigned but no error
}

The reference to n in do ... while (n) meets all the conditions of #60265, so flow analysis forgets that the code path is unreachable. So it assumes that the assignment i = 42 is reachable. Furthermore, since flow analysis doesn't perform any constant folding (by design), it doesn't know which branch of if (1 > 2) will be taken. Therefore, it sees two reachable code paths leading to the statement i;:

• one assuming that 1 > 2 is true (in which case i is assigned)
• one assuming that 1 > 2 is false (in which case i is not assigned)
  So no error is issued at the site of the statement i;.

Roughly the same analysis applies to the second example:

test(Never n) {
  late int i;
  if (1 > 2) {
    do {
      i = 42;
    } while (n);
  }
  i; // Definitely unassigned but no error
}

This code, on the other hand:

test(Never n) {
  late int i;
  if (1 > 2) {
    do {
      i = 42;
      n;
    } while (false);
  }
  i; // Definitely unassigned. Ok, the error the is reported.
}

Works as expected because the expression with static type Never is not used as a condition, so #60265 doesn't apply.

I'm fairly convinced this is what is going on, but I'm not 100% certain, so I'm not going to mark this as a duplicate of #60265. When I fix #60265, I'll come back and look at this bug to check whether it's fixed.