Migration incorrectly propagates non-nullability to fields via field formals

[stereotype441]

Consider the following program:

class C {
  int i;                     // (1)
  int j;
  C.one(this.i) : j = i + 1; // (2)
  C.two() : i = null, j = 0; // (3)
}

The migration tool currently considers the field C.i to be non-nullable, so it changes line (3) from i = null to i = null!. This is not a great migration, since clearly the user's intent was for i to be nullable. It would be better to change line (1) from int i; to int? i;.

The reason this is happening is that since the expression i + 1 at (2) unconditionally references i, a hard edge is created from the type of C.one's i parameter to never. And since C.one's i parameter gets its type from the C.i field, this causes the field to be forced to non-null.

What should happen instead is that we should never create hard edges to field formal parameters that have implicit types.

[stereotype441]

The current behavior of the tool is to produce the output:

class C {
  int? i;                     // (1)
  int j;
  C.one(this.i) : j = i + 1; // (2)
  C.two() : i = null, j = 0; // (3)
}

This is better than the behavior we had on Sep 18, but it's still not great because it has a compile time error (no null check of i at (2)). What we ought to produce is probably either:

class C {
  int? i;                     // (1)
  int j;
  C.one(this.i) : j = i! + 1; // (2)
  C.two() : i = null, j = 0; // (3)
}

or:

class C {
  int? i;                     // (1)
  int j;
  C.one(int this.i) : j = i + 1; // (2)
  C.two() : i = null, j = 0; // (3)
}

See also #39404

[srawlins]

I am going with the latter solution:

class C {
  int? i;                     // (1)
  int j;
  C.one(int this.i) : j = i + 1; // (2)
  C.two() : i = null, j = 0; // (3)
}

It may be surprising to the author that the type of the field formal is different from the field, but I think this calls out early (rather than later, at runtime with i!) that something may be amiss.