- Check against sending arbitrary classes via types.
- Stop allowing any object from dart:core, dart:collection, dart:typed_data (effectively reverts 807eacae30).
`SendPort.send` does not require such objects are sendable, and there is no guarantee the receiving isolate can represent them.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/50243
Change-Id: I7e9b0e9d83080d44a98b257cd8f2a58da5443a87
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/264725
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Allows for tests to pass with dart2wasm. This CL also adds these
tests to the test_matrix.json.
Change-Id: I970ef26b0fb377095c3889e6f52bef256d618850
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/264604
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
While export creation covers both exports and mocks, we only test
createDartExport here.
Change-Id: I85bd65193644930768fdab7dfae9d54cf5ad2e31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261765
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Tests the various checks needed for @JSExport and createDartExport,
with and without inheritance. Also renames the mock directory to export.
Change-Id: Iae0233f1080a2f12f20b46ba1a6b30aeb36843a8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/260743
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
* Use dartk as the default compiler for runtime=vm.
* Status file entries for checking for the `none` compiler now either
use dartk or are deleted.
Tested: Standard CQ and local testing.
Fixes: https://github.com/dart-lang/sdk/issues/50241
Change-Id: I7a08d3e491ae1c82a0348fb66ea7b557398f97e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/264682
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Bug: https://github.com/dart-lang/sdk/issues/49350
Checks to see that external extension members on `@staticInterop` types
do not declare or use a type parameter.
Change-Id: Id8646b599094b748c5490810b64d872065676014
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254103
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
To report at the token of the expected positional argument
Fixes#50127
Change-Id: I5eb31c6d354fb15d482c2046f7faaa4505658f4e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/262603
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Small --optimization-counter-threshold makes tests very slow,
especially on architectures where kernel service runs from
kernel and not from app-jit snapshot.
TEST=change in tests, *-ia32 bots
Fixes https://github.com/dart-lang/sdk/issues/48627
Change-Id: I63e7e201ef9a0e4f645016c39a5be1819b61822d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/263421
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Adds tests to check that various members are correctly mocked,
inheritance on both the Dart and @staticInterop side work as
expected with respect to mocking, and pkg:mockito can be used
with the new mocking functionality.
Change-Id: I7346339f15c14e934b045d75260c1e4540f89d0c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257161
Reviewed-by: Riley Porter <rileyporter@google.com>
Adds tests for the following cases:
- Type arguments to createStaticInteropMock
- Missing members in implementing class
- Members that need to be implemented through inheritance
- Members that implement through inheritance and mixins
- Implemented members are correct subtypes
- Static checker checks for potential extension conflicts
Change-Id: I866ba47189d8f397fe6a934af1c5ecb0b231aa68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256422
Reviewed-by: Riley Porter <rileyporter@google.com>
The package 'wasm' was moved to https://github.com/dart-lang/wasm in
063d0ef286.
Some of the tests for this package in pkg/wasm/test were duplicated
(probably with some changes) in tests/lib/wasm, and the commit that
moved the package to the new repo forgot to remove those duplicated
tests. This commit removes them.
Change-Id: I24ecbab99a383319482a2220623449bd516e6528
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/258926
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Ömer Ağacan <omersa@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>
This reverts commit 3688a4723c.
Reason for revert: b/244409289
Original change's description:
> Fix bug in Completer.complete.
>
> When given a completed `_Future`, it would complete its own future synchronously.
>
> Fixes#48493.
>
> Bug: https://github.com/dart-lang/sdk/issues/48493
> Change-Id: Ic4a68389b5a009ef52b3875bf03a3bafb493f79a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/234981
> 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.
Bug: https://github.com/dart-lang/sdk/issues/48493
Change-Id: I5ed360bebe160868f6152c72c82070c93188858e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257100
Reviewed-by: Ivan Inozemtsev <iinozemtsev@google.com>
Commit-Queue: Ivan Inozemtsev <iinozemtsev@google.com>
Reviewed-by: Lasse Nielsen <lrn@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 foregoes the optimization of removing CheckWritable if the unmodifiable views are not used from Dart code.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/49784
Change-Id: I18f3c36437ef136daf875358278caca4e3e0faa0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255816
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Adds static method on `Isolate` to run an asynchronous function
in a separate isolate.
Change-Id: I673373fa02524f1d0b88099027cfaf1b796eb344
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254960
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
These types now work with Dart_TypedDataAcquireData.
The presence of these types no longer degrades the performance of typed data indexed loads.
The presence of these types degrades the performance of typed data indexed stores much less. The performance of indexed stores is somewhat regressed if these types were not used.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/32028
Bug: https://github.com/dart-lang/sdk/issues/40924
Bug: https://github.com/dart-lang/sdk/issues/42785
Change-Id: I05ac5c9543f6f61ac37533b9efe511254778caed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253700
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Compilers named "dartdevc" and "dartdevk" should be listed together
at all locations. These are now aliases for the same compiler
across different configurations.
In the future these names should converge on "dartdevc".
Some skipped tests for "dartdevc" no longer need to be skipped but
currently there are no configurations are running those tests with
that compiler name so removing the skips shows no change in test
results.
Change-Id: Ieca27fbe497c4768293de125b14c694666dc8a8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253821
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Closes https://github.com/dart-lang/sdk/pull/49478
TEST=Manual
GitOrigin-RevId: f4c9c6869dfe73639295e86574a021523b3d374d
Change-Id: I134a97caed4eec59d70e9cbca16b7e9a472cf2c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251902
Reviewed-by: Michael Thomsen <mit@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Kevin Chisholm <kevinjchisholm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
On ia32 the CFE will run from a kernel file instead of an AppJit
snapshot. This is generally not that fast. In debug mode the JIT will
have various additional verifications turned on in the runtime (e.g.
flow graph checker runs, ...) - which will make it very slow.
So we should give all tests on debug-ia32 extra time.
TEST=ci
Change-Id: Ia2738a38c5cb50a4e830af23f663f205ab4c6593
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252360
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Types in constants and supertypes need to be visited in case
they include @staticInterop types.
Fixes a bug in caching in the constant replacer.
Change-Id: Icde8b7170a8806d6a1995cad57a9788893b7772f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249441
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Riley Porter <rileyporter@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 CL:
* Removed the redirect from .packages to .dart_tool/package_config.json
(whenever such a file existed).
* Removes support for the old format entirely.
* Updates all tests etc that were found.
Fixes https://github.com/dart-lang/sdk/issues/48939
TEST=Existing tests updated.
Change-Id: Iccf711c455ac1885189aa773ca74dd8f55012964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248603
Reviewed-by: Michael Thomsen <mit@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Jens Johansen <jensj@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>
Fixes#49241
TEST=ci
Change-Id: I6117bf816fc8c4613cce66927f952fef75632725
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248120
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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
69f32d6ad7
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>
Some JS functionality is only exposed through operators, such as
implicit type conversions and BigInt arithmetic. Other than requiring
some minor additions for the exponentiation (`**`) operator, supporting
these through `dart:js_util` is trivial.
Change-Id: I010674303e4f99b42d43b73095de69b8ddcdeb47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242680
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
