The dart2wasm compiler treats wasm arrays of objects/ints/floats pretty
much the same, there's no reason to have complicated class hierarchy and
different kinds of wasm array classes.
Also: We rely on all operations on wasm arrays (and other built-in
types) to be handled on the call site. Wasm arrays are not dart objects,
don't support virtual dispatch. So we make operations operating on the
wasm types extensions.
This also makes now loads and stores into the wasm arrays simple `[]` and
`[]=` operations. We still have special extensions for reading/writing
to integer/double arrays that not only read/write but also
sign-extend/zero-extend and operate on Dart's `int` / `double`.
The compiler will allow `WasmArray<X>(length)` for types `X` that have
default-value in wasm arrays (nullable / integer / double types) and
have another `WasmArray<X>.filled(length, X)` for non-nullable reference
types.
Overall this reduces LOCs and simplifies things
Change-Id: I885bed3dfd1c602dc7b0747c69927d464376383d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340881
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
This will allow users who are implementing their own deferred loading mechanism
to batch all the loads for a specific library. Today in order to do batching users have to gather the URIs passed to the `dartDeferedLibraryLoader` hook in a list and schedule (e.g. via setTimeout) a load for some future task.
The need to schedule a task has been shown to cause delays in IPL. But loading each part file individually can also be very expensive. So this allows for a compromise where bundling can be done synchronously per loaded library.
Adds ~8kB to unminified main files and ~2.5kB to minified main files.
Bug: https://github.com/dart-lang/sdk/issues/54202
Change-Id: I623643b03920988cda8b0f8b297944be35ffa606
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340480
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@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>
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>
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>
1. Add `Object` and `Map` to the very short list of names that are
unminified in the app.
2. Tweak test to avoid testing minified name.
Change-Id: Ide0cedc2950b5392eb6963403a48c0f89cd1b50a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332368
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This test has failed with a timeout in a flaky manner: 48% on windows,
13% on linux bots. Unlike other timeouts, this is a legit slow test
because the compiler takes too long to build it. That seems justified
given that this is a stress test for deferred loading, so it is expected
to be slow.
This CL updates the status file for non host-asserts configurations, since the
hostasserts configuration already has 4x budget.
Change-Id: Ie6b53a8c7ef5f6c9b9c6748386db2ae505c2eca2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332281
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
These tests had bugs intronduced during the the null-safety test
migration. Surprisingly the failures didn't show up on some
configurations because the tests were previosly not using the
async-helper wrapper. As a result, the test was logged as completed and
passing before it was done executing. Together this was the cause why
these tests failed in d8 and flaked in firefox.
This CL fixes both issues. A few notes:
* web_2 tests didn't have bugs, but this CL also adds asyncHelper to
match
* it's quite possible that many of these `is` tests are optimized away
in dart2js. I added a couple `confuse` calls when the trivial tests
were highlighted by the analyzer directly (not based on whether or not
dart2js optimized them away).
Change-Id: I8f58c0b0b850023764524f57201eada89a5c0d6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332062
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The existing usage will no longer work as expected once the security
measures to prevent native Object prototype pollution are enabled.
The recommended replacements are `Object.getPrototypeOf()` and
`Object.setPrototypeOf()`.
Change-Id: I0617233bd31ccd2afc9f94c527eecb31c5f1b340
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330047
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@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>
Treat the loop update marker more like an ordinary symbolic value. The old symbolic marker attempted to do widening 'on the fly', which could lead to incorrect results when the update could reset the value to a constant lower than the starting value. The new version moves the widening to a single place, at the loop update.
Fix#53355 by caching intermediate results so that long chains of diamond control flow are not explored exponentially.
There are very few changes in apps. There is one change in a Flutter app that is like the changed codegen/value_range_test where the bounds check can be eliminated because the loop index may be decremented, but not more than the increment, so is still weakly monotonic. There is one change in a large ACX app where a lower bounds check is no longer removed but I *think* it was previously removed incorrectly, though it is hard to tell since it is in a huge function.
Issue: #48465
Issue: #53078
Issue: #53355
Change-Id: Ib125cd6bb30cef52f8dfcd53eaa13e439f26316c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322594
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
The CFE's lowering for record patterns can sometimes make use of late local fields. Dart2JS's late lowerer assumes that all late local fields live in the scope of some function body. Record patterns allow late locals to be created in other contexts though. Some examples that break this assumption include field initializers and expressions in constructor initializer lists.
To fix this we add a late local scope in some extra contexts where these record patterns can show up.
Fixes: 53358
Change-Id: If43b4dd393d0249e6557a54e6e455d52b39e97c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323020
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Adds the same interceptors from dart2js as JsPeerInterfaces
and handles typeof differences in getReifiedType. These must
be JsPeerInterfaces so that Object members can be stored in
their prototype. Tests are added so that dart2js and ddc are
consistent.
Change-Id: Iadc3dd26957c0a21b4039c49c1c1ff162ae286e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321748
Reviewed-by: Stephen Adams <sra@google.com>
This change doesn't seem to have a significant impact on most compilation results:
- Golem results show no significant difference in microbenchmarks.
- For a medium and large app tested, while we see a small change in the actual inference results, the generated code is identical before/after this change.
- Timing and memory usage on internal compilations seem comparable before/after this change.
Note: This replaces the need for any notion of "invalid" refines so I will clean up that code in a follow up change.
Change-Id: I2a293eacd944fc17ee2dab97d3d947c042b4038f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313720
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
A user found another case where this fails (b/290868787).
In this case a ForwardingTypeMask is delegating the subtyping checks to its `forwardTo` mask which ends up saying the masks are equal even though the wrapper around the forwarded masks means they are not equal.
Change-Id: I015f2faf57557ff4189acb6c7144d09cf1ae6bb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313341
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
In order to have the browser send a new request for each retry (each new appended script tag), a query token must be appended to the URI. We don't include any extra tokens on the initial request.
Change-Id: I846660894c16345a441193cd9c7b4784364a3c54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311200
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
- Adds toDartInt and toDartDouble to JSNumber
- Changes semantics of int on external functions from truncate to
assert integer value
- Adds tests for number semantics
- Renames JSExportedDartObject -> JSBoxedDartObject to avoid confusion
with @JSExport
- Adds Object.toJSBox
JSNumber.toDart and Object.toJS will be removed in a future CL once
migrations are complete.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I8ff26ee5624c52703e49dd8483f62e829cb6fff0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309081
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
ConstantEvaluator.isSubtype contains special logic to handle JS number subtyping. It then delegates any recursive subtype checking to TypeEnvironment.isSubtypeOf. TypeEnvironment.isSubtypeOf is not aware of the JS context and has no special logic for JS numbers. This leads to inconsistent behavior when numbers are nested in records. The special number logic is never applied to those nested types.
Fixes: https://github.com/dart-lang/sdk/issues/52619
Change-Id: I72c64bb0544aea79bd83bc589abdda96c851525c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307720
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This was originally implemented in a289c4d but then reverted in dc33261
as it broke Flutter: https://github.com/flutter/flutter/issues/124282.
The problematic code in Flutter was updated, so landing the fix again.
Original commit message:
`emitTypeTest` optimizes a test like `x is List<T>` where `x :
Iterable<T>`, i.e. tested-against type is a subtype of the operand's
static type. In these cases we can check just the class ID of the
operand without checking the type arguments.
However this optimization cannot be done when the types don't have same
number of type arguments. Example:
class H1<T> {}
bool test(Object o) {
return o is H1<num>;
}
void main() {
print(test(H1<Object>()));
}
Here `H1<num> <: Object`, but we still need to check the type parameter.
This CL checks that the types have the same number of type arguments
before optimizing the test.
Fixes#51187.
This fix reveals another bug in `static_interop_test`, which is tracked
in #51200. The test is updated to work around the bug for now.
New passing tests:
- co19/LanguageFeatures/Patterns/matching_cast_A01_t01
- co19/LanguageFeatures/Patterns/matching_list_A01_t01
- co19/LanguageFeatures/Patterns/matching_list_A01_t02
- co19/LanguageFeatures/Patterns/matching_list_A01_t03
- co19/LanguageFeatures/Patterns/matching_map_A01_t01
- co19/LanguageFeatures/Patterns/matching_map_A01_t02
- co19/LanguageFeatures/Patterns/matching_object_A01_t01
- co19/LanguageFeatures/Patterns/matching_object_A01_t02
- co19/LanguageFeatures/Patterns/record_A01_t03
- co19/LanguageFeatures/Patterns/record_A01_t06
- co19/LanguageFeatures/Patterns/record_A01_t07
- co19/LanguageFeatures/Patterns/record_A01_t08
- co19/LanguageFeatures/Patterns/record_A01_t09
- language/generic/deep_test
- language/generic_methods/type_expression_test
- language/patterns/object_pattern_inference_test
Change-Id: Ia08ef466f74c3c55a61d4dbf0088e4b43713ee1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307046
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
The desugared code uses `Completer<bool>` values to suspend the `async*`
function, but we can't use a type test and to check if a value is the
`Completer<bool>` value for the suspension or a user-emitted value as
the `async*` function can also yield `Completer<bool>` values. Update
the test from `value is Completer<bool>` to `!isEven`.
Change-Id: I74f54b838e6a2aab942154ec7f3e667e291523e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304880
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
These tests are flaky or timing out on the stable DDC configurations.
This change adds skips for the canary configurations to avoid crashing
the infra when too many tests that timeout are attempted to be
deflaked.
When the canary mode stabilizes we should manually mark all these
tests as flaky if they are still not passing on the stable DDC
configurations.
Issue: https://github.com/dart-lang/sdk/issues/50666
Change-Id: I9b1cb8fe466624480767fea05610331bf0f4ed87
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302843
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Our helper function to detect whether a null-assertion was required
didn't include a case to check for record types.
The null-assertion flag is likely to go away soon, since it's
only valuable for mixed applications.
Fixes#52276
Change-Id: Ief4515b8c3eaae5343012da4220e6051bb5a2f19
Fixed: 52276
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301680
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
This reverts commit 4919729f00.
This CL also adds back in logic to handle older package:js versions to avoid
failures in our static checking. It also supports dart:js_interop's @JS
annotation since it can now be used for @staticInterop classes.
CoreLibraryReviewExempt: Reland of backend-specific library changes.
Change-Id: I104653a9a6b2593f6bab658808287e2074c18550
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294130
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This is a reland of commit fbe9c21972
This fixes the issue with the duplicate allowPlatformPrivateLibraryAccess.
Original change's description:
> [pkg:js/dart:js_interop] Move annotations to dart:_js_annotations
>
> This moves package:js annotations to the internal library that
> Flutter has been using already. This gives us a single location
> for all package:js annotations. We also introduce a @JS annotation
> in dart:js_interop since we can no longer use dart:_js_annotations
> to avoid the breaking change in semantics.
>
> CoreLibraryReviewExempt: Backend-specific internal library.
> Change-Id: I9ca55c807d7d192004a6da99f63a72d598fe4f12
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284760
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Samuel Rawlins <srawlins@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Joshua Litt <joshualitt@google.com>
CoreLibraryReviewExempt: Relanding.
Change-Id: I40ff2a00682fccbd7dd44a364b5046aaac0f3bac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293203
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Nate Biggs