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>
Static class members could technically be mapped to a name with dots,
but in the early days of JSInterop we thought this was not necessary
since it could also be modeled as a top-level member or by adding
additional classes and exposing the member as a simple name on a deeper
class.
This invariant was assumed by DDC (which crashed if this was not the
case) and ignored by dart2js.
This change adds a static check to ensure both compilers act
consistenlty.
Fixes https://github.com/dart-lang/sdk/issues/27926
Change-Id: I20e59fbb75f0378a58ca88dc3910e079b4eeb7a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247180
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Riley Porter <rileyporter@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>
Adds an experimental `@trustTypes` annotation which can be used during
migration to static interop to preserve the older semantics for JS interop.
Change-Id: Ic00a6c968b15f8c8f5d0840b82db5a6670eaf0eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241362
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
The current VM closure serialization makes this function a foot-gun.
Revert until the supporting features are improved, so as to not give
users a bad experience.
Change-Id: I83b6b453ce5ab00d49ffbf36a5763119a6435352
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237940
Reviewed-by: Michael Thomsen <mit@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Closes https://github.com/dart-lang/sdk/issues/48630
'mark' can return undefined in Firefox, and therefore needs to
return a nullable. Similarly, the different syntaxes of 'measure'
don't work in Firefox or Safari, so the incompatible ones are
removed from tests.
Change-Id: Ia137fe0d72ddbaad03ae8cf58c43736b128b3f33
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237930
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/48430
Adds overloads for both methods to accept additional/different options.
Also changes return types:
- mark returns a PerformanceEntry
- measure returns a PerformanceMeasure, but this may be undefined, so it's
marked as nullable
Change-Id: I189c4613b19e214a1f5bcc5bbd780d9dc447d9e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235286
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Should make this test run within the normal timeout period.
TEST=ci
Change-Id: Ie8048a6cc7c31b193cf326bf9742fad279411b44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237688
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Failed to close the receive-port if `Isolate.spawn` threw
asynchronously, which would keep the isolate alive forever.
Fixes#48516
BUG= http://dartbug.com/48516
Change-Id: If53a868bcc6a11aef9123e95a7dfe47d25932c4c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235603
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Closes https://github.com/dart-lang/sdk/issues/48515
Expands existing checks for index operations to all operators. This
only affects instance members and not extension members.
Change-Id: I8cbb5b12a49539ea502e4396e1b469ffb0e17d5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235980
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/47520
decodeAudioData has an older callback-based syntax and newer
Promise-based syntax. In order to be consistent with the method
signature as well as be able to use both syntaxes, this CL
provides an API that can handle both.
Change-Id: I875defcfec9e429496a1ac9866f1b53d204eff69
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/221744
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Right now the implementation of `Isolate.spawnUri(<uri>, ...)` in
the standalone embedder is to ignore `<uri>` and make the spawnned
isolate from the same AOT snapshot as the main isolate.
This is very confusing and very incorrect.
Instead `Isolate.spawnUri()` should work if-and-only-if the given
`<uri>` points to a valid and compatible AOT snapshot. If not, it should
throw an appropriate exception.
Fixes https://github.com/dart-lang/sdk/issues/48375
Fixes https://github.com/dart-lang/sdk/issues/48326
TEST=vm/dart{,_2}/spawn_uri_aot_test
Change-Id: I279ace08ac1b9a9eed3ae03ebe5d9e2336c1e5c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232603
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This CL implements `WeakReference` in the VM.
* This reduces the size of weak references from 2 objects using 8 words
to 1 object using 4 words.
* This makes loads of weak reference targets a single load instead of
two.
* This avoids the fix-point in the GC and message object copying for
weak references. (N.b. Weak references need to be processed _after_
the fix-point for weak properties.)
The semantics of weak references in messages is that their target gets
set to `null` if the target is not included in the message by a strong
reference.
The tests take particular care to exercise the case where a weak
reference's target is only kept alive because a weak property key is
alive and it refers to the target in its value. This exercises the fact
that weak references need to be processed last.
Does not add support for weak references in the app snapshot. It would
be dead code until we start using weak references in for example the
CFE.
This CL does not try to unify weak references and weak properties in
the GC or messaging (as proposed in go/dart-vm-weakreference), because
their semantics differ enough.
Closes: https://github.com/dart-lang/sdk/issues/48162
TEST=runtime/tests/vm/dart/finalizer/weak_reference_run_gc_test.dart
TEST=runtime/tests/vm/dart/isolates/fast_object_copy_test.dart
TEST=runtime/vm/object_test.cc
TEST=tests/lib/isolate/weak_reference_message_1_test.dart
TEST=tests/lib/isolate/weak_reference_message_2_test.dart
Change-Id: I3810e919a5866f3ae8a95bd9aa23a880a0b0921c
Cq-Include-Trybots: luci.dart.try:app-kernel-linux-debug-x64-try,dart-sdk-mac-arm64-try,vm-canary-linux-debug-try,vm-fuchsia-release-x64-try,vm-kernel-gcc-linux-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-linux-debug-x64c-try,vm-kernel-linux-debug-x64-try,vm-kernel-linux-debug-simriscv64-try,vm-kernel-mac-debug-x64-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-nnbd-linux-release-ia32-try,vm-kernel-nnbd-linux-release-simarm64-try,vm-kernel-nnbd-linux-release-simarm-try,vm-kernel-nnbd-mac-debug-arm64-try,vm-kernel-nnbd-mac-debug-x64-try,vm-kernel-nnbd-win-release-ia32-try,vm-kernel-nnbd-win-release-x64-try,vm-kernel-optcounter-threshold-linux-release-x64-try,vm-kernel-precomp-android-release-arm_x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try,vm-kernel-precomp-win-debug-x64c-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-kernel-win-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232087
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Use `hasScheme` in place of comparing against the empty string, and
`isScheme` to compare against all other schemes.
TEST=No behavior changes.
Change-Id: Ifc9fd13c6cf37933ebd4a754c4b500dedbcb291b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231185
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Add dynamic to JS foreign function calls to get implicit
downcast to T, which will cause more accurate type errors
for DDC and dart2js with -O2. Checks will be omitted
with dart2js and -O3.
Bug: #47832
Change-Id: Ie85faf47d58d748b068bc7e902a17a99292f02e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/230823
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Riley Porter <rileyporter@google.com>
Closes https://github.com/dart-lang/sdk/issues/25324
requestFullscreen returns a Promise and takes in an options parameter.
It also can be accessed either via `requestFullscreen` or
`webkitFullscreen` (only necessary for Safari). The bindings should be
updated to reflect this behavior.
Change-Id: I9401b6a1c8b3f9ac370aad8caac8295e0ee358b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/229381
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
For `asyncExpectThrows`, instead of taking a function,
then checking if that function can be called with zero arguments,
and then immediately calling it and checking that it returns a future,
just take the future as argument.
Since synchronus errors from calling the function were not caught
anyway, doing the entire `Future` computation directly shouldn't
change behavior.
Also make `asyncExpectThrows` and `Expect.throws` return the caught error,
so that you can use normal `Expect.something` checks on it afterwards,
instead of doing that in the `check` function.
That basically makes the `check` function unnecessary (but hard to remove
with the existing test corpus using it heavily).
This makes some uses of the `asyncExpectThrows` function slightly more
complicated, those that have no other way to create a future than calling
the argument function anyway, but other uses become simpler
when they can avoid adding the function wrapper.
TEST= Refactoring. If the tests keep running, it's successful.
Change-Id: I983eb65ea4805760339073fabc27f78c57f9a471
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/226102
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Part 2 of the renaming to create the new parent type. Also modifies
some existing tests to reflect the change in name and function of
JavaScriptObject.
Change-Id: If37f34dd8477b7fc1fe459d3225ecf2537fb9f1a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217156
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Changes in type hierarchy will have JavaScriptObject as the new
parent class of interop and native types instead. Also modifies
js_interop_constructor_name tests to reflect addition of static
interop.
Change-Id: I74957ca89aea1726a01e0677548fbb3c5c981323
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215949
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Remove messages referring to expired `non-nullable` experiment.
Remove occurrences of --enable-experiment with expired experiments.
TEST=Flags were expired. If existing tests still run, it's a success.
Change-Id: Id66d78eb0a3191ec5e31375faf0effd9ea7b768f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219789
Auto-Submit: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This is a preparation CL to remove the --enable-isolate-groups flag in
the VM.
The following tests were only running in --no-enable-isolate-groups and
are therefore obsolete now:
- runtime/tests/vm/dart/regress_47468_test.dart
- runtime/tests/vm/dart_2/regress_47468_test.dart
- tests/lib/isolate/illegal_msg_function_test.dart
- tests/lib_2/isolate/illegal_msg_function_test.dart
TEST=Changes tests only.
Change-Id: I6257cb667eebca66a649614d3010139dd2cdd3ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219100
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The WebSQL standard was abandoned more than 10 years ago and is not
supported by many browsers.
The `dart:web_sql` library was marked as deprecated in Dart 2.14. This
CL makes the library inaccesible, removes support for `dart:web_sql` imports,
and removes the `Window.openDatabase` API. The old code for `dart:web_sql` is
still generated by the html generators. Removing that will be handled by a
separate change.
Closes https://github.com/dart-lang/sdk/issues/46316
Change-Id: I892107396b3b227b4f33344377585aa5e5328288
Bug: https://github.com/dart-lang/sdk/issues/46316
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216080
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
These were unnecessarily added twice when I finished out the rest of the
constant rename fixes, but had already been implemented as the proof of
concept for core library fixes.
Change-Id: I4c5bb018ad344ccb4c393c656fed47aae2df4d16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214066
Auto-Submit: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The existing lib/isolate/stacktrace_message_test was failing and also
incorrectly written due to "!" in front of the expected stringification
of the stacktrace.
Issue https://github.com/dart-lang/sdk/issues/46623
TEST=vm/dart{,_2}/isolates/fast_object_copy2_test, lib{,_2}/isolate/stacktrace_message_test
Change-Id: I169d8fd7a7c3cb3b8c57e00287565e3a5c622acf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216041
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Adds @staticInterop annotation to allow users to declare static interop
classes. Also adds errors for erroneous usage of static interop
classes, like including instance members or using a non-static
supertype.
Change-Id: I21abafbf6ea6c2eb7cd0425f0a54c1ba35d6ec6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215010
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This exits current isolate immediately. If [port] is provided, then [message] is verified and sent out as isolate exits.
TEST=ci
Fixes https://github.com/dart-lang/sdk/issues/47164
Change-Id: I513f4d7ceb5d74820f4aee60f5799b7b5193f2e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214312
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@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>
CFE transformation to add a function body for external
extension methods. Routes to `js_util.callMethod` with the
arguments in a ListLiteral to then be further optimized to
the `callMethodUnchecked` version if possible.
Change-Id: Iccdda7b8c16c19b37e20b7cbceb8c32498e64d3b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213721
Commit-Queue: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
CFE transformation to add a function body for external fields,
getters, and setters, routing to the relevant js_util
getProperty and setProperty optimized calls.
Change-Id: Ia3d0f05fda50f20d217c0a67e0fd636bb774000b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213600
Commit-Queue: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Add fix definitions and tests for renamed class and top level constants in
`dart:developer` and `dart:io`.
Change-Id: I6851bd61c68fdcff461117fe8f2ab1c3890cb9df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214000
Auto-Submit: Nate Bosch <nbosch@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Some usages of `callConstructor` will have unnecessary checks
removed, when checks on the arguments can be elided. The
compilers will optimize further if they can.
Example optimizations: https://paste.googleplex.com/4594240957972480
Change-Id: I0e6e7e4d1268580cbfab84599b1c9da6fc64e7c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213114
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Riley Porter <rileyporter@google.com>
js_interop_1_test awaits the completer itself instead of the
future which is triggered when the completer completes.
Change-Id: I6a784ced7caaade457cd444823e8cd21d338b9b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213025
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
As a side-effect of making closures without captured variables have an
empty context, we not only avoid a memory leak, but also allow such
closures to be sent across [SendPort]s.
Issue https://github.com/dart-lang/sdk/issues/36983
Issue https://github.com/dart-lang/sdk/issues/45603
TEST=vm/dart{_2,}/isolates/closures_without_captured_variables_test
Change-Id: I5e8845203059ff625f7cff3f072d845b5e48ba36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212297
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This makes the self-detection of whether isolate groups are enabled work
correctly in the test.
TEST=Fixes lib_2/isolate/message3_test test failures on CI
Change-Id: I71965236444af71e6deb4df6a77911144af9af91
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212294
Auto-Submit: Martin Kustermann <kustermann@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Closures can be shared if they have no state they capture (i.e. a null
context). Otherwise we copy them by also transitively copying the
parent context chain.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Added tests to vm/dart{,_2}/isolates/fast_object_copy{,2}_test
Change-Id: Ie641b97806edd0c21f0a8d5c514f8e850823e165
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209110
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
It's a badly designed class, but this change makes it slightly better.
(We should consider moving it to package:collection and removing it from
the platform libraries. Eventually.)
The changes decouples the public `DoubleLinkedQueueEntry` class from
the actual queue implementation classes, avoiding the latter having
to share a generic `_Link<DoubleLinkedQueueEntry>` interface
which would force them to do otherwise unnecessary casts.
The public class should have been abstract, but isn't.
It's mainly used as the API of the entries exposed by DoubleLinkedQueue,
but it can also be used by itself to build double-linked lists that are
not part of a Queue, and the class can be extended.
If anyone does either, it should keep working, so it needs to be a concrete,
self-contained class with a generative constructor.
That class is moved to dart:_internal to avoid its private
implementation fields from interfering with the queue implementation classes,
which have similar fields, but can now have them at different types.
That's a hack, but it works.
The internal implementation of the DoubleLinkedQueue and its entries
are updated to better follow current programming idioms, and avoids
having fields on classes which don't need them.
Also fixes#27920
(`clear`ing a list now detaches each entry from the list so later `.contains`
won't give the wrong answer).
And moves queue tests from tests/corelib to tests/lib/collection,
since Queue isn't exposed by `dart:core`.
BUG= https://github.com/dart-lang/sdk/issues/27920
Change-Id: Ia3bb340a75886de160cc0e449947e8e7ee587061
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211265
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Previously, when encountering identifiers in metadata on a class's
type parameter, the analyzer would resolve them using the type
parameter scope, but then fall back on using implicit `this`. The CFE
would resolve them using the class body scope. In both cases, the end
result was that the annotation could refer to static class members.
This change brings the behavior of both the analyzer and the CFE in
line with the spec, by preventing the use of implicit `this` in these
annotations, and resolving them in the type parameter scope.
This is not expected to break any code in practice, because
annotations on type parameters are rare, as are annotations referring
to static class members, and the overlap between these two should be
negligibly small.
Fixes https://github.com/dart-lang/language/issues/1790.
Bug: https://github.com/dart-lang/language/issues/1790
Change-Id: Ibe5a421e04a53d29074a8b1509e1390658ed72e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210040
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is a reland of 824bec596f
Original change's description:
> [vm] Hide internal implementation List types and expose them as List
>
> When taking a type of an instance with x.runtimeType we can map
> internal classes _List, _ImmutableList and _GrowableList to a
> user-visible List class. This is similar to what we do for
> implementation classes of int, String and Type.
> After that, result of x.runtimeType for built-in lists would be
> compatible with List<T> type literals.
>
> Also, both intrinsic and native implementations of _haveSameRuntimeType
> are updated to agree with new semantic of runtimeType.
>
> TEST=co19/LanguageFeatures/Constructor-tear-offs/type_literal_A01_t01
> TEST=runtime/tests/vm/dart/have_same_runtime_type_test
>
> Fixes https://github.com/dart-lang/sdk/issues/46893
> Issue https://github.com/dart-lang/sdk/issues/46231
>
> Change-Id: Ie24a9f527f66a06118427b7a09e49c03dff93d8e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210066
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Tess Strickland <sstrickl@google.com>
TEST=co19/LanguageFeatures/Constructor-tear-offs/type_literal_A01_t01
TEST=runtime/tests/vm/dart/have_same_runtime_type_test
TEST=lib/mirrors/regress_b196606044_test
Fixes https://github.com/dart-lang/sdk/issues/46893
Issue https://github.com/dart-lang/sdk/issues/46231
Change-Id: I79b587540338808bd73a6554f00a5eed042f4c26
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210201
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
Add missing checks for FFI types disallowed in isolate messages.
Align error messages with the other serializer and test expectations.
TEST=ci
Change-Id: I3813dd8f26e5122524bdf41f9ce6e0785fdd260b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209840
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The transitive copy algorithm was missing support for [WeakProperty]s,
thereby ensuring that we only copy the values if the keys are reachable.
Furthermore we might need to re-hash [Expando]s - since the copied
objects start with no identity hash codes.
The CL also makes us avoid calling to Dart for each [Expando]
separately and instead use a list - just as we do in the re-hashing of
maps/sets.
We also move the C++ code to invoke rehashing logic into
DartLibraryCalls::*.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=vm/dart{,_2}/isolates/fast_object_copy{,2}_test
Change-Id: I836745feef8a6d7573faa94e29a19c1eca0c39f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209106
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
These annotations have all been replaced with @pragma('dart2js:xxx')
versions:
@ForceInline, @NoInline, @NoThrows, @NoSideEffects, @AssumeDynamic.
Change-Id: Ia4730670c6864ccbe0fa4120108c3c16ab887c23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208863
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Removes the lazy loading of the underlying type in LazyJSTypes.
As such, this removes the need to keep AnonymousJSType and
LazyJSType separate, and is therefore refactored to
PackageJSType. Similarly, subtyping is fixed such that
PackageJSTypes are all subtypes of each other.
Change-Id: If489defdbeb5cb932db802a7d146ad2fc393b12c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207982
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reports an error if there are external members in an extension,
where the extension on type is not a JS interop class. A follow
up change will allow extensions with external members on some
Native classes, like dart:html classes.
Change-Id: I01c645aa46e46071aae5f380c5e36329f61d3e18
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207722
Commit-Queue: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
The JIT support has progressed and is no longer unstable. We'll
therefore remove the experimental flag and rely on the same
--enable-isolate-groups flag as in AOT mode.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Existing test suite.
Change-Id: Iff0dd5b64d9b6ab91ad9ffc0ae445efc802d3908
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207122
Auto-Submit: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This CL
* Removes conditional Skip markers in status files
* Removes some outdated TODOs in the code
* Deletes tests/lib_2/isolate/isolate_stress_test
=> It's skipped everywhere, we no longer support isolates on web
* Fixes standalone{,_2}/io/directory_list_sync_test:
=> Instead of relying on the Platform.script which could be an ELF
file lying somewhere else, use Platform.executable instead
* Fixes standalone{,_2}/io/unix_socket_test:
=> The server used `sub.cancel()` to close it's reading end while
the client tried to write to it. This is racy.
If the server goes first, the write on client will throw (since
no error listener was installed on socket.done)
Avoid the race by coordinating client/server.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Enables more tests.
Change-Id: I0464f81f540f2eda23ef4199cc536e53e6a809b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207120
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Tests static extension methods on JavaScriptObject work as
expected, as well as making sure it works with package:js. Once
extension types are added, these tests need to be changed to use
those instead.
Change-Id: I9504c8a3a8e466c680b221e259d93c1df5474218
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/199601
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
It uses eval, which is disallowed.
Change-Id: Ib125276560903846eefa3b86125350294ff5d8fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206661
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
- Account for initialization-in-progress sentinel when checking static field types for reload.
- Don't read the true stack limit when setting or clearing interrupts.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/46596
Change-Id: I80adb4d7d69f01125b7eae8215b5da4d2e467bda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206662
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Adds tests for type checks/casts for pkg:js types that inherit each
other. Similarly, adds subtyping tests for both when types are made
live and when they are not.
Also adds extends_test to lib_2.
Change-Id: Ia3ca03ad9c0291092998d1d3e98d672711fcf8e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205602
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
We use message passing as comunication mechanism between isolates.
The transitive closure of an object to be sent is currently serialized
into a snapshot form and deserialized on the receiver side. Furthermore
the receiver side will re-hash any linked hashmaps in that graph.
If isolate gropus are enabled we have all isolates in a group work on
the same heap. That removes the need to use an intermediate
serialization format. It also removes the need for an O(n) step on the
receiver side.
This CL implements a fast transitive object copy implementation and
makes use of it a message that is to be passed to another isolate stays
within the same isolate group.
In the common case the object graph will fit into new space. So the
copy algorithm will try to take advantage of it by having a fast path
and a fallback path. Both of them effectively copy the graph in BFS
order.
The algorithm works effectively like a scavenge operation, but instead
of first copying the from-object to the to-space and then re-writing the
object in to-space to forward the pointers (which requires us writing to
the to-space memory twice), we only reserve space for to-objects and
then initialize the to-objects to it's final contents, including
forwarded pointers (i.e. write the to-space object only once).
Compared with a scavenge operation (which stores forwarding pointers in
the objects themselves), we use a [WeakTable] to store them. This is the
only remaining expensive part of the algorithm and could be further
optimized. To avoid relying on iterating the to-space, we'll remember
[from, to] addresses.
=> All of this works inside a [NoSafepointOperationScope] and avoids
usages of handles as well as write barriers.
While doing the transitive object copy, we'll share any object we can
safely share (canonical objects, strings, sendports, ...) instead of
copying it.
If the fast path fails (due to allocation failure or hitting) we'll
handlify any raw pointers and continue almost the same algorithm in a
safe way, where GC is possible at every object allocation site and
normal barriers are used for any stores of object pointers.
The copy algorithm uses templates to share the copy logic between the
fast and slow case (same copy routines can work on raw pointers as well
as handles).
There's a few special things to take into consideration:
* If we copy a view on external typed data we need to know the
external typed data address to compute the inner pointer of the
view, so we'll eagerly initialize external typed data.
* All external typed data needs to get a finalizer attached
(irrespective if the object copy suceeds or not) to ensure the
`malloc()`ed data is freed again.
* Transferables will only be transferred on successful transitive
copies. Also they need to attach finalizers to objects (which
requires all objects be in handles).
* We copy linked hashmaps as they are - instead of compressing the
data by removing deleted entries. We may need to re-hash those
hashmaps on the receiver side (similar to the snapshot-based copy
approach) since new object graph will have no identity hash codes
assigned to them. Though if the hashmaps only has sharable objects
as keys (very common, e.g. json) there is no need for re-hashing.
It changes the SendPort.* benchmarks as follows:
```
Benchmark | default | IG | IG + FOC
----------------------------------------------------------------------------------------------------------------------------
SendPort.Send.Nop(RunTimeRaw): | 0.25 us (1 x) | 0.26 us (0.96 x) | 0.25 us (1.00 x)
SendPort.Send.Json.400B(RunTimeRaw): | 4.15 us (1 x) | 1.45 us (2.86 x) | 1.05 us (3.95 x)
SendPort.Send.Json.5KB(RunTimeRaw): | 82.16 us (1 x) | 27.17 us (3.02 x) | 18.32 us (4.48 x)
SendPort.Send.Json.50KB(RunTimeRaw): | 784.70 us (1 x) | 242.10 us (3.24 x) | 165.50 us (4.74 x)
SendPort.Send.Json.500KB(RunTimeRaw): | 8510.4 us (1 x) | 3083.80 us (2.76 x) | 2311.29 us (3.68 x)
SendPort.Send.Json.5MB(RunTimeRaw): | 122381.33 us (1 x) | 62959.40 us (1.94 x) | 55492.10 us (2.21 x)
SendPort.Send.BinaryTree.2(RunTimeRaw): | 1.91 us (1 x) | 0.92 us (2.08 x) | 0.72 us (2.65 x)
SendPort.Send.BinaryTree.4(RunTimeRaw): | 6.32 us (1 x) | 2.70 us (2.34 x) | 2.10 us (3.01 x)
SendPort.Send.BinaryTree.6(RunTimeRaw): | 25.24 us (1 x) | 10.47 us (2.41 x) | 8.61 us (2.93 x)
SendPort.Send.BinaryTree.8(RunTimeRaw): | 104.08 us (1 x) | 41.08 us (2.53 x) | 33.51 us (3.11 x)
SendPort.Send.BinaryTree.10(RunTimeRaw): | 373.39 us (1 x) | 174.11 us (2.14 x) | 134.75 us (2.77 x)
SendPort.Send.BinaryTree.12(RunTimeRaw): | 1588.64 us (1 x) | 893.18 us (1.78 x) | 532.05 us (2.99 x)
SendPort.Send.BinaryTree.14(RunTimeRaw): | 6849.55 us (1 x) | 3705.19 us (1.85 x) | 2507.90 us (2.73 x)
SendPort.Receive.Nop(RunTimeRaw): | 0.67 us (1 x) | 0.69 us (0.97 x) | 0.68 us (0.99 x)
SendPort.Receive.Json.400B(RunTimeRaw): | 4.37 us (1 x) | 0.78 us (5.60 x) | 0.77 us (5.68 x)
SendPort.Receive.Json.5KB(RunTimeRaw): | 45.67 us (1 x) | 0.90 us (50.74 x) | 0.87 us (52.49 x)
SendPort.Receive.Json.50KB(RunTimeRaw): | 498.81 us (1 x) | 1.24 us (402.27 x) | 1.06 us (470.58 x)
SendPort.Receive.Json.500KB(RunTimeRaw): | 5366.02 us (1 x) | 4.22 us (1271.57 x) | 4.65 us (1153.98 x)
SendPort.Receive.Json.5MB(RunTimeRaw): | 101050.88 us (1 x) | 20.81 us (4855.88 x) | 21.0 us (4811.95 x)
SendPort.Receive.BinaryTree.2(RunTimeRaw): | 3.91 us (1 x) | 0.76 us (5.14 x) | 0.74 us (5.28 x)
SendPort.Receive.BinaryTree.4(RunTimeRaw): | 9.90 us (1 x) | 0.79 us (12.53 x) | 0.76 us (13.03 x)
SendPort.Receive.BinaryTree.6(RunTimeRaw): | 33.09 us (1 x) | 0.87 us (38.03 x) | 0.84 us (39.39 x)
SendPort.Receive.BinaryTree.8(RunTimeRaw): | 126.77 us (1 x) | 0.92 us (137.79 x) | 0.88 us (144.06 x)
SendPort.Receive.BinaryTree.10(RunTimeRaw): | 533.09 us (1 x) | 0.94 us (567.12 x) | 0.92 us (579.45 x)
SendPort.Receive.BinaryTree.12(RunTimeRaw): | 2223.23 us (1 x) | 3.03 us (733.74 x) | 3.04 us (731.33 x)
SendPort.Receive.BinaryTree.14(RunTimeRaw): | 8945.66 us (1 x) | 4.03 us (2219.77 x) | 4.30 us (2080.39 x)
```
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=vm/dart{,_2}/isolates/fast_object_copy{,2}_test
Change-Id: I835c59dab573d365b8a4b9d7c5359a6ea8d8b0a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203776
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Adds tests for subtyping between pkg:js types. Also runs tests
for both when types are made live and for when they are not.
Also adds these tests to lib_2.
Change-Id: I25fdc293e422eb21fa8a80dea66ae5d492c5aafd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205601
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
The is checks in is_check_and_as_cast_test.dart are currently optimized
by dart2js at compile time. In order to test them at runtime, is checks
are added after confusing the instance.
Also adds this test file to lib_2.
Change-Id: I3a77c779799f77342297508b89367ab8b64c3241
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205600
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This is a compile-time error today, and that is tested already
elsewhere, so the test serves no purpose.
Bug: #46526
Change-Id: If098f8dc308ae4532b22f786f14a1986e2899251
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205720
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Change completes initial set of js_util optimizations. Some usages
of `getProperty`, `setProperty`, and `callMethod` with <= 4
arguments will have unnecessary checks removed by the compilers.
Change-Id: I94d5402ca9a64ad2818fd6d6a5f7f114f87348c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204562
Commit-Queue: Riley Porter <rileyporter@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Add rename migrations for all the screaming snake case constants that
were renamed to lower camel case during the Dart 2 migraiton.
Rename the test from `file.dart` to `io.dart` so that we can test all
deprecations for the same import together. Add a test for the same
deprecations when imported through `dart:html`.
Change-Id: Iee91d88b1b11648e8c65cfcc8d2fcfabac3954ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203820
Auto-Submit: Nate Bosch <nbosch@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Phil Quitslund <pquitslund@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>
Added check to convertNativeToDart_Dictionary to recursively convert native objects within a map to their Dart equivalent.
Fixes: https://github.com/dart-lang/sdk/issues/44319
Change-Id: I80a2bc0541454900b1c7d9635debaf72d7c120f2
Bug: 44319
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201200
Commit-Queue: Gabriel Castro <gabrielmcastro@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
A JSON value can be `null`, so the return type must be `Object?`, not `Object`.
Fixes#46205.
Bug: http://dartbug.com/462051
Change-Id: I9a5522e09765457dcf8cd2639abbe385d97a3186
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/202623
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
_setPropertyUnchecked version that can be inlined.
No change in the generated JavaScript for dart2js.
Change-Id: Ie4a8e5a34826b6c9083d34656aaa27050635cb21
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200933
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Riley Porter <rileyporter@google.com>