commit c97f7b7fadca5b6a3e220a20dbefd4eaa3b442ba
author Lasse R.H. Nielsen <lrn@google.com> Fri Jun 24 11:32:30 2022 +0000
committer Commit Bot <commit-bot@chromium.org> Fri Jun 24 11:32:30 2022 +0000
tree f30780c8d6349c4e0b0476384a90ae4e53955363
parent db6b2679e6576df3c785ec20e9c75565c4b48055

Make `nullFuture` be per-zone.

We introduced a `nullFuture` during the null-safety migration where
we changed some methods to no longer allow returning `null`,
and they therefore had to return a `Future`.
That affected timing, because returning `null` was processed
synchronously, and that change in timing made some tests fail.
Rather that fix the fragile tests, we made the function return
a recognizable future, a canonical `Future<Null>.value(null)`,
and then recognized it and took a synchronous path for it.

That caused other issues, because the future was created in the
root zone. (Well, originally, it was created in the first zone
which needed one, that was worse. Now it's created in the root zone.)
Some code tries to contain asynchrony inside a custom zone, and
then the get a `nullFuture` and calls `then` on it, and that
schedules a microtask in the root zone.
(It should probably have used the listener's zone, and not store
a zone in the future at all, but that's how it was first done,
and now people rely on that behavior too.)

This change creates a `null` future *per zone* (lazily initialized
when asked for). That should be sufficient because the code recognizing
a returned `null` future is generally running in the same zone,
but if any other code gets the `nullFuture`, it will be in the
expected zone for where it was requested.

This is a reland of commit a247b158d6fc2ae89e824080bd7877e7b51f642a

Change-Id: Ieec74d6f93c57175c357ec18889144635f5bdca6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249490
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>