Flow analysis doesn't track definite unassignment in lazy locals correctly.

[leafpetersen]

The following program does not read x in an unassigned state, but currently the front end and the analyzer report the use of x in the initializer of y as a definitely unassigned read. The laziness of late initializers does not seem to be taken into account in the flow analysis.

main() {
  late int x;
  late int y = x;

  x = 3;
  y;
}

cc @johnniwinther @scheglov @stereotype441

[stereotype441]

Agreed. We should be able to fix this fairly simply by re-using the logic we use for closures. In essence we would treat the code above as syntactic sugar for:

main() {
  int? x;
  int get_x() => x!;
  int? y;
  int get_y() => y ??= get_x();

  x = 3;
  get_y();
}

(note that this is a bit handwavy because such a desugaring wouldn't work in general: it would do the wrong thing for nullable-typed late variables, and it would destroy the ability to promote late variables. I'll make sure that the real implementation of flow analysis handles late nullable variables correctly and retains the ability to promote late variables.)

[leafpetersen]

In thinking through some tests, I noted the following difference between closures and late variables which we may or may not want to account for:

void test(bool b) {
  late int x;
  late int y;
  var f = () {
      x;  // x is neither definitely assigned nor definitely unassigned
      x = 3;
  }
  f();  // Use of x is undefined
  f(); // Use of x is not defined
  late var z = y + (y = 3); // use of y can be soundly treated as definitely unassigned, since there are no writes in the enclosing body
  z; // Use of y is definitely unassigned
  z; // Second use does not re-evaluate the initializer

I don't think this is a particularly high value nuance to capture. I will write tests based on the assumption that we will not distinguish between these, and we can update the tests if this changes.

[leafpetersen]

Thinking about my previous example a bit, I'm not sure that it's correct to treat y as definitely unassigned in the initializer of z. Consider this variant:

void test(bool b) {
  late int x;
  late int y;
  var f = () {
      x;  // x is neither definitely assigned nor definitely unassigned
      x = 3;
  }
  f();  // Use of x is undefined
  f(); // Use of x is not defined
  late var z = y + (y = 3) + throw "Bad"; // use of y cannot be soundly treated as definitely unassigned
  try {
     z; // Use of y is definitely unassigned
  } catch (e, s) {}
  try {
     z; // Re-evaluates the initializer, use of y is now assigned.
  } catch (s, e) {}

[mit-mit]

(removed beta epic as it was already there under flow analysis, which is in beta epic)