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>
There's a bundle of improvements here:
- Show the stack trace of the failure when a test using async_minitest
fails. The trade-off is that it now only reports the first failure.
Collecting all of them didn't play nice with the stack trace
deobfuscation the test runner does.
- Report the group and name of the test that failed when known.
- Fix as many double-reporting test result bugs as I could find. Also,
in case that still happens, don't spew out a pile of useless JSON.
- Correctly wait for a test to complete even if it schedules its own
asynchronous operations without returning futures.
- Generally simplify and clean some stuff up.
Change-Id: Ie020ae0b80a11764c455cf0ce24dfea09ca0adce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138903
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
It wasn't waiting for anything, so it would consider the test done
before the expectation was even reached. Went ahead and migrated it to
the simpler expect and async_helper libraries in the process.
Change-Id: I1d498980f34985bc5d54c5a514711143c689c199
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136080
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
This deletes:
tests/co19
tests/corelib
tests/html
tests/isolate
tests/language
tests/lib
It does not delete tests/standalone because apparently there are tests
in there that are not in standalone_2. (I assume they were added after
the test migration. I don't know why they were added there.)
I have tried to remove references to the old tests from various scripts
and tools but may have missed some. (As you can imagine, grepping for
"lib" does not have the best signal-to-noise ratio.)
"It was a pleasure to burn. It was a special pleasure to see things
eaten, to see things blackened and changed. With the brass nozzle in his
fists, with this great python spitting its venomous kerosene upon the
world, the blood pounded in his head, and his hands were the hands of
some amazing conductor playing all the symphonies of blazing and burning
to bring down the tatters and charcoal ruins of history."
- Ray Bradbury, Fahrenheit 451
Change-Id: If3db4a50e7a5ee25aff8058b1483e2ce8e68424e
Reviewed-on: https://dart-review.googlesource.com/c/75420
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Terry Lucas <terry@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This block felt trickier than others, mostly due to random errors that I
wasn't able to find a cause for. Tests that I'm uncertain about are:
-first_regression_test
-future_timeout_test
-future_or_bad_type_test/implements
These all have status entries to prevent failures, but I think these
tests need another set of eyes.
BUG=
R=rnystrom@google.com
Review-Url: https://codereview.chromium.org/2999943002 .
Dan Field