Fixes https://github.com/dart-lang/sdk/issues/55024
The patch files for these operators return a bool, whereas
the public API returns a JSBoolean. Since there's only one
possible return type, we should make them return bool for
convenience. Boolean conversion is also inexpensive on
dart2wasm, so that shouldn't be an issue.
Also adds helpers to operator_test to make sure any JS values
are converted before they're compared, adding additional type
checking through the conversion.
CoreLibraryReviewExempt: Fixes type mismatch in backend-specific library.
Change-Id: I7ff2e334e817e6e7d7d8d5091a4e5d570a496b03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354702
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Modifies a test to check that object literals that are
assumed to not contain a parameter actually don't
contain that parameter.
Change-Id: I2e7952c696ed22cd2d8e59d72cb1a537a61c6b6e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355202
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Gives the constructor optional parameters for providing
more information that can be used in the `toString` message,
and the `stackTrace` getter.
Makes the `iterable.wait` and `record.wait` extension methods
provide such information, so that the `toString` will always
contain the text of *one* of the errors.
(No issue, problem with logging was brought up in chat.)
Change-Id: I5f9a20ad0af0c64a2e7ff3cdb56f187a5cf5a3ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353080
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
* We migrate the `dart:developer` implementation of dart2js to
static interop.
* We make dart2wasm use the same implementation as dart2js.
Closes https://github.com/dart-lang/sdk/issues/54991
Change-Id: I7873edc7e804500c8eca878367d9045c98a1c2e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354101
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
If a target `_Future` is chained to another source `_Future`,
then it's because the target will complete with the same
result as the source future. Instead of keeping both
alive with a listener on the source which completes the target,
instead the target moves all its listeners to be directly on
the source, and keeps a link to the source in case more listeners
are added later.
The idea is that most futures are unreferenced after they have
had their first listener, so the target future has a chance
to be GC'ed.
If the target future has `.ignore()` called, and has no listener,
then the source completing with an error should not cause the
error to be uncaught. Without the optimization, the source would
have had a listener, and the target would ignore the error.
To simulate that, the source now gets a copy of the target's
`_ignoreUnhandledErrors` flag.
This is still not precisely the same as it would be without the
optimization. If *two* target futures are chained to the same source,
and only one of targes has `.ignore()` called, then this
implementation will make the uncaught error not be reported,
where it technically should.
(An alternative would be to *not* use chaining for futures
with `ignore()` called on them. But those are precisely futures
that are likely to be GC'able, because someone has already said
that they don't care if the future complete with errors.)
Fixes#54943
Bug: https://github.com/dart-lang/sdk/issues/54943
Change-Id: I0dbb4919ce2ea612d66539862fa0eb188aab8287
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352908
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Fixes https://github.com/dart-lang/sdk/issues/54801
Object literal constructors need to be explicitly handled when
determining a member is JS interop or not in dart2js as it does
not require any @JS annotations.
Change-Id: Iee99375439057844485aa3f5cd88f85f5d03ae06
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349840
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/54138
Adds a helper to do better type-checks so that users don't
accidentally using is checks or have to manually do the right
typeof or instanceof checks. In order to do this, there is
some refactoring to make ExportCreator a SharedInteropTransformer
(as it's shared across all backends) so that we can reuse an
existing visitor. In the same class, we remove unnecessary setting
of parent pointers. We should clean up the fileOffsets as well,
but dart2js verifies that those are set, so we keep them as is
for now. Also adds some static errors for edge cases.
CoreLibraryReviewExempt: Helper for web-specific library.
Change-Id: I34d818ada1349b69afd15d170d3fafa0460f65fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347225
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/54482
This is generally useful for users working around some limitations of
dart:html. While we want to encourage users to use package:web,
dart:html is not available on dart2wasm and users can use dart:html in
other ways already e.g. in an interop extension type, so it doesn't make
sense to disallow this. We also allow type parameters that extend these
types as well.
In order to make this a bit more performant (subtyping checks may be
expensive), code is refactored to cache more readily and separate the
notion of an allowed representation type vs interop extension type. We
also define the notion of a "core" interop type, which will be useful
when we want to efficiently query what interop type users are using
underneath the possible layers of extension types.
A few missing tests around typed_data are added and the error around
invalid types is reworded to include this change and be more consise.
Change-Id: I256b0cce4355d2a21853b0c5bf641166cafc523e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347224
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
The current implementation externalizes and internalizes the Dart
value instead of adding a box and using a runtime-specific symbol.
This makes the implementation consistent with the JS backends.
Change-Id: Iefa382f742bc819b18dfe27ca33741b12473ee39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347222
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This test was written to validate correctness of the web
implementation of `dart:isolates`, back when it was supported.
Today, this API is unsupported in both dart2js and DDC. The test was
consistently failing in DDC and skipped in dart2js. We don't believe
it's valuable to continue running this test at this moment.
Change-Id: I578533b09c4172daf3f49fcc528ccb2cebebb53d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347642
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The former waits for the test to complete while the latter does
not. Testing this on d8 uncovered two issues which are also
addressed in this CL:
1. async_test has a Promise that is rejected before it is handled.
2. Tests that use Promises don't work correctly on dart2js + d8,
and are therefore skipped for now until the issue is resolved.
Change-Id: I1fac1f4c653bb9ee30ed683d1b0d11bfbf14a58c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/343682
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/52852
Allows importing of modules using the JS "import()" expression.
The result is a promise that resolves to a module, from which users
can then access exported members from.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I4c1caae689be55d1dbb038448e3243bcb80ac8b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/343683
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Shorthand of hasProperty for the common case. Reworded some docs
to be less strict about not using this library (since has and
hasProperty have no good alternatives).
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I7e82385fd18ff4fbc83266e9b08c9d854ca62a78
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/343681
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Includes small wording modifications and extra allowlisting for
benchmarks and Flutter engine tests.
This reverts commit c97a17b2349bcbdadd34204a65a9e7c7c13def83.
Change-Id: I2db391782c98c351d744ea7201c9421f13b97979
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/343689
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
This reverts commit 8c246caa91.
Reason for revert: Need to allowlist benchmarks to use package:js.
Original change's description:
> [dart2wasm] Disallow use of old interop libraries
>
> Closes https://github.com/dart-lang/sdk/issues/54004
>
> Adds an error for imports of old interop libraries. Has an
> allowlist for existing usages/migrated usages that we'll need
> to migrate.
>
> Change-Id: Ie7174ae2a50c2d03a7aa2975e8a1914a4cba8a2c
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342521
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: Id7d3a3063d417830774d7a72eed5185599f9267f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/343685
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Closes https://github.com/dart-lang/sdk/issues/54004
Adds an error for imports of old interop libraries. Has an
allowlist for existing usages/migrated usages that we'll need
to migrate.
Change-Id: Ie7174ae2a50c2d03a7aa2975e8a1914a4cba8a2c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342521
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This method is the JS typed replacement of createDartExport. Tests
are duplicated to make sure this method is tested as well. We avoid
exposing a JS typed version of createStaticInteropMock as the
signature would not be compatible with @staticInterop classes, and
due to the low usage (there's only 1 result in google3 and 0 in
GitHub afaict), we should wait until we support interop extension
types in this method before exposing it.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I1a47e86e33563f740e0813d4657c26d555e57508
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342520
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
https://github.com/dart-lang/sdk/issues/54004
In order to reach parity with js_util, we expose operators
through an extension and do some partial renames in order
to make the member names sound better e.g. `equals` instead
of `equal`. We also expose the following from js_util:
- NullRejectionException
We don't expose `isJavaScriptArray` and `isJavaScriptSimpleObject`
as they can expressed through other forms of interop. There
was an esoteric bug where we needed these members for Firefox
in pkg:test, but the package no longer uses these members, so to
avoid increasing the API space too much, we do not export them.
For the same reason, we also don't expose `objectGetPrototypeOf`,
`objectPrototype`, `objectKeys`.
We don't expose `allowInteropCaptureThis` as it will take some
work to handle this in dart2wasm. That work is tracked in
https://github.com/dart-lang/sdk/issues/54381.
Lastly, `instanceof` and `instanceOfString` is moved to be on
`JSAny?`, as this operator is useful to avoid needing to
downcast to `JSObject` e.g. `any.instanceOfString('Window')`
instead of `any.typeofEquals('object') &&
(any as JSObject).instanceOfString('Window')`.
Extensions are reorganized and renamed to handle these changes.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ib1a7fabc3fa985ef6638620becccd27eeca68c25
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341140
Reviewed-by: Sigmund Cherem <sigmund@google.com>
In order to support this, adds necessary changes to conversion
functions (including cast-lists) and makes JSArrayImpl a generic
type.
CoreLibraryReviewExempt: Backend-specific library changes.
Change-Id: I58bcfb67ef21c90be5e25735757d780aac52dc23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337923
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/54192
Callbacks were being casted to their static type before being
called. With generic callbacks, we do not know their exact type
at compile time, therefore cannot make that cast. Similarly, a
null check was being done if the static type of the parameter
was potentially non-nullable, whereas it should be done if it's
*not* potentially nullable.
Change-Id: I3d30e901f1ff2ae4c17887564f15368244baeb24
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340390
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Addresses some comments in https://github.com/dart-lang/sdk/issues/54192
- With the addition of `nonTypeVariableBound`, we no longer need a
recursive checker.
- We also should account for `StructuralParameterTypes`.
- The current checks did not check type parameters for functions
converted via `toJS`, so that is handled as well.
- Functions that declare type parameters cannot be called in JS
correctly, so an error is added when users try to convert them.
- Some errors are reworded/modified.
Change-Id: Ic05220883ec4ad8653963acd901d339426cba6c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339346
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Support extension type members in dart:mirrors similarly to extensions.
Add MethodMirror.isExtensionTypeMember and VariableMirror.isExtensionTypeMember.
TEST=tests/lib/mirrors/method_mirror_extension_test.dart
Fixes https://github.com/dart-lang/sdk/issues/54266
CoreLibraryReviewExempt: VM-only dart:mirrors API change
Change-Id: I9c1c22118ee52e98d5013c881eb6ad5686df656e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340284
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
- Removes @staticInterop JS types declarations in favor of
typedefs (the function types' reified types and the typed data's
reified types have changed to make the type hierarchy work in the
JS backends).
- Adds extension types to dart:js_interop
- Adds a fromInteropObject helper to JSObject to avoid casting to
an extension type
- Deletes now stale tests
- Refactors some dart2wasm @staticInterop declarations since they
can no longer implement JS types
- Updates extension types tests to use the prefix extension_type
instead of inline_class
- Updates comments
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ibe04afac9585ddb99fcf6dbaa7f12050d8b876dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332860
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/54118
ApplicationCache is a deprecated browser API, and this test
is failing on almost all web configurations. There's nothing
to test, so this should be deleted.
Change-Id: I582ae44e23bfaa1198bd5e57236340b552380ba5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338427
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
All tests skipped here are flaking or timing out. Most of them fail for
a common reason tracked in
https://github.com/dart-lang/sdk/issues/53985: Chrome inactive tabs do
not run behave the same as active tabs. This means that interactions like
css transitions, requestAnimationFrame, and video play don't work as
expected.
This CL skips the tests only on Chrome, but continues to run them in
other browsers where the expectation is met. If we can in the future
ensure tests are run on an active tab, we can consider reneabling these
tests. That said, the value of this tests was higher when we mantained
Dartium, but these days we may consider deleting them instead.
Change-Id: I9c0ea230fecca16fa008b64c2cf316ccdd0f53e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335030
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Users are allowed to have extension types on types that we allow
on external methods e.g. String. For most types, this doesn't make a
difference as we jsify for parameters and dartify and cast for return
types. The one place it does matter is when we check the static type
to do int conversions. Here, we should use the erased type instead.
Change-Id: Ibfcb0acc7f2c8a1ba3b52aa42000640982f11962
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335120
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
A lot of JS inline function calls were being passed null
instead of nullRef. Extension conversions are changed to better
handle WasmExternRef?s. There were a few spots in the
dart:js_interop_unsafe API surface as well that were not handling
nulls consistently.
CoreLibraryReviewExempt: Doc changes to backend-specific lib.
Change-Id: I08c5020e65156faed3841b0446aafb1e51242342
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334380
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Address comments from Lasse in
https://dart-review.googlesource.com/c/sdk/+/331210. Namely:
* Use 100ms for the interval, so avoid overlap with the safety-margin of 40ms
* Rewrite comment to only discuss the safety margin in terms of an early
dispatch
* Only use the safety margin on web backends. Unlike timer_test, I am
using the presence of `dart.library.js` instead. Going forward it's
possible that dart2wasm hits this issue if it relies on browser's
timers.
I also copied the changes to lib_2 since flakiness is seen there too.
Change-Id: I71b6365346cccc7667dbe3da809b1bfd192ff38a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333057
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
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>
