I also cleaned up a bunch of places that referred to them.
Change-Id: I45f68818c892f8620ea04257885ffa3763374bb5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335863
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
The current `String.fromCharCodes` behavior, throwing if `start`
or `end` is larger than the length of the `charCodes` iterable,
is inconsistent with the argument being an `Iterable<int>`,
which the user is not expected to know the length of.
Most other operations that accepts or produces an `Iterable` and
restricts it to a range, will allow the range to exceed the length
of the iterable, acting like `.take(end).skip(start)`, just without
needing to create wrappers that hide the original value.
(`List.setRange` is another exception, and should probably be fixed
by allowing the range to be partially filled, since it's too hard
to change it to require a `List` argument.)
Fixes#50253, #53937
Tested: Added to `corelib/string_fromcharcodes_test.dart`
Bug: https://dartbug.com/53937, https://dartbug.com/50253, https://dartbug.com/23282
Change-Id: Ie19c5fa8e715ea1c58c9c77c247f2a563654c1aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333921
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
This is a reland of commit 6f29e7fce4
Original change's description:
> Expire 3.0.0 experiment flags.
>
> TEST=Existing tests covers.
> Change-Id: I161eefdc28c74f63ba1ee926800a01eea03d9930
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331960
> Commit-Queue: Lasse Nielsen <lrn@google.com>
> Reviewed-by: Alexander Thomas <athom@google.com>
TEST=Existing tests covers.
Change-Id: I384e77744c74774a250be413358a7fa176117167
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332684
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Also tests/language_2 (which hopefully we can delete soon).
Change-Id: I4c7086ecb1b374c2068be9d1366f76323435e57f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336624
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Adds tests to cover constant values flowing into `Handle` parameters
of `@Native external` functions.
The first test is a repro of the failure from
https://dart-review.googlesource.com/c/sdk/+/333840
The other tests construct more extreme cases.
Handles can't be passed to leaf functions, so no `isLeaf`.
Split off reland:
https://dart-review.googlesource.com/c/sdk/+/333841
TEST=tests/ffi/ffi_native_handles_test.dart
Change-Id: I89d31a940f5a63793a03a9eb364231a54164a328
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336661
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Switch the Windows ARM64 builds to use MSVC. Clang disagrees with itself about handling of small structs in variadic functions, allowing splitting between the last argument register and the stack as the callee but not as the caller.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-android-release-arm-try,vm-ffi-android-release-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-linux-release-arm64-try,vm-mac-debug-arm64-try,vm-mac-release-arm64-try,vm-win-debug-arm64-try,vm-win-release-arm64-try,vm-ffi-qemu-linux-release-riscv64-try,vm-linux-debug-ia32-try,vm-linux-release-ia32-try,vm-win-release-ia32-try,vm-linux-debug-x64-try,vm-linux-release-x64-try,vm-mac-debug-x64-try,vm-mac-release-x64-try,vm-win-debug-x64-try,vm-win-release-x64-try
Bug: https://github.com/dart-lang/sdk/issues/52644
Bug: https://github.com/dart-lang/sdk/issues/53829
Change-Id: I2fd6c40620a885479f11bb8528ca1e9df3948a2f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331209
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit 92e7989fbc.
Reason for revert: Causes VmService WebSocket creating to fail because HttpClient is mocked during Flutter Widget tests. See https://github.com/flutter/flutter/issues/138413
Original change's description:
> Call the HttpClient constructor when connecting a WebSocket to allow HttpOverrides to work.
>
> One consequence of this is that there will be one HttpClient per WebSocket connection rather than one for all WebSocket connections. This does *not* affect connection pooling because the sockets are detached from the HttpClient after the WebSocket connection is made.
>
> Closes https://github.com/dart-lang/sdk/pull/52509
>
> GitOrigin-RevId: 28ca642a56e3bbc6112df844b07026b9e0ae8ae6
> Change-Id: I8d9c6f2a883b0f79bafca30abd1dfd98291cf0e0
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305620
> Reviewed-by: Alexander Aprelev <aam@google.com>
> Commit-Queue: Brian Quinlan <bquinlan@google.com>
Change-Id: Ie1d029e7acf477503cd601f6a03e121cd17d1695
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336100
Auto-Submit: Brian Quinlan <bquinlan@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
There is an issue with cross module constant extension types that causes
the CFE to crash.
Change-Id: Id6af3a5400e55ecb2534ce71a07c5c1ecb17a46f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335384
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The `gcd` method has a parameter of type `int`, when trusting
type annotations, we don't validate that the parameter is not
a `double`.
This change guards against this scenario and makes this test pass in
dart2js-production-linux-d8.
Change-Id: I70ab76b5b389d33c316b625ebb6188959a1ae949
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335620
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
One consequence of this is that there will be one HttpClient per WebSocket connection rather than one for all WebSocket connections. This does *not* affect connection pooling because the sockets are detached from the HttpClient after the WebSocket connection is made.
Closes https://github.com/dart-lang/sdk/pull/52509
GitOrigin-RevId: 28ca642a56e3bbc6112df844b07026b9e0ae8ae6
Change-Id: I8d9c6f2a883b0f79bafca30abd1dfd98291cf0e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305620
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Brian Quinlan <bquinlan@google.com>
The test was relying on the runtime type representation to verify
that the library object returned from `getLibrary` was correct. Now
it uses the static `print()` method instead to avoid issues in the new
type system.
Change-Id: Iaa26427e46afd0e7f4ae0a84cb4c123755484647
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335023
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Bug: b/310114753
Change-Id: Id39362d267c9967ab679456c6f891700196f9170
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335444
Auto-Submit: Alexander Thomas <athom@google.com>
Commit-Queue: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
The test creates DateTime objects reusing the data from another
DateTime object, but on one case it didn't include the seconds and
milliseconds value.
When using the minimum date value, this omission made the copy to be
out of range, and as a result returned an InvalidDate.
Change-Id: I83f1d8a755e8d3a78ef0fd0468ee80e162c10545
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335400
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: 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>
Eventually we may want to revisit whether it is worth running this test
at all on the web backends. The test was designed to ensure the VM
didn't produce memory leaks when capturing state in closures, as such,
it may be better placed on a different suite.
Today, the test passes in most web configurations. The two exceptions
are:
* ddc-linux-chrome is flaky and times out 50% of the time
* ddc-linux-firefox consistently times out.
Locally, on a machine much faster than our bots, the former completes in
5s and the latter in 25s. In the last 60 days, the chrome configuration
has seen runs on the bots ranging from 8 to 60s (hitting the timeout). I
expect marking the test as slow will fix the flakiness on chrome, but
given that it is 5 times slower on FF, I fear it may not be enough to
make the test pass in FF. Given that it doesn't provide much value to
also have the coverage in FF, I'm inclined to skip it there instead.
Change-Id: Ice25eb401b6af3c6ab8ba3f4b43bf3ce9ee38c83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335020
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
I suspect that when the list of type preserving selectors was created the first/last setters either didn't exist or were just overlooked. Any dynamic List could have its inferred type changed by these operations.
Due to Dart2js's type representation this bug affects more than just dynamic lists. We track some simple values as part of the type system. So an operation that modifies a value can technically modify the type, as Dart2js represents it, even if the "real" type is preserved.
In the added test we would represent the list literal's type as "List(length: 2, elementType: Bool(true))". Notice the type states the elementType is specifically true, not just bool. Thus the first/last operations are modifying that type. But since we aren't registering this type change, SSA optimizes away the call/index and inlines the element itself.
Interestingly, this primarily manifested for bools due to a check in SSA:
https://github.com/dart-lang/sdk/blob/main/pkg/compiler/lib/src/ssa/optimize.dart#L475
In that code we are inlining constant-like expressions for the arguments of static invocations (such as the argument to a Expect.isTrue call). However, a few lines earlier you will see we only inline bool constants:
https://github.com/dart-lang/sdk/blob/main/pkg/compiler/lib/src/ssa/optimize.dart#L467
So when the list element type is anything other than a bool, this inlining does not trigger thus avoiding the bug.
Bug: https://github.com/dart-lang/sdk/issues/53944
Change-Id: I4e893903f335fc99b13cf526736c27bb066a4bad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334420
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@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>
Classes were mistakenly being formatted by the function formatter.
Change-Id: I6c513803c7c211f02bb9267914b5988cd6c02c5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334005
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Ensures that `toString()` of types that contain embedded js types
will appear the same in the old and new runtime type systems.
Issue: https://github.com/dart-lang/sdk/issues/48585
Change-Id: I71ec0e13943281e745bcf05e10aa36d093cbc0c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334003
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Dart does not officially support browsers before the introduction of WeakRef and FinalizationRegistry but there are users of Dart that have a few customers still using these browsers.
As a result, both ACX and Flutter have ad-hoc polyfills for these classes. Adding the polyfill in js_runtime will allow the other polyfills to be removed. The polyfill is as small as possible (omitting checks, avoiding extra Dart classes, detecting as late as possible), so it should be a net code size improvement of a few bytes for ACX and Flutter use cases.
The polyfill leaks memory by retaining the weak reference target and never calls the finalization callbacks. This is permitted behaviour.
Change-Id: I4f0d08ee6322dab26728d95ca8c24a7fd59b3314
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333304
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This test flakes 0.5% of the time due to long compilation times. It
seems to be intended to be a stress test, so increasing the timeout
seems reasonable.
Change-Id: I508b4e42654dbb01fba9d84bea3bf843d7b59c48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333320
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test returned a future, which in other runtimes may mean that
the test would not be awaited for. The test-runner for DDC does include
extra asyncStart/asyncEnd to ensure the test runs to completion.
However, this sporadically caused double reporting and flaky failures
([example][1]).
This change makes the test itself track the async nature of the test,
just like we do in most other tests today.
[1]: https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8766055193681740753/+/u/test_results/ignored_flaky_test_failure_logs
Change-Id: Ib0edab197db21026d38b40036a1eeaf6edff5ad6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333300
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The changes calls to getInterfaceTypeAsInstanceOfClass (et al.) to
getTypeAsInstanceOf to ensure that we take extension types into account.
Change-Id: I7d732cdae8494002b44561cb02c49d58dd0ba67b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332920
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Refactor libraries so that JSCM will only use `JSStringImpl` class for
strings.
The goal is to disentangle the native string classes and `JSStringImpl`
and start testing `JSStringImpl` in isolation.
Changes:
- `dart:_string` is no longer available in JSCM.
- Make `int.toString` external to allow patching it differently in JSCM
and normal modes.
`toString` implementations are in `boxed_int_to_string.dart` patch
files.
- `int.parse` now uses JS `parseInt`. However `parseInt` is not
compatible with Dart's `int.parse` so this will cause some more test
failures in JSCM for now.
- Any dependencies to `dart:_string` from JSCM `dart:convert` are
removed. The library implementation now uses JS `TextDecoder` for
UTF-8 decoding.
Note: `TextDecoder` is not available on d8, so text decoding tests
will fail on d8.
JSON encoding and decoding in `dart:convert` will be updated in a
follow-up CL.
- Compiler (translator, constant generator, code generator etc.) is
updated to allocate the `JSStringImpl`s in JSCM.
Initially this will make some JSCM test fail as `int` parsing is not
quite right, those will be fixed in follow-up CLs.
Co-authored-by: Joshua Litt <joshualitt@google.com>
Change-Id: I366e06f44cdc369d28fe47b24015234260304399
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332680
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@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>
Previously, if field promotion failed both because the language
version was less than 3.2, *and* for some other reason(s), the
analyzer and CFE only reported the other reason(s). The rationale was
that this was better than reporting just that the language version was
less than 3.2, because if a user upgraded their language version to
3.2 in an attempt to get field promotion to work, and *then* found out
that the property in question was unpromotable for some other reason,
that could be quite frustrating.
With this change, if field promotion fails both because the language
version is less than 3.2 and for some other reason, the analyzer and
CFE report *all* the reasons.
Change-Id: Ib5d3a4621273c1e80d66b66b456119f9053e18b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332485
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
