Migration: consider handling compound assignments where the read type is nullable

[stereotype441]

It's not clear what the migration tool should do if it encounters a compound assignment where the read type is nullable, e.g.:

class C {
  C operator+(C other) { ... }
}
void f(C/*?*/ x, C y) {
  x += y;
}

The only way to properly migrate the expression x += y is to first desugar it to x = x + y and then add the appropriate null check to produce x = x! + y. But this can’t be done in the general case where the LHS assignment might be a property access or an index expression, because duplicating the LHS would change semantics.

In https://dart-review.googlesource.com/c/sdk/+/119525 we simply report the situation as a problem for the user to fix manually. But if this comes up frequently enough we may wish to do something different, for example:

• Go ahead and desugar the expression in cases where it is semantics preserving, or
• Go ahead and desugar the expression in all cases, and warn the user if semantics might have changed

[stereotype441]

As of d8fcc65 we're not even reporting this as a problem for the user to fix manually. The user isn't alerted to the problem until they try to run (or analyze) the migrated code.

[stereotype441]

There is actually a more general problem here, even for code that doesn't involve nulls. For example, consider:

abstract class _C extends _D {
  _D/*!*/ operator+(int/*!*/ value);
}
abstract class _D {}
_f(_C/*!*/ x, int/*!*/ y) => x += y;

This can't be migrated without desugaring the assignment, because what is needed is to change x += y to x = (x + y) as _C.