Proposal: remove special analyzer behavior for await expressions with "null context".

[stereotype441]

Background: I'm trying to update the expression inference rules in inference.md to match what was implemented, so that we can have a rigorous specification of the inference-update-3 logic I landed in https://dart-review.googlesource.com/c/sdk/+/353440. In the process I've discovered some subtle differences between the analyzer and front end type inference of await expressions. This issue addresses one such difference.

In the front end, type inference of an expression always takes place with respect to a type schema (the "context"). In the analyzer, type inference of an expression sometimes takes place with respect to a context, but sometimes takes place with respect to no context at all; the latter circumstance arises when the analyzer uses its standard AstVisitor mechanism to call one of the visit methods in the ResolverVisitor class, and so the visit method's contextType argument takes on the value null. Because of this I am calling this situation a "null context".

In all the circumstances where the analyzer infers an expression using a null context, the front end infers the same expression using a context of _. Furthermore, all but one of the analyzer's visit methods treat a null context the same as they treat a context of _. The one exception is visitAwaitExpression: in this method, if the context is the null context, then the analyzer analyzes the await expression's subexpression using a context of _; otherwise, it analyzes it using a context of FutureOr<_>. Whereas the front end, lacking any notion of a "null context", analyzes the await expression's subexpression using a context of FutureOr<_> in the same circumstances.

For the most part, the way contexts feed into the type inference algorithm is by appearing to the right of <# in the subtype constraint generation algorithm. This algorithm treats a right hand side of _ nearly identically to a right hand side of FutureOr<_>, so it is difficult to come up with an example of code that the analyzer and front end treat differently.

But we can exploit the special behavior of e1 ?? e2, which behaves as follows: if it is type inferred in context _, then e2 is type inferred using the static type of e1 as its context; whereas if it is type inferred in context K, then e2 is type inferred using K as its context.

So here is an example program that is analyzed differently:

Future<T> g<T>(T t) => Future.value(t);

extension on Future<int> {
  void foo() {}
}

test(Future<num>? f) async {
  await (f ?? (g(0)..foo()));
}

main() {}

This example is accepted by the front end, because:

• await (f ?? (g(0)..foo())) is inferred using a context of _.
• Therefore, f ?? (g(0)..foo()) is inferred using a context of FutureOr<_>.
• Therefore, g(0)..foo() is inferred using a context of FutureOr<_>.
• Therefore, g(0) is inferred using a context of FutureOr<_>.
• Since the return type of g is Future<T>, and that satisfies FutureOr<_> for all T, downwards inference of g(0) does not constrain the type of T. So the type of T is set to int during upwards inference.
• Therefore, g(0) has static type Future<int>.
• Therefore, ..foo() resolves to the extension method foo defined in extension on Future<int>.

But it is rejected by the analyzer, because:

• await (f ?? (g(0)..foo())) is inferred using a null context.
• Therefore, f ?? (g(0)..foo()) is inferred using a context of _.
• Therefore, g(0)..foo() is inferred using a context of Future<num>? (the static type of f).
• Therefore, g(0) is inferred using a context of Future<num>?.
• Since the return type of g is Future<T>, and that satisfies FutureOr<num>? only if T <: num, the type of T is set to num during downwards inference.
• Therefore, g(0) has static type Future<num>.
• Therefore, ..foo() does not resolve to the extension method foo defined in extension on Future<int>.

Whereas this program is accepted by both the anaylzer and front end:

Future<T> g<T>(T t) => Future.value(t);

extension on Future<int> {
  void foo() {}
}

test(Future<num>? f) async {
  var x = await (f ?? (g(0)..foo()));
}

main() {}

(The only difference is the addition of var x = before the await expression; this causes the analyzer to analyze the await expression using a context of _, just like the front end does).

I propose to base my update of the expression inference rules in inference.md on the front end's behavior in this corner case, and to change the analyzer's behavior to match the front end.

This change could in principle cause the analyzer to reject a program that it previously accepted, however I believe it's not necessary to go through the breaking change process, because any such program is already rejected by the front end.

@dart-lang/language-team any objections?

[stereotype441]

Note: I've separately proposed, in #3571, changing the inference rules for await expressions to reduce the proliferation of unnecessary FutureOrs in contexts. That change is much more potentially breaking than this one (and should probably be done in a language-versioned way), so I'm hoping to move forward with this change first.

[lrhn]

Sold. The "context type" type FutureOr<_> is a way of saying that we don't know what this is, or it's a future of something we don't know what is. That's not a good hint, it can't possibly help inference, so it's not a good context type. It can only get in the way of figuring out what the expression actually is.

Should we consider _? as just as useless? "This should be anything, or null".
Should we convert any top type to _?

Generally a union type with _ is meaningless and useless.

[eernstg]

SGTM!

[stereotype441]

Ok, I'm moving forward with this, via https://dart-review.googlesource.com/c/sdk/+/357521.

[stereotype441]

Fixed by dart-lang/sdk@f7d5d0c.