Analyzer: Implementation of new static analysis for return statements

[eernstg]

The null-safety specification updates in dart-lang/language#941 and dart-lang/language#948 have been unfolded as part of the migration of tests/language/invalid_returns. This issue is concerned with updating the analyzer correspondingly.

The following tests have a missing compile-time error:

language/async/return_types_test
language/invalid_returns/async_invalid_return_48_test
language/invalid_returns/async_invalid_return_50_test
language/invalid_returns/async_invalid_return_51_test
language/invalid_returns/sync_invalid_return_27_test
language/invalid_returns/async_invalid_return_00_test
language/invalid_returns/async_invalid_return_03_test
language/invalid_returns/async_invalid_return_04_test
language/invalid_returns/async_invalid_return_05_test
language/invalid_returns/async_invalid_return_08_test
language/invalid_returns/async_invalid_return_11_test
language/invalid_returns/async_invalid_return_14_test
language/invalid_returns/async_invalid_return_17_test
language/invalid_returns/async_invalid_return_20_test
language/invalid_returns/async_invalid_return_23_test
language/invalid_returns/async_invalid_return_24_test
language/invalid_returns/async_invalid_return_25_test
language/invalid_returns/async_invalid_return_32_test
language/invalid_returns/async_invalid_return_33_test
language/invalid_returns/async_invalid_return_34_test
language/invalid_returns/async_invalid_return_35_test
language/invalid_returns/async_invalid_return_36_test
language/invalid_returns/async_invalid_return_37_test
language/invalid_returns/async_invalid_return_41_test
language/invalid_returns/async_invalid_return_45_test
language/invalid_returns/async_invalid_return_47_test
language/invalid_returns/async_invalid_return_52_test
language/invalid_returns/async_invalid_return_53_test
language/invalid_returns/async_invalid_return_54_test
language/invalid_returns/async_invalid_return_55_test
language/invalid_returns/async_invalid_return_56_test
language/invalid_returns/async_invalid_return_57_test
language/invalid_returns/async_invalid_return_58_test
language/invalid_returns/async_invalid_return_59_test

The main reasons for the above is that the rules about return; are now more strict, and a void expression can no longer be returned in an async function with return type Future<Null> (and several similar types).

The following tests incur some compile-time errors that shouldn't be there:

language/invalid_returns/async_valid_returns_test
language/async/return_types_test

The reason for this is that the old rules required Future<flatten(S)> to be assignable to the return type where S is the type of the returned expression, and the new rules require S to be assignable to the future value type of the function, or flatten(S) to be a subtype thereof.

[scheglov]

Should these new rules be applied for both legacy and opted-in libraries, or only to opted-in libraries?

[eernstg]

Only for code with null-safety (this is also the reason why these tests are in language, and the language_2 tests have not had a similar update).

[scheglov]

I have an issue with this code (language/invalid_returns/async_invalid_return_35_test):

import 'dart:async';

FutureOr<Object?> Function(void) f = (void a) async {
  return a;
  //     ^
  // [analyzer] unspecified
  // [cfe] unspecified
};

For function expressions we need to infer the return type. I'm using these rules.

Imposed type: FutureOr<Object?>.
Context type: FutureOr<Object?>.
Returned types: [void].
Actual returned type: void.

For this rule: Let T be the actual returned type of a function literal as computed above. Let R be the greatest closure of the typing context K as computed above. If T <: R then let S be T. Otherwise, let S be R. Here T = void, R = FutureOr<Object?>, and T <: R by Left Top rule from the subtyping spec.

So, the inferred type of the closure is Future<flatten(S)> = Future<void>.

Then later, when we check return a; with type void, we have T_v = void and flatten(S) = void, and it is not an error. So, the test fails.

@eernstg @leafpetersen Is there a mistake in my calculations? Is this an unexpected interaction between closure return type inference and null safety?

[leafpetersen]

@scheglov Good catch, I agree with your analysis.

This also raises another issue however. I believe that the change to use futureValueType should also be applied to function literal downwards inference. In particular, I believe that the line

Otherwise the context type is FutureOr<flatten(T)> where T is the imposed return type.

Should be replaced with

Otherwise the context type is FutureOr<futureValueType(T)> where T is the imposed return type.

with a suitable definition of futureValueType.

@eernstg can you follow up?

[scheglov]

@eernstg ping

[leafpetersen]

@eernstg I think the test that @scheglov mentions above is incorrect, can you look into it?

[eernstg]

Sorry, don't know why I missed this one. Looking into it now.