ARGUMENT_TYPE_NOT_ASSIGNABLE although preceded by a not-null condition

[asashour]

For the below case, there is a compiler error

The argument type 'TypeAnnotation?' can't be assigned to the parameter type 'AstNode'

I believe this shouldn't happen, since there is a check for returnType != null, also the error is removed if the returnType is declared as

var returnType = function?.returnType;

void fun(FunctionDeclaration? function, ChangeBuilder builder, String file) async {
  TypeAnnotation? returnType;
  returnType = function?.returnType;
  // var returnType = function?.returnType; // this doesn't give an error

  if (returnType != null) {
    await builder.addDartFileEdit(file, (builder) {
      builder.addReplacement(range.node(returnType), (builder) {
        //                              ^^^^^^^^^^ error is here
      });
    });
  }
}

Dart SDK version: 2.15.0-6.0.dev (dev) (Wed Aug 11 14:48:30 2021 -0700) on "windows_x64"

[lrhn]

Since returnType is captured by a closure, it gets much harder for the compiler to ensure that the execuction really happens after the test, and not after any other change to returnType.
If there is any assignment to a variable inside any closure, all promotion of that variable is turned off. If a variable occurs in a closure, that occurrence may or may not have promotion turned off depending on how clever the compiler manages to be.

In this case, it should be technically possible to retain the promotion (the closure is created after the last assignment to returnType in the function's control flow, and returnType is promoted to non-null at the time), but there are limits to how clever the compiler can be and how far ahead it can look to see that nothing bad happens. Even in cases that look very clear-cut, the edges of those cases might not always be as clearly delimited.

@stereotype441 should know whether this is intended or accidental.

I'd recommend working around this by creating a new variable:

  if (returnType != null) {
    var nonNullReturnType = returnType;
    .....  
             range.node(nonNullReturnType);

[stereotype441]

Yes, this is a known area where flow analysis could be improved. The primary place we're tracking it is here: dart-lang/language#1536.

[srawlins]

Closing in favor of the language issue.