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>
Previously, when completing a future with another future,
we always chained to the other future. This effectively awaits
the latter future and then completes the former with its result.
This is incorrect behavior if the former future is, say,
a `Future<Future<int>>` and the latter is a `Future<int>`.
In that case we *must not* await the latter future
because we can't complete the former future with an `int`.
We should just complete the future directly with the latter future
as a value.
We now check first whether to chain a `Future<T>` to another
future, and only does so if the latter future is a `Future<T>`
(or it's not a `T`, which shouldn't happen,
but currently does in some places).
Add test for behavior.
Change-Id: I57e27111c2fc7b7792dcf4ae9b7c1d5d504d0c0f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/53602
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Users have seen event being sent *during* the `listen` call
to the underlying stream. This caught the `StreamIterator`
in an unanticipated state (subscription wasn't available yet).
Sending events during a `listen` call can currently happen
using a synchronous broadcast stream controller adding
events in the `onListen` callback.
That should be fixed so that broadcast stream subscriptions
are treated as paused during the `onListen` call like
single-subscription streams already are.
This change hardens the class against that particular malpratice,
but it's still possible to get into inconsistent states if the
`listen` call somehow manages to call back into the same
stream-iterator again. So, don't do that.
(The class also assumes that no stream will send events/call callbacks
* while paused.
* after cancelling
* after a done event
* while delivering another event.
If a stream does so, things will still crash.
It is believed that no platform stream will do any of these.)
Fixes#43779.
BUG= http://dartbug.com/43779
Change-Id: If47065cfa9a1115425fdf51b147f2ed7154fef99
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167800
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
The sync operations on a MultiStreamController did not check whether
sending events at the current time was allowed.
That could lead to `null` dereferencing errors when doing operations
on the controller after a cancel, and could cause events to appear
out of order.
Change-Id: I06b86a78959dfcaa402f74e2980a9d515f097dc9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159442
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
A generalized stream which provides a controller for each listener.
Can be used to implement both broadcast streams and single subscription streams,
as well as any stream behavior between the two.
Change-Id: I7a75f8736ca6bc91ce266e768db68536efd24dfe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150936
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
When we moved to make errors non-nullable in the async API, I added
legacy tests, but not NNBD tests because it is a static error in NNBD.
However, we've since started testing that null is caught dynamically
when flowing into those APIs from legacy code.
So this migrates those tests over.
Change-Id: I8002bacb45e947ef8c93dca10c7c1fd41afaa696
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152614
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Benchmarks (AOT):
- RunTime as Score (bigger is better):
- Iteration.deeptree.syncstar(x64): +3450%
- Iteration.concat.syncstar(x64): +28%
Note: Some other benchmarks (notably ForInGeneratedLoop) are to a
lesser degree negatively impacted since they use sync* in a way
that incurs the overhead without being able to see any of the benefit.
Bug: https://github.com/dart-lang/sdk/issues/37753
Change-Id: I003375ed5104623884bc1cf9c745ba992d0879c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144943
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
All these tests now pass in both weak and strong mode, except for
relation_subclass_test and typedef_reflected_type_test. For those 2
tests I fixed the compile time error and now they have the same runtime
errors in both weak and strong mode (they were already failing at
runtime in weak mode).
Change-Id: If0157f811fffcf72a12ce6690ac0568c8f4419a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144343
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
stream_controller_async_test and stream_join_test are built on
async_minitest, so most of the issues were fixed by migrating it to use
Never as the bottom type rather than Null.
Change-Id: I6f43e818a7a8d6793844166c8f9fc07b3b0f7a16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143562
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
It seems that there's some fiddliness when writing error handling
lambdas in strong mode.
async_await_sync_completer_test: The lambda was implicitly trying to
return the result of a throw, which was Never. I've switched it to this
syntax, which implicitly returns Null instead.
stream_iterator_test: The error handler needs to return a Bool, for
compatibility with the Future.
I'm open to suggestions for cleaner fixes to these bugs.
Change-Id: Ifc646a965d4b435512277da96ffb5e0b429114cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141164
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
A combination of `runZoned` and `runZonedGuarded` where only the latter allows an `onError` parameter,
and only that has a nullable return type.
Retains the `onError` parameter on `runZoned` for now because it's too breaking to remove it until packages have been migrated off of it.
It will be removed in a follow-up CL.
Change-Id: If0e86c8d14e13fa089c66f4af975aeacb2616cf6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/137302
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Lasse R.H. Nielsen