Make `Zone.createTimer`, `Zone.createPeriodicTimer` and `Zone.scheduleMicrotask`
not call register on the same zone.
These are low-level functions that should not build on top
of other low-level functions.
Instead the function is registered in the `Timer` constructors and
top-level `scheduleMicrotask` code, and the root zone's `createTimer`
and `scheduleMicrotask` just make sure that the callback will run
in its original zone, and that uncaught errors are handled in the
correct zone.
Avoids a double-registration that timers did.
Significant clean-up.
- The private `_Zone`, `_ZoneSpecification` and `_ZoneDelegate`
subclasses are not necessary now that their superclasses are `final`.
- Stopped using type aliases instead of function types
and old-style function arguments.
- Renamed some parameters to not be, fx, `f`.
Avoided some closure allocations for microtasks by putting the zone
into the queue entry, instead of wrapping the callback in a closure calling `zone.run`.
This is a potentially visible change if any code uses the zone functions
directly and expect them to invoke `Zone.register*`.
(Suspiciously no test failed with this change. May need to add some.)
Fixes#59913.
CoreLibraryReviewExempt: Have had all +1s, just not at the same time.
Bug: https://dartbug.com/59913
Change-Id: Ie3c87f5f22aedcbe30ab04718df98e1c0f0659c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/405020
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
The new formatter supports opting a region of code out from being
formatted. I'm applying this marker to all of the multitests since
those tests are often very sensitive to formatting and easily broken.
This way, anyone touching a multitest (including me when I reformat
the tests) doesn't have to remember to not run the formatter on it.
Change-Id: I34831719cd35e669b49e02a0d00c32b44068a34e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396103
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Makes `whenComplete` create a new future with either the result of the
original, or the error of a future returned by the callback.
Until now it was returning the original future, causing it to be chained after
it was completed. That caused issue with `ignore()`.
(Which suggests that there is still something iffy about ignore and chaining.)
Combines `chainCoreFuture{Sync,Async}` into one function with boolean flag.
Most of the code is the same, and they had accidentally drifted apart.
Fixes#56806.
CoreLibraryReviewExempt: Should be simple refactoring.
Tested: Regression test added
Bug: http://dartbug.com/56806
Change-Id: I52751c078a4e26a10e9da0a64460e2c5c7f34ae5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/387360
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Collects files from `package:async_helper` and `tests/language`
that are generally useful, so that all test-related helpers are
in `package:expect`.
Moves the two libraries from `package:async_helper` into `package:expect`,
and the `tests/language/static_type_helper.dart` file too.
Deprecates `async_minitest.dart`, to follow `minitest.dart`,
expecting the Flutter use of it to have been fixed to not break
on deprecation (I believe Flutter no longer breaks builds on deprecations at all).
Patch 1 is the actual change.
Patch 2+4+8 is changing all existing references to the files.
Patch 6 ignores deprecation in files still using `async_minitest.dart`.
3+5+7+9 are updating this text to make the numbers match.
Then it's just test-expectations and small tweaks from there.
Change-Id: I1b665135b5fef9b9a0c3b340ffe9daf874d0174c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373120
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Also removed a bunch of `CheckNotNullable`s that shouldn't be necessary any more. Any remaining non-sound-null-safety code runs today, and no more should be written. (And if it is, it'll mostly just err somewhere else, with a worse error message.)
Tested: New test added. Removed older tests checking for unsound null-safety.
Change-Id: I28626909cd8c1f91db6c61fc2b93042ed1b085dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/380780
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This never worked. It was silently accepted, at least if the future had no listeners, then any later attempt to use the future would cause a stack overflow or other impossible results.
Moves some `_Future._complete` call out of try-catch.
The `_complete` shouldn't throw (but before this fix it could).
Moving them out of the `try`/`catch` makes such errors be reported
as unhandled, instead of catching them and trying to complete the same
future again with an error, when it's possibly in an inconsistent state.
Fixes#43662.
Based on https://github.com/dart-lang/sdk/issues/43662#issuecomment-2058870247
CoreLibraryReviewExempt: No response.
Bug: http://dartbug.com/43662
Change-Id: I96a4f01bcd5b6cee93bba267299852569a9b905c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363060
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit cd2c566bcf.
Reason for revert: Updating to not remove field used by Flutter engine.
Original change's description:
> Revert "Tweak `expect.dart` library."
>
> This reverts commit ff5f391c0a.
>
> Reason for revert: The expect library is used by Flutter engine, and some of its tests use assertStatementsEnabled. There should be a migration path that doesn't require an atomic change, like adding the replacement api before removing the old one.
>
> Original change's description:
> > Tweak `expect.dart` library.
> >
> > Make API more consistent for a few methods.
> > Reduce the number of language features used in tests:
> > * Never iterating an iterable, always converting it
> > using `.toList()` first and iterating using indices
> > (fx `setEquals`).
> > Also require a `List` in places where an `Iterable`
> > wasn't necessary.
> > * Avoid doing complicated computations that are also
> > used for the error message. Do simple check first,
> > then recompute to get better error messages
> > (fx `allDistinct`).
> >
> > Renamed some rarely used members for consistency
> > (`stringContainsInOrder`->`containsInOrder`,
> > where other string-contains functions just start
> > with `contains`, and `containsOneOf` -> `containsAny`
> > to match `Iterable.any` phrasing, and also it accepts
> > if containing at least one, not precisely one.)
> >
> > Removed a function that wasn't used anywhere.
> >
> > Moved `assertStatementsEnabled` to `variations.dart` as `asserts`.
> > Removed `typeAssertionsEnabled` and `checkedModeEnabled`. The former used in one place, where it was replaced with `checkedImplicitDowncasts` from `variations.dart`, the latter wasn't used anywhere.
> >
> > Deprecates `package:expect/minitest.dart`. It was never intended
> > to be used for new tests, only as a help to convert existing tests
> > written against `package:unit_test`.
> > All existing imports marked as `// ignore: deprecated_member_use`.
> >
> > Change-Id: I07e21d4c0f3ccf11b82ee34af2668fdbb22264d2
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352360
> > Reviewed-by: Slava Egorov <vegorov@google.com>
> > Reviewed-by: Ömer Ağacan <omersa@google.com>
> > Reviewed-by: Nate Bosch <nbosch@google.com>
> > Reviewed-by: Stephen Adams <sra@google.com>
> > Commit-Queue: Lasse Nielsen <lrn@google.com>
>
> Change-Id: I360b4347470a0bb2b63c3108e2b83ee2a771bf3f
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362020
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Reviewed-by: Ömer Ağacan <omersa@google.com>
> Reviewed-by: Stephen Adams <sra@google.com>
> Reviewed-by: Leaf Petersen <leafp@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: William Hesse <whesse@google.com>
CoreLibraryReviewExempt: Reland
Change-Id: I53db40edc0733842a008839c3913d51c885e39ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362502
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reverts commit ff5f391c0a.
Reason for revert: The expect library is used by Flutter engine, and some of its tests use assertStatementsEnabled. There should be a migration path that doesn't require an atomic change, like adding the replacement api before removing the old one.
Original change's description:
> Tweak `expect.dart` library.
>
> Make API more consistent for a few methods.
> Reduce the number of language features used in tests:
> * Never iterating an iterable, always converting it
> using `.toList()` first and iterating using indices
> (fx `setEquals`).
> Also require a `List` in places where an `Iterable`
> wasn't necessary.
> * Avoid doing complicated computations that are also
> used for the error message. Do simple check first,
> then recompute to get better error messages
> (fx `allDistinct`).
>
> Renamed some rarely used members for consistency
> (`stringContainsInOrder`->`containsInOrder`,
> where other string-contains functions just start
> with `contains`, and `containsOneOf` -> `containsAny`
> to match `Iterable.any` phrasing, and also it accepts
> if containing at least one, not precisely one.)
>
> Removed a function that wasn't used anywhere.
>
> Moved `assertStatementsEnabled` to `variations.dart` as `asserts`.
> Removed `typeAssertionsEnabled` and `checkedModeEnabled`. The former used in one place, where it was replaced with `checkedImplicitDowncasts` from `variations.dart`, the latter wasn't used anywhere.
>
> Deprecates `package:expect/minitest.dart`. It was never intended
> to be used for new tests, only as a help to convert existing tests
> written against `package:unit_test`.
> All existing imports marked as `// ignore: deprecated_member_use`.
>
> Change-Id: I07e21d4c0f3ccf11b82ee34af2668fdbb22264d2
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352360
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Reviewed-by: Ömer Ağacan <omersa@google.com>
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Reviewed-by: Stephen Adams <sra@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
Change-Id: I360b4347470a0bb2b63c3108e2b83ee2a771bf3f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362020
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: William Hesse <whesse@google.com>
Make API more consistent for a few methods.
Reduce the number of language features used in tests:
* Never iterating an iterable, always converting it
using `.toList()` first and iterating using indices
(fx `setEquals`).
Also require a `List` in places where an `Iterable`
wasn't necessary.
* Avoid doing complicated computations that are also
used for the error message. Do simple check first,
then recompute to get better error messages
(fx `allDistinct`).
Renamed some rarely used members for consistency
(`stringContainsInOrder`->`containsInOrder`,
where other string-contains functions just start
with `contains`, and `containsOneOf` -> `containsAny`
to match `Iterable.any` phrasing, and also it accepts
if containing at least one, not precisely one.)
Removed a function that wasn't used anywhere.
Moved `assertStatementsEnabled` to `variations.dart` as `asserts`.
Removed `typeAssertionsEnabled` and `checkedModeEnabled`. The former used in one place, where it was replaced with `checkedImplicitDowncasts` from `variations.dart`, the latter wasn't used anywhere.
Deprecates `package:expect/minitest.dart`. It was never intended
to be used for new tests, only as a help to convert existing tests
written against `package:unit_test`.
All existing imports marked as `// ignore: deprecated_member_use`.
Change-Id: I07e21d4c0f3ccf11b82ee34af2668fdbb22264d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352360
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Gives the constructor optional parameters for providing
more information that can be used in the `toString` message,
and the `stackTrace` getter.
Makes the `iterable.wait` and `record.wait` extension methods
provide such information, so that the `toString` will always
contain the text of *one* of the errors.
(No issue, problem with logging was brought up in chat.)
Change-Id: I5f9a20ad0af0c64a2e7ff3cdb56f187a5cf5a3ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353080
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
If a target `_Future` is chained to another source `_Future`,
then it's because the target will complete with the same
result as the source future. Instead of keeping both
alive with a listener on the source which completes the target,
instead the target moves all its listeners to be directly on
the source, and keeps a link to the source in case more listeners
are added later.
The idea is that most futures are unreferenced after they have
had their first listener, so the target future has a chance
to be GC'ed.
If the target future has `.ignore()` called, and has no listener,
then the source completing with an error should not cause the
error to be uncaught. Without the optimization, the source would
have had a listener, and the target would ignore the error.
To simulate that, the source now gets a copy of the target's
`_ignoreUnhandledErrors` flag.
This is still not precisely the same as it would be without the
optimization. If *two* target futures are chained to the same source,
and only one of targes has `.ignore()` called, then this
implementation will make the uncaught error not be reported,
where it technically should.
(An alternative would be to *not* use chaining for futures
with `ignore()` called on them. But those are precisely futures
that are likely to be GC'able, because someone has already said
that they don't care if the future complete with errors.)
Fixes#54943
Bug: https://github.com/dart-lang/sdk/issues/54943
Change-Id: I0dbb4919ce2ea612d66539862fa0eb188aab8287
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352908
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Address comments from Lasse in
https://dart-review.googlesource.com/c/sdk/+/331210. Namely:
* Use 100ms for the interval, so avoid overlap with the safety-margin of 40ms
* Rewrite comment to only discuss the safety margin in terms of an early
dispatch
* Only use the safety margin on web backends. Unlike timer_test, I am
using the presence of `dart.library.js` instead. Going forward it's
possible that dart2wasm hits this issue if it relies on browser's
timers.
I also copied the changes to lib_2 since flakiness is seen there too.
Change-Id: I71b6365346cccc7667dbe3da809b1bfd192ff38a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333057
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The underlying subscription would invoke the `onDone` handler even
after a `cancel`.
It also forgot to register the `onDone` callback in the zone before
running it.
Tweaked the behavior of `pause` and `resume` to make sure they make
no difference after `cancel` or after a done event has been omitted.
(Test now checks that the behavior matches other streams.)
Fixes#53201
Bug: https://dartbug.com/53201
Change-Id: Iba35be2c4b44b5c4ec97d5a4dbcd3aff7fee8b75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320561
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Breaking change request: https://dartbug.com/52334
Four abstract pure-interface classes in `stream.dart` have
been missed, and not made into `interface` declarations
like other similar abstract interface-only classes.
They should be marked `interface`, for consistency,
and to express intent.
The classes are:
* `StreamConsumer`
* `StreamIterator`
* `StreamTransformer`
* `MultiStreamController`
All are abstract classes with only abstract instance members.
Only `StreamConsumer` has uses where it is extended.
Most of those are inside the SDK, and are fixed here.
Two more are in packages (`http_server` and `streams`).
The former is discontinued and archived, and will never have a 3.0
release. The latter is internally developed and easy to fix.
Hope to cherry pick this for 3.0.3
Tested: Modified affected tests. Only adding restrictions.
CoreLibraryReviewExempt: Adding modifiers only.
Change-Id: I41aa47e48eaf769b7bd9d3206c1079a16ef3d476
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302204
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
With the addition of records, it now makes sense to create an API
for parallelizing of futures of different types, like `Future.wait`
does for collections of same-typed futures.
The `wait` getters here apply to tuples of 2-9 futures of distinct types, which should be enough for most reasonable uses.
Planned addition for Dart 3.0.
CoreLibraryReviewExempt: Everybody's on vacation, everybody everywhere.
Change-Id: Iaa814e02e2274082bb8a29b9a18b4930bcc953bb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288903
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reverts commit 9292afa710.
Reason for revert: b/244407576
Original change's description:
> Make `addStream` events be delivered synchronously.
>
> The asynchronous stream controllers were forwarding stream events
> from an `addStream` stream through the same path as user-added event,
> which added an extra asynchronous delay that is unnecessary for forwarding existing events.
>
> Change-Id: I8edd1936d0d155d051d3cb8f7f82c577334d5f8e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256560
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I0e4791f4d32616fee9772a2ab7015bac4e117312
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257080
Auto-Submit: Ivan Inozemtsev <iinozemtsev@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Ivan Inozemtsev <iinozemtsev@google.com>
The asynchronous stream controllers were forwarding stream events
from an `addStream` stream through the same path as user-added event,
which added an extra asynchronous delay that is unnecessary for forwarding existing events.
Change-Id: I8edd1936d0d155d051d3cb8f7f82c577334d5f8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256560
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reverts commit c97f7b7fad.
Reason for revert: Still breaking google3 (b/236665701)
Original change's description:
> 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 a247b158d6
>
> 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>
TBR=lrn@google.com,eernst@google.com,nbosch@google.com
Change-Id: I870285b03ec05803c5aaa6b66f9a6e6ea360d732
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249609
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
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 a247b158d6
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>
This reverts commit 4d750a862d.
Reason for revert: breaks google3 (b/236665701)
Original change's description:
> 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 a247b158d6
>
> Change-Id: Ia113756de1f6d50af4b1abfec219d6b4dcd5d59b
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249488
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,nbosch@google.com
Change-Id: I02d62d58bae33d6a606a80eb3eee2e8e721a8e20
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249620
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
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 a247b158d6
Change-Id: Ia113756de1f6d50af4b1abfec219d6b4dcd5d59b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249488
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reverts commit a247b158d6.
Reason for revert: breaks google3. See b/236665701.
Original change's description:
> 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.
>
> Change-Id: Ibe204eaabe175cbcbcb7822ca1f2bcdda72a478c
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248660
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,nbosch@google.com
Change-Id: Ic765eb1401dbff4dea6c08c007c0bf9aff186684
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249188
Reviewed-by: Oleh Prypin <oprypin@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
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.
Change-Id: Ibe204eaabe175cbcbcb7822ca1f2bcdda72a478c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248660
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
The current implementation uses a specialized version of the
pending-event queue used by stream subscriptions to remember
pending events.
That makes the queue polymorphic, and slightly more complicated than
necessary, and that again makes further refactorings of the
Stream implementation harder.
This change moves the logic from the specialized pending-queue
into a simple function instead, so you only pay for it if you
actually use `Stream.fromIterable`.
Also allows `Stream.fromIterable` to be listened to more than once.
(It uses `Stream.multi` for the general async+sync controller API,
and it would cost extra code to make it only work once.)
Change-Id: I44b2010225cd3d32c2bcdb8a315c94881331bdae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248146
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reverts commit 69f32d6ad7.
Reason for revert: We seem to have a number of tests failing with timeouts in CBUILD after this change, please see logs at
https://dart-in-g3-qa-prod.corp.google.com/dg3/Home#/cbuild/find/69f32d6ad7e724e3148cb2eb6601e63165e76ad3
Original change's description:
> Refactor `_Future`.
>
> This is a major rewrite of the `_Future` class,
> which is the default implementation of the `Future` interface.
>
> The main goal was to reduce the number of expensive type checks
> in the internal passing around of data.
> Expensive type checks are things like
> * `is _Future<T>` (more expensive than just `is _Future`, the latter
> can be a single class-ID check.
> * Covariant generic parameter checks (using `T` covariantly in a
> parameter forces a run-time type check).
>
> Also removed some plain unnecessary casts and turned some
> implicit casts from `dynamic` into `unsafeCast`s.
>
> This seems to be an success, at least on very primitive benchmarks, according to Golem:
> FutureCatchErrorTest 41.22% (1.9 noise)
> FutureValueTest 46.51% (2.8 noise)
> EmptyFutureTest 59.15% (3.1 noise)
> FutureWhenCompleteTest 51.10% (3.2 noise)
>
> A secondary goal was to clean up a very old and messy class,
> and make it clearer for other `dart:async` how to interact
> with the future.
>
> The change has a memory cost: The `_FutureListener<S,T>` class,
> which represents a `then`, `catchError` or `whenComplete`
> call on a `_Future`, now contains a reference to its source future,
> the one which provides the inputs to the callbacks,
> as well as the result future returned by the call.
> That's one extra memory slot per listener.
>
> In return, the `_FutureListener` now does not need to
> get its source future as an argument, which needs a covariant
> generic type check, and the methods of `_Future` can be written
> in a way which ignores the type parameters of both `_Future`
> and `_FutureListener`, which reduces complex type checks
> significantly.
>
> In general, typed code is in `_FutureListener`, which knows both
> the source and target types of the listener callbacks, and which
> contains the futures already at that type, so no extra type checking
> is needed.
> The `_Future` class is mostly untyped, except for its "public"
> API, called by other classes, which checks inputs,
> and code interacting with non-native futures.
> Invariants ensure that only correctly typed values
> are stored in the untyped shared `_resultOrListeners` field
> on `_Future`, as determined by its `_state` integer.
> (This was already partially true, and has simply been made
> more consistent.)
>
> Further, we now throw an error in a situation that was previously
> unhandled: When a `_Future` is completed with *itself*.
> That would ensure that the future would never complete
> (it waits for itself to complete before it can complete),
> and may potentially have caused weird loops in the representation.
> In practice, it probably never happens. Now it makes the error
> fail with an error.
> Currently a private `_FutureCyclicDependencyError` which presents
> as an `UnsupportedError`.
> That avoids code like
> ```dart
> import "dart:async";
> void main() {
> var c = Completer();
> c.complete(c.future); // bad.
> print("well!");
> var d = Completer();
> d.complete(c.future);
> print("shucks!");
> }
> ```
> from hanging the runtime by busily searching for the end of a cycle.
>
> See https://github.com/dart-lang/sdk/issues/48225
> Fixes#48225
>
> TEST= refactoring covered by existing tests, few new tests.
>
> Change-Id: Id9fc5af5fe011deb0af3e1e8a4ea3a91799f9da4
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244241
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,kustermann@google.com,sra@google.com,sigmund@google.com,nshahan@google.com
Change-Id: I455be5a04b4c346df26d4ded0fa7388baccb0f8c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247762
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This is a major rewrite of the `_Future` class,
which is the default implementation of the `Future` interface.
The main goal was to reduce the number of expensive type checks
in the internal passing around of data.
Expensive type checks are things like
* `is _Future<T>` (more expensive than just `is _Future`, the latter
can be a single class-ID check.
* Covariant generic parameter checks (using `T` covariantly in a
parameter forces a run-time type check).
Also removed some plain unnecessary casts and turned some
implicit casts from `dynamic` into `unsafeCast`s.
This seems to be an success, at least on very primitive benchmarks, according to Golem:
FutureCatchErrorTest 41.22% (1.9 noise)
FutureValueTest 46.51% (2.8 noise)
EmptyFutureTest 59.15% (3.1 noise)
FutureWhenCompleteTest 51.10% (3.2 noise)
A secondary goal was to clean up a very old and messy class,
and make it clearer for other `dart:async` how to interact
with the future.
The change has a memory cost: The `_FutureListener<S,T>` class,
which represents a `then`, `catchError` or `whenComplete`
call on a `_Future`, now contains a reference to its source future,
the one which provides the inputs to the callbacks,
as well as the result future returned by the call.
That's one extra memory slot per listener.
In return, the `_FutureListener` now does not need to
get its source future as an argument, which needs a covariant
generic type check, and the methods of `_Future` can be written
in a way which ignores the type parameters of both `_Future`
and `_FutureListener`, which reduces complex type checks
significantly.
In general, typed code is in `_FutureListener`, which knows both
the source and target types of the listener callbacks, and which
contains the futures already at that type, so no extra type checking
is needed.
The `_Future` class is mostly untyped, except for its "public"
API, called by other classes, which checks inputs,
and code interacting with non-native futures.
Invariants ensure that only correctly typed values
are stored in the untyped shared `_resultOrListeners` field
on `_Future`, as determined by its `_state` integer.
(This was already partially true, and has simply been made
more consistent.)
Further, we now throw an error in a situation that was previously
unhandled: When a `_Future` is completed with *itself*.
That would ensure that the future would never complete
(it waits for itself to complete before it can complete),
and may potentially have caused weird loops in the representation.
In practice, it probably never happens. Now it makes the error
fail with an error.
Currently a private `_FutureCyclicDependencyError` which presents
as an `UnsupportedError`.
That avoids code like
```dart
import "dart:async";
void main() {
var c = Completer();
c.complete(c.future); // bad.
print("well!");
var d = Completer();
d.complete(c.future);
print("shucks!");
}
```
from hanging the runtime by busily searching for the end of a cycle.
See https://github.com/dart-lang/sdk/issues/48225Fixes#48225
TEST= refactoring covered by existing tests, few new tests.
Change-Id: Id9fc5af5fe011deb0af3e1e8a4ea3a91799f9da4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244241
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
The associated `unawaited_futures` lint triggers for expressions
of type `Future?` as well, so we should allow the workaround to
handle such expressions.
This change makes a static function more permissive, and is not expected
to be breaking in any way.
(It does mean that you need Dart 2.15.0 to use the function with
nullable arguments. I've changed the annotation to say `@Since("2.15")`.
That means anyone using a 2.15 SDK should assume that they need a 2.15
SDK to use it, and someone using a 2.14 SDK will not see the argument
as nullable. If anyone uses `@Since` annotations for anything at all.)
Change-Id: Ib2da4b353104cc88a834208a6ebd788ae55b4544
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214406
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
The `unawaited` function in `dart:async` is intended for use with the `unawaited_futures` lint which is hopefully going to be part of the Dart recommended set of lints.
The `ignore` extension method is there to provide an alternative if you even want to ignore errors from a future. By having both, it makes the distinction clearer and makes it easier to not think one can be used for everything.
Change-Id: Ib96ed5ff64ead4b228721e5210efa82f76119c9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200428
Reviewed-by: Jacob Richman <jacobr@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Robert Nystrom