It is unclear if this will help reduce flakiness and timeouts. Until now
the test was setting the listener and making the transition on the same
microtask. If the transition were to complete before the listener is
fully set up, then that would explain the timeout: the transition event
is never fired at that point. Honestly, I find this scenario hard to
believe, but regardless it is worth a try.
This small refactor changes the order to ensure the listener is set up
upfront, and only later we initiate the transition.
Change-Id: I3ae2bfae210ef307935c3d7f2aec9af82df1ddd9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332625
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
This test appears to flake 88% of the time in FF. One
potential reason could be that FF requires user interaction
(similar to the notification_permissions test), however
I don't have an explanation why it doesn't consistently time-out.
One potential theory is whether this behavior is different depending on
which FF browser version is used, but I don't have the data at the
moment to confirm.
Change-Id: Ib5b2759e0d289e44ff06ab11345c597af6cab0f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332626
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
These tests had several issues. The fixes are aimed to reduce flakiness
and remove invalid configurations where tests are not providing any
value. Some of the issues include:
* some tests interferered with each other causing a 18% flakiness rate
in chrome: they used a common file system that ended up being shared
in a single browser instance. This is why some tests failed when they
find a file exists before it was created [1].
* some tests were not properly using async_helper/async_minitest, so
they may complete before they finish executing
* DDC no longer supports these APIs due to
https://github.com/dart-lang/sdk/issues/53864. We don't intend to fix
those issues, so there is no purpose in running these tests in DDC at this
time.
[1]: https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8766313714239949697/+/u/test_results/ignored_flaky_test_failure_logs
Change-Id: I1dbb28eba2d962000a4d425563dbc1eb6b55dbed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332266
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Similar to the request_animation_test, it's unclear the reasons why this
test is hitting flaky timeouts (rate as high as 70% in DDC!).
This change can hopefully improve handling of
asynchrony in the test and help us investigate further.
Change-Id: I5c6023ccfaa7270b1d1e49d902fe9fa168d0d868
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332169
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test provides very little value. It requests the notification
permissions and waits for an answer. What's happening is that the test
launches a prompt and then waiting for a user to click on the browser
dialog to accept or reject the request.
On the bots, this is consistently timing out in chrome and safari.
Turns out this issue was [identified][1] 5 years ago and the test was marked
as Timeout in the status files for that reason (dart2js) or skipped
(DDC). Back then there were discussions
about whether we could make chrome automatically accept or reject the
request, but there was no traction on that.
If we thought this test was providing value, we could explore whether
there is a way to make bots automatically accept/reject the prompt by
saving some preferences on the test machines. That said, I'm honestly
not seeing much value here. For that reason, I'm inclined to delete the
test instead.
Other reasons to delete mentioned in the review:
* this API may require a secure context, but our test runner doesn't default to use https yet
* this API requires a [user gesture in FF][2]
[1]: https://github.com/dart-lang/sdk/issues/32002
[2]: https://developer.mozilla.org/en-US/docs/Web/API/Notification/requestPermission_static
Change-Id: Ib8d372b2ebfb5859a0a9bc82d50a14ad8badeab1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332320
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test is flaky and causes timeouts 70% of the time in DDC.
The reasons are not clear at the moment, but I noticed that the
test was not properly using async-helper. This change may help
improve our investigation in the near future.
Change-Id: I834265dd6b898098ee7d5210ffe68ef0a6db74a0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332280
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test is 61% flaky in dart2js-chrome and 73% flaky in DDC.
This test is almost identical to
lib/html/element_animate_simple_timing_test (long ago it was a separate
case in the same file that used the html multi test configuration). The
only difference is that this test has no deadline for the animation to
complete, while the other test (which passes consistently) does.
My theory is that not including a deadline is the cause of flakiness and
without it, there isn't ,uch we can control to recover consistency. As
such, I don't think we should be including this test anymore.
Change-Id: I5451dbc7053ba0280a64e1bef2e03cc20465ad88
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332170
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test has non-deterministic failures (rate 30% on mac, 10% on linux
and windows) caused likely by a data-race ([example log][1]). The test
has a write to set the contents of a file, and a corresponding read. The
error makes it appear as if the read occurred before the write
completed.
This API is part of the [createWriter][2] proposal, which was abandoned
early on (almost a decade ago) and documented as deprecated. As a result
I believe this test is providing coverage for obsolete functionality.
In fact, the API for the `write` returns void and appears synchronous,
but my guess is that it is not. There is no API to ensure the write
completes as far as I know. An alternative here would be to use timers
to add a significant delay between the operations.
It is also worth noting that the [requestFileSystem][3] API to access
the FileSystem (used here and in the fileapi tests) is also deprecated
and not supported in firefox or safari.
Given the flakiness issue and the fact that this API is already
deprecated, I'm not really seeing the value in keeping the test.
[1]: https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8767600632278735009/+/u/test_results/ignored_flaky_test_failure_logs
[2]: https://developer.mozilla.org/en-US/docs/Web/API/FileSystemFileEntry/createWriter
[3]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestFileSystem
Change-Id: I92ad6399218c6a17cfa029a99b99afcfadde0035
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332282
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
It seems to me that this test doesn't provide value for the JS backends.
The test was first introduced 11 years ago to investigate and fix GC
issues in Dartium that happened across the Dart/DOM boundary (see
https://github.com/dart-lang/sdk/issues/1448).
While the test works in many configurations, this test is flaky in
dart2js-firefox (37%) and DDC (8-14%). I haven't investigated the
reasons behind the timeouts, but given the origins of the test, it
doesn't seem worth fixing it.
Change-Id: I3eaf2273209b587ce5ecfcf4a2bbbd9cb8b990fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332167
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test has flaked on our CI but actually it's consistently failing
because we do not represent `typedef`s in a reflective way in the VM
since switching to kernel (because they used to be desguared on kernel
level).
So this has not been working for a long time, let's remove this test.
Issue https://github.com/dart-lang/sdk/issues/44489
Change-Id: I36e8d8aee7a7736e8afc5741b01d10429ac0d7a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331941
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This reverts commit b657773d58.
Reason for revert: blocking Dart SDK -> Engine roll (https://github.com/flutter/flutter/issues/137054)
Original change's description:
> [typed_data] Deprecate UnmodifiableUint8ListView and friends
>
> This is the first of several steps to remove the unmodifiable views for typed data classes. The end goal is that dart2js has only one class implementing `Uint8List` so that `Uint8List` accesses can always be compiled down to JavaScript code that directly uses indexed property accesses (`a[i]`).
>
> This first step deprecates the unmodifiable view classes to help prevent their use in new code, and adds `asUnmodifiableView()` methods as a replacement for the small number of places that use the classes.
>
> The next steps (see #53785) are to remove uses of the unmodifiable view classes from the SDK. Once this is complete the classes themselves can be removed.
>
> TEST=ci
>
> Issue: #53218
> Issue: #53785
>
> Change-Id: I04d4feb0d9f1619e6eee65236e559f5e6adf2661
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321922
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Stephen Adams <sra@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Ömer Ağacan <omersa@google.com>
Issue: #53218
Issue: #53785
Change-Id: I0bb042269f9ff8e5cd69619cf97b60c79ea98cbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331680
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
This is the first of several steps to remove the unmodifiable views for typed data classes. The end goal is that dart2js has only one class implementing `Uint8List` so that `Uint8List` accesses can always be compiled down to JavaScript code that directly uses indexed property accesses (`a[i]`).
This first step deprecates the unmodifiable view classes to help prevent their use in new code, and adds `asUnmodifiableView()` methods as a replacement for the small number of places that use the classes.
The next steps (see #53785) are to remove uses of the unmodifiable view classes from the SDK. Once this is complete the classes themselves can be removed.
TEST=ci
Issue: #53218
Issue: #53785
Change-Id: I04d4feb0d9f1619e6eee65236e559f5e6adf2661
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321922
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Minus all the operator-related functionalities, members that
can be worked around using static interop e.g. getPrototypeOf,
and createDartExport/createStaticInteropMock, this bridges the
gap of js_util.
Adds:
- instanceOfString from js_util as an extension methods
- JSObject constructor to replace js_util.newObject
- Unnamed factory constructor to JSAny so users can't extend it
Fixes:
- JSArray.withLength to take an int
- typeofEquals to take a String and return a bool
- instanceof to return a bool
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I7db1651f641a4fc84392957dfa7ad64904f110e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326691
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
null and undefined cannot be distinguished on dart2wasm in its
current state, so these helpers should only work on the JS
compilers. Some comments are updated to reflect the current state
of this internalization. Also fixes a pending TODO in isNull and
isUndefined on the JS backends.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ic56e8aa346af99cb99d01fe3c7ac5e37e965db23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326690
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Adds Future.toJS that creates a Promise using a Dart callback.
Resolving is simple as we just pass the value (if any). Rejection
boxes the error and stack trace and sets them as properties of
a JSObject, which is then passed to the reject function.
Also adds:
- JSPromise constructor
- JSFunction.callAsFunction helper
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: If2ce8018a2c8b3c4dc5d5af710c9bb4c2f688f87
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326689
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Then callbacks should accept and return a JSAny?. Some JS types tests
were incomplete as well.
Change-Id: Id46e2a53f8f83ce17247fbd23d5be82f3f986f30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326688
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Now that the canary configurations are more reliable we can start
running these tests again. They were originally skipped when the
async implementation in the new type system was not working correctly.
The `web/async_stacktrace_test` has actually been timing out in the
stable configs as well. The timeout is consistent and reproducible
locally so I'm filing a new issue and skipping it on all DDC configs
for now.
Fixes: https://github.com/dart-lang/sdk/issues/50666
Issue: https://github.com/dart-lang/sdk/issues/53555
Change-Id: I7306ba66afe595fb213f06c0ad884d376240addc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326721
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This is a reland of commit 54522db98f
Original change's description:
> [dart2wasm] Fix nullable JS type and int parameters in JSFunction
>
> When a callback is toJS'd with an int parameter, we should attempt
> a conversion to int if possible, similar to return values on
> external functions. Similarly, parameters where the expected type is
> a JS type should check to make the value isn't nullish before boxing,
> as JS null and undefined are converted to Dart null.
>
> Tests are added for conversion semantics of JSFunctions.
>
> Change-Id: I95566c2954d915b8cf31cdc55fed359c695404f2
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323445
> Reviewed-by: Aske Simon Christensen <askesc@google.com>
Change-Id: I36ec7702b1e08fc9e4d6290952ae548b0e074ee3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325971
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This is a reland of commit 2a669c571f.
External APIs when using dart:js_interop should only allow
primitives, JS types, and other static interop types. This
was previously checked in a more restrictive mode called
"strict mode" but is not checked everywhere where dart:js_interop
APIs exist.
Change-Id: I1a8d04071a519c4965b266eb2800bcc3c3bb8393
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325961
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Revert submission 323446
Reason for revert: This breaks flutter web engine unit tests. See https://github.com/dart-lang/sdk/issues/53521
Reverted changes: /q/submissionid:323446
Change-Id: I9095f0791a556d4bc912e29fde274f3cb8824317
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325964
Commit-Queue: Jackson Gardner <jacksongardner@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Strings are the most likely use case of getting and setting
properties, and therefore we should make that easier to use.
This CL also renames the extensions in dart:js_interop_unsafe
to a more relevant name and to avoid conflicts in dart:js_interop.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ia8ce6593167c648f9710b47cfe27f80c854be407
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324572
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This reverts commit 2a669c571f.
Reason for revert: Failing dart -> Flutter Engine roller. We need to make some changes on the engine side to prepare for re-enabling these checks.
Original change's description:
> [dart:js_interop] Re-enable type checks on external APIs
>
> External APIs when using dart:js_interop should only allow
> primitives, JS types, and other static interop types. This
> was previously checked in a more restrictive mode called
> "strict mode" but is not checked everywhere where dart:js_interop
> APIs exist.
>
> Change-Id: Ic82a3ec0bf6062c25d7f8933e503820a21bc191f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316867
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: I54caf06976e215b2b576cedfc0013ee79c6682f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324902
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Adds a conversion function on List<JSAny?> so that users can
modify the original list and have those changes carry forward
to the array. Creates a proxy object for dart2wasm when the
list is not a JSArrayImpl. This proxy uses handler methods and
the fact that Array methods are generic to provide an Array
interface. Also fixes a small issue in the exporting so that
toJS'd function types have a valid return type.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I00f453aa82dd19f2913820579eb2675b799288d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323446
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
When a callback is toJS'd with an int parameter, we should attempt
a conversion to int if possible, similar to return values on
external functions. Similarly, parameters where the expected type is
a JS type should check to make the value isn't nullish before boxing,
as JS null and undefined are converted to Dart null.
Tests are added for conversion semantics of JSFunctions.
Change-Id: I95566c2954d915b8cf31cdc55fed359c695404f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323445
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This is a reland of commit ebc96ecb83
Angular codegen emits members that are external so DDC's external
checks need to be more specific to only focus on JS interop. This
also modifies some code logic around whether a member is JS interop
to be less permissive. Before, it claimed that any member is JS
interop if it's external and the enclosing library has a @JS
annotation, but this is only true if there is no surrounding class.
Original change's description:
> [ddc] Don't emit type args on interop invocations
>
> DDC passes type args as the first args for a generic function
> invocation, but interop functions should be excluded from doing
> so, as this leads to passing type args to JS functions.
>
> Change-Id: Ia011beca8c7a0ebb3a7e6c81cd960096045c3a06
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323941
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: Id48337ac4980d9de5de03d895d93cad3ab3a1808
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324542
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This reverts commit ebc96ecb83.
Reason for revert: breaks G3, b/299279625
Original change's description:
> [ddc] Don't emit type args on interop invocations
>
> DDC passes type args as the first args for a generic function
> invocation, but interop functions should be excluded from doing
> so, as this leads to passing type args to JS functions.
>
> Change-Id: Ia011beca8c7a0ebb3a7e6c81cd960096045c3a06
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323941
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: Id1af7f71e80b22b48343c1d918b9431afaf6aaf4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324521
Commit-Queue: Ilya Yanok <yanok@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
DDC passes type args as the first args for a generic function
invocation, but interop functions should be excluded from doing
so, as this leads to passing type args to JS functions.
Change-Id: Ia011beca8c7a0ebb3a7e6c81cd960096045c3a06
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323941
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
External APIs when using dart:js_interop should only allow
primitives, JS types, and other static interop types. This
was previously checked in a more restrictive mode called
"strict mode" but is not checked everywhere where dart:js_interop
APIs exist.
Change-Id: Ic82a3ec0bf6062c25d7f8933e503820a21bc191f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316867
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Static invocations of external factories are casted so that the
result, which is a @staticInterop type, can be treated as the erased
type instead. This CL fixes the issue where the type that it was
casted to was never replaced with the erased type.
Change-Id: Ic6eb529349ea2b5c42f91c2740d501d4f81bc38e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323505
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Skip `_NativeCallableIsolateLocal` in the fuzz test so that we have
coverage for the other things again while investigating.
Bug: https://github.com/dart-lang/sdk/issues/53350
Change-Id: I67d8657f965dee5338fd9286a9f1fd935559d585
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322662
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
Now that ddc, dart2js, and dart2wasm are consistent on toString outputs
for JS objects, we should test to make sure this behavior doesn't
regress.
Change-Id: I2b1b4819e5a2425ae813dc944a4dea7b2147d5bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322365
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Some of these is checks can be optimized away by dart2js.
Change-Id: I76b5b253a24a4ded2394664985665fc875b60f52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321750
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Adds JSSymbol and JSBigInt and erases to either their respective
interceptor types in the JS backends or JSValue in dart2wasm.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ib2c70d22a70c6308733cd170b91eafa8ec3b3aeb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321749
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The underlying subscription would invoke the `onDone` handler even
after a `cancel`.
It also forgot to register the `onDone` callback in the zone before
running it.
Tweaked the behavior of `pause` and `resume` to make sure they make
no difference after `cancel` or after a done event has been omitted.
(Test now checks that the behavior matches other streams.)
Fixes#53201
Bug: https://dartbug.com/53201
Change-Id: Iba35be2c4b44b5c4ec97d5a4dbcd3aff7fee8b75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320561
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
This is likely more useful than returning globalThis always. It
allows users to workaround issues with lowerings without having
to worry about browser compatibility differences.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I01479211fe6b573c845de5b134d36338c40fc10d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319301
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Extension type factories are added to the language, so they
should be tested. Also fixes a small issue on detecting
tear-offs.
Change-Id: I8d2b374830e4ac11783d10d3b75221544ee9ef3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318160
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Does several refactorings now that inline class -> extension type:
- InlineExtensionIndex becomes ExtensionIndex
- Comments mentioning inline classes now reference extension types
- Tests are moved to extension types
- Errors now reference extension types instead of inline classes
Change-Id: I26ede8e3aaf6bba5f73847238edeed266fc6a043
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317805
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Tests class type parameters and local type parameters that are
bound to both JS types and static interop types.
Also moves and refactors a test on external extension members to
static_interop_test so that dart2wasm runs it now.
Change-Id: I6b407455d853d3d85b3d58abafdd23e6b2a03977
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316866
Reviewed-by: Sigmund Cherem <sigmund@google.com>
With this change the Dart Core Object members (`.hashCode`,
`.runtimeType`, `.noSuchMethod()`, `.toString()`, and
`operator ==`) are no longer installed onto the native JavaScript
Object prototype. This is done because the Object prototype will be
sealed as a security precaution in some environments to avoid
prototype pollution exploits.
This means that dispatching to these APIs will change when the
compiler cannot know if the receiver may be null or a value from
JavaScript interop. In those cases a call to a helper method is
inserted instead. The helpers will probe for the API on the value,
call it if available or execute a default version.
NOTE: Many other native JavaScript prototypes are still modified. This
change is only for the Object prototype.
Issue: https://github.com/dart-lang/sdk/issues/49670
Change-Id: Iddb3a48e790dd414aa3254d729535c4408e99b3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310971
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
