This is a reland of commit e7dbd6ba48
Original change's description:
> [dart:js_interop] Make JSFunction and JSExportedDartFunction generic
>
> Fixes https://github.com/dart-lang/sdk/issues/54557
>
> The generic type in JSExportedDartFunction corresponds to the
> static type of the function it wrapped, whereas for JSFunction,
> it's purely a descriptor of the JS function.
>
> When calling JSExportedDartFunction, a cast is now introduced
> to cast it to T.
>
> When calling isA, the type in JSExportedDartFunction is passed
> along to check that the value that is wrapped is that function
> type. Because the T in JSFunction is descriptive, e.g.
> isA<JSFunction<int Function()>>() does no such check.
>
> ____
>
> Also cleans up:
>
> - isA<JSTypedArray>() logic to use intrinsic functions
> - some expectation files to be consistent for both dart2js and ddc.
>
> CoreLibraryReviewExempt: Backend-specific library with needed reviews.
> Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
CoreLibraryReviewExempt: Reland.
Change-Id: I29d706aa4967fd80390e8cb37f8144603ec007f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498100
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit e7dbd6ba48.
Reason for revert: Broke flutter_analyze
Original change's description:
> [dart:js_interop] Make JSFunction and JSExportedDartFunction generic
>
> Fixes https://github.com/dart-lang/sdk/issues/54557
>
> The generic type in JSExportedDartFunction corresponds to the
> static type of the function it wrapped, whereas for JSFunction,
> it's purely a descriptor of the JS function.
>
> When calling JSExportedDartFunction, a cast is now introduced
> to cast it to T.
>
> When calling isA, the type in JSExportedDartFunction is passed
> along to check that the value that is wrapped is that function
> type. Because the T in JSFunction is descriptive, e.g.
> isA<JSFunction<int Function()>>() does no such check.
>
> ____
>
> Also cleans up:
>
> - isA<JSTypedArray>() logic to use intrinsic functions
> - some expectation files to be consistent for both dart2js and ddc.
>
> CoreLibraryReviewExempt: Backend-specific library with needed reviews.
> Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I98447c8c95906feb7f8f1a57859a24fc8e4966d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498080
Commit-Queue: Alexander Aprelev <aam@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Fixes https://github.com/dart-lang/sdk/issues/54557
The generic type in JSExportedDartFunction corresponds to the
static type of the function it wrapped, whereas for JSFunction,
it's purely a descriptor of the JS function.
When calling JSExportedDartFunction, a cast is now introduced
to cast it to T.
When calling isA, the type in JSExportedDartFunction is passed
along to check that the value that is wrapped is that function
type. Because the T in JSFunction is descriptive, e.g.
isA<JSFunction<int Function()>>() does no such check.
____
Also cleans up:
- isA<JSTypedArray>() logic to use intrinsic functions
- some expectation files to be consistent for both dart2js and ddc.
CoreLibraryReviewExempt: Backend-specific library with needed reviews.
Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
dart2js and DDC implement `identical` using JS `===`. This means for
interop values the objects will be compared using JS strict equality
semantics. For Strings in particular this means value equality rather
than reference equality.
In wasm we use equality on the struct reference wrapping the JS value.
This leads to differing semantics between JS and wasm when using
identical on these JS wrapped values.
`jsIdentical` provides a way to have consistent semantics between JS and
wasm.
Change-Id: I207fbbb294254798372924a55cdb2691094a5461
CoreLibraryReviewExempt: Just updating web-related code.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/483440
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Closes https://github.com/dart-lang/sdk/issues/62573
isA<JSExportedDartFunction>() used to just check if the object
was a function, leading to a possible runtime error if `toDart`
is called. Fixes that by introducing some helpers and moving
around some functions in the JS compilers to other internal
libraries (public members can't be added to
js_allow_interop_patch.dart). Also fixes a minor issue in dart2js
where `allowInterop`ed functions could successfully invoke
`JSExportedDartFunction.toDart`.
CoreLibraryReviewExempt: Documentation change.
Change-Id: I5a9d7c31d3143eb3fb6ebd3273a4bf06ca329479
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482967
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Fixes https://github.com/dart-lang/sdk/issues/56905
Instead of just supporting isJSAny and isJSObject, we
can support isA for all objects. Depending on the static
type, we include an intrinsic _isJSAny function first in
the transformation. For fast paths for JSObjects, we also
now call an intrinsic function which has the added benefit
of now correctly returning true for objects with no prototype.
The intrinsic functions in dart2wasm need to be careful to
not treat ExternalDartReferences as JS values, so JSValue
is amended to include a field that determines if the value
is a Dart value (and caches it if not set already). JSValue
constructions are updated to pass false for this field if
we know for sure this value isn't an externalized Dart value.
CoreLibraryReviewExempt: Backend-specific function changes.
Change-Id: Ib2a6e74b4130632791375fcda9a5b85198ad64af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478241
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Not removing from any file with a language marker.
Also not touching anything in `tests/language/primary_constructors`
or `.../private_named_parameters`, which are both assumed to be
primary constructor feature aware.
Two files rewritten from multi-test to error-test.
Change-Id: I43d444a35a41c7734f266794e9f167655692473f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480640
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reverts commit c616db31d2.
Reason for revert: Fix landed downstream in Flutter engine: https://github.com/flutter/flutter/pull/180127
Original change's description:
> Revert "[ DDC / CFE ] Add support for allowing imports of unsupported libraries"
>
> This reverts commit b5e60be49d.
>
> Reason for revert: broke Flutter web engine tests
>
> Original change's description:
> > [ DDC / CFE ] Add support for allowing imports of unsupported libraries
> >
> > This change adds support for allowing for imports of unsupported
> > platform-specific libraries when the
> > `--include-unsupported-platform-library-stubs` flag is provided to the
> > CFE.
> >
> > This flag sets the `includeUnsupportedPlatformLibraryStubs` property in
> > `TargetFlags`, which `Target`s can use to conditionally return different
> > `DartLibrarySupport` objects with different supported/unsupported
> > library sets.
> >
> > A `checkForUnsupportedDartColonImports` function has been added to
> > `Target` that uses the value of `dartLibrarySupport` to determine if
> > there's any unsupported library imports. This function is called after
> > the various transformation operations provided by the `Target`
> > implementation, meaning the import of an unsupported library specified
> > in `dartLibrarySupport` will now result in a compilation error (this
> > includes `dart:mirrors` imports for VM targets when mirrors are
> > disabled, which was previously handled by the VM itself).
> >
> > Related to https://github.com/dart-lang/sdk/issues/62125
> >
> > TEST=Tests added / modified
> >
> > Change-Id: Ife819b2e1a6d28f67d80aab6701cd23a1724aa4d
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465760
> > Reviewed-by: Nicholas Shahan <nshahan@google.com>
> > Reviewed-by: Johnni Winther <johnniwinther@google.com>
> > Commit-Queue: Ben Konyi <bkonyi@google.com>
>
> Change-Id: I0b59f00e55a2424f783351abd977eb38409ce01f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469100
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
Change-Id: I1ae2eac675432286aebabea3c1f58caf35a27fbb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469240
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
This reverts commit b5e60be49d.
Reason for revert: broke Flutter web engine tests
Original change's description:
> [ DDC / CFE ] Add support for allowing imports of unsupported libraries
>
> This change adds support for allowing for imports of unsupported
> platform-specific libraries when the
> `--include-unsupported-platform-library-stubs` flag is provided to the
> CFE.
>
> This flag sets the `includeUnsupportedPlatformLibraryStubs` property in
> `TargetFlags`, which `Target`s can use to conditionally return different
> `DartLibrarySupport` objects with different supported/unsupported
> library sets.
>
> A `checkForUnsupportedDartColonImports` function has been added to
> `Target` that uses the value of `dartLibrarySupport` to determine if
> there's any unsupported library imports. This function is called after
> the various transformation operations provided by the `Target`
> implementation, meaning the import of an unsupported library specified
> in `dartLibrarySupport` will now result in a compilation error (this
> includes `dart:mirrors` imports for VM targets when mirrors are
> disabled, which was previously handled by the VM itself).
>
> Related to https://github.com/dart-lang/sdk/issues/62125
>
> TEST=Tests added / modified
>
> Change-Id: Ife819b2e1a6d28f67d80aab6701cd23a1724aa4d
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465760
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Commit-Queue: Ben Konyi <bkonyi@google.com>
Change-Id: I0b59f00e55a2424f783351abd977eb38409ce01f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469100
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This change adds support for allowing for imports of unsupported
platform-specific libraries when the
`--include-unsupported-platform-library-stubs` flag is provided to the
CFE.
This flag sets the `includeUnsupportedPlatformLibraryStubs` property in
`TargetFlags`, which `Target`s can use to conditionally return different
`DartLibrarySupport` objects with different supported/unsupported
library sets.
A `checkForUnsupportedDartColonImports` function has been added to
`Target` that uses the value of `dartLibrarySupport` to determine if
there's any unsupported library imports. This function is called after
the various transformation operations provided by the `Target`
implementation, meaning the import of an unsupported library specified
in `dartLibrarySupport` will now result in a compilation error (this
includes `dart:mirrors` imports for VM targets when mirrors are
disabled, which was previously handled by the VM itself).
Related to https://github.com/dart-lang/sdk/issues/62125
TEST=Tests added / modified
Change-Id: Ife819b2e1a6d28f67d80aab6701cd23a1724aa4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465760
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Since that stops `dart:_js_annotations` from building on dart2wasm,
let's stop supporting that, too.
This causes `package:js` to no longer work on dart2wasm, but none of the
allowlisted packages use it any longer, so we can simply migrate tests
off of it.
Fixes: #56502Fixes: #61550
Change-Id: I6a6a696438255ebf25a5a17131cdbd327ba81581
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453645
Commit-Queue: Mayank Patke <fishythefish@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
These tests need to run on dart2wasm but use `dart:js_util`, which
dart2wasm will no longer support.
`js_util` isn't core to the behavior being tested in
tests/lib/js/static_interop_test/; it's simply how the expectations were
written. This CL migrates those tests to use the new `dart:js_interop`
APIs for expectations.
Since dart2wasm no longer supports `dart:js_util`, which includes
`createStaticInteropMock`, it can simply skip
tests/lib/js/export/static_interop_mock/* in the status file.
We also split up tests/lib/js/export/functional_test into two separate
tests - one for `createDartExport` (which is also skipped on dart2wasm),
and one for `createJSInteropWrapper` (which runs on all web backends).
These tests can still share most of the code in a common library.
Bug: #61550
Change-Id: I6a6a6964b6f914fea5b42101204ab80910c49b36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/451221
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Fixes https://github.com/dart-lang/sdk/issues/61543
toJS and jsify conversions instantiate a new typed array using
the same underlying buffer instead of returning the original
typed array. To fix this, the typed array wrappers now capture
the original array ref (if any) and return it in toJSArrayExternRef
if it exists and the caller didn't ask for a subrange.
Note that _ref in the wrappers refer to a DataView, and not
the array ref. Some methods are renamed to reduce that confusion.
Change-Id: Ia9befd114a77489aedbb3644c9604aef4b3af7c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/450966
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
dart2js and ddc both have a rich enough JS AST to use
dot or bracket notation when necessary. Therefore,
both compilers have and do support @JS renames that
contain characters that aren't supported in dot
notation e.g. `my-lib`. We should have dart2wasm also
support such characters to be consistent, but prefer
dot notation and avoid adding extra `globalThis`
when possible.
Change-Id: Iabf4d6f88dd23321388841f3a6b64758f856c68f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447964
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Fixes https://github.com/dart-lang/sdk/issues/61411
This was previously disallowed for static members in pkg:js
classes, but an error was never added for dart:js_interop types.
We could add an error, but this is useful for both static and
non-static members so users don't have to introduce new top-levels
or types just to access a nested member. This also makes it
consistent with dart2wasm.
Updates some front_end expectations tests as well to test
more syntax and renamed members.
Change-Id: I690d53d64fedc5869e1bdd9f7cfd86d256d7f75b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447482
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Currently _emitArgumentList handles arguments for Dart
members, JS interop members, and object literal constructors.
It requires an Arguments node, which we end up synthesizing,
which messes with parent pointers erroneously. We also have
to separate out the arguments and do additional checks later
to detect whether the arguments passed correspond to an
object literal constructor.
Instead, we should create the resulting expression directly
in a helper method. A map is passed so that the names of
arguments can be easily changed when we handle @JS renaming
on object literal constructors. Lastly, we need to avoid
wrapping the values with assertInterop in the case where the
constructor is from a dart:js_interop interface. That library
only statically allows Functions to be passed if they're
externalized, in which case we shouldn't tell users to wrap
the Function with allowInterop (which doesn't exist anyways in
dart:js_interop).
Change-Id: If6fdc706e80837ab2b698cca704ffd9f08aed28a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446184
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Fixes https://github.com/dart-lang/sdk/issues/60644
Previously, we made no special case for JSBoxedDartObjects, so isA
would always return true for any object (as JSBoxedDartObject contains
an @JS('Object') annotation). This is not obvious however, and it's
much more useful to check that the value is a result of a previous
`toJSBox` call. Documentation is updated/cleaned up to make note of
the various exceptions in `isA`.
CoreLibraryReviewExempt: Web-only library.
Change-Id: Ibd8873d3f862f4c950101f5f049327a1aa5c7bf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445522
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Fixes https://github.com/dart-lang/sdk/issues/59830
Migration from Lists to JSArray sometimes involve usages
of List.add. In the migration, if List.add was used, it would
become JSAnyOperationExtension.add, which is the JS + operator.
This then leads to bugs where users mistakenly assumed that
something similar to List.add was occurring.
CoreLibraryReviewExempt: Wasm and JS backends only.
Change-Id: I2bb6684316725167a8fa65fd51483f2717788dad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/443182
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Fixes https://github.com/dart-lang/sdk/issues/61085
If a member that is not exportable is marked for export, we
mark it as an error using the member's name. In the case of
unnamed members, however, we don't have a name, and therefore
the template throws an error as it doesn't have a valid arg.
Instead, use "<unnamed>" in the absence of a name.
Change-Id: Ie0776c95f775eb3f09f582d0386a2097beedc7fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/439641
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Previously, the implementation worked around boxing limitations
by always setting this field to false. However, because we
control both the callback and the JS code that calls the rejection
function, we can pass more information to the callback to let it
know whether the error was undefined.
Change-Id: Ic19f24ec20d321859eb8184d5c87744f7679cf0c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/439141
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
https://github.com/dart-lang/sdk/issues/56455
The existing native typed data implementation in dart2js/ddc
and the JS typed data wrappers in dart2wasm do not support
SharedArrayBuffers.
In dart2js/ddc, this is because the native type for ByteBuffer
is simply ArrayBuffer, leading to type failures when using
SharedArrayBuffers. To handle this, this change makes NativeByteBuffer
an abstract parent class to NativeArrayBuffer and NativeSharedArrayBuffer.
This allows ByteBuffer to support both types. There is a preexisting
SharedArrayBuffer type in dart:html that we should avoid breaking, so
we add an interface that NativeSharedArrayBuffer implements and expose
that interface.
In dart2wasm, JSArrayBufferImpl only allows ArrayBuffers as its
extern ref. This change makes that wrapper support SharedArrayBuffers
as well.
In dart:js_interop, the existing toJS conversion on ByteBuffer
now throws if the underlying buffer was actually a SharedArrayBuffer.
This is to support the return type of JSArrayBuffer. This behavior
technically already existed due to type differences in the JS
compilers, but was never possible with dart2wasm.
CoreLibraryReviewExempt: Backend-specific libraries with no real functional changes to public APIs.
Change-Id: I4dac9fb808590bf0c274da815c152cd4637316b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437526
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
eval is disallowed by CSP and the dart2js-minified-csp-linux-chrome
bot is currently red. This uses Math.max, which should be available
both on d8 and with CSP enabled.
Change-Id: I5e348a72d50cf10db713934151473f0d15782ba3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421502
Commit-Queue: Ömer Ağacan <omersa@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
This is a reland of commit 4bb05dc562
Initial commit didn't properly box the `void` return value, so when we
cast the return value to `ref #Top` to pass it to a Dart function (as
`Object?` or `dynamic`) it caused "illegal cast" traps.
In this commit we properly box the `externref` as `JSValue` (a proper
Dart class). A new test added passing the return value of a `void` JS
return to `print`.
Original change's description:
> [dart2wasm] Don't dartify JS values when returning as void
>
> When calling a JS function that returns `void`, avoid dartifying the
> result.
>
> Technically the return value of `void` functions can still be used, by
> casting the return type to `Object?` or `dynamic`. However this
> shouldn't be done, and `dartifyRaw` overhead just to support this case
> which should be extremely rare is too much.
>
> Any hacky code that uses return values of `void`-returning JS interop
> functions can manually dartify the retrun values with `toDart` or
> similar.
>
> Issue: https://github.com/dart-lang/sdk/issues/60357
> Change-Id: Ic370c7cf6eb6982f61f8a07c91e3bb93c5345ac6
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417240
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Ömer Ağacan <omersa@google.com>
Change-Id: I264211cca4f6b87e63d68909647975ab96f0b5bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421080
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Currently we have 3 different string types (JS Strings, OneByteString
and TwoByteString)s. There's some advantages to this, mainly that
if strings are used purely inside Dart we have more control over
optimizing them. But it does come with some issues
* Operations on mixture of strings are slow
* We get JS strings from outside (in DevTools e.g. websocket messages)
* Any kind of DOM interaction requires copying strings
* Regular expression matches can result in O(N*N) instead of O(N)
* Encoding of string literals/constants is terrible, high size overhead
* ...
Now that there's a standardized way to access JS strings (via
the `js-string` builtin spec) and this standard is finalized and
enabled in Chrome & Firefox it makes sense for us to switch to it.
It reduces app size:
* Smaller size: hello world -25%, flute -5.5%
* Faster startup
The performance changes are nuanced, some workloads will improve
significantly, some workloads will regress.
Improvements will come especially in cases where
strings are concatenated (due to JS not actually allocating new
strings in this case). That impacts e.g. string interpolations,
string buffer, json-to-string encoding, ...
Regressions will come especially for cases where we have to
construct strings from bytes (e.g. in utf8 decoder, utf8+json
decoder) - mainly due to having to go through an intermediary
`WasmArray<WasmI16>` to allocate strings. Also in cases where we
access individual char codes from the strings.
There's some follow-up improvements we can do, but it's better to
not iterate on this CL even longer but get it landed.
This CL will make the benchmarking system use
`--require-js-string-builtin` as well as most of test CI
(in `pkg/dart2wasm/tool/compile_benchmark`)
Though we run some configurations via overriding with
`--no-require-js-string-builtin`
(in `tools/bots/test_matrix.json`)
Issue https://github.com/flutter/flutter/issues/159400#issuecomment-2538593980
Issue https://github.com/dart-lang/sdk/issues/59699
TEST=ci
Change-Id: I238ac65efe092de569da870f23134f889ac929f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392903
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The new formatter supports opting a region of code out from being
formatted. I'm applying this marker to all of the multitests since
those tests are often very sensitive to formatting and easily broken.
This way, anyone touching a multitest (including me when I reformat
the tests) doesn't have to remember to not run the formatter on it.
Change-Id: I34831719cd35e669b49e02a0d00c32b44068a34e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396103
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Collects files from `package:async_helper` and `tests/language`
that are generally useful, so that all test-related helpers are
in `package:expect`.
Moves the two libraries from `package:async_helper` into `package:expect`,
and the `tests/language/static_type_helper.dart` file too.
Deprecates `async_minitest.dart`, to follow `minitest.dart`,
expecting the Flutter use of it to have been fixed to not break
on deprecation (I believe Flutter no longer breaks builds on deprecations at all).
Patch 1 is the actual change.
Patch 2+4+8 is changing all existing references to the files.
Patch 6 ignores deprecation in files still using `async_minitest.dart`.
3+5+7+9 are updating this text to make the numbers match.
Then it's just test-expectations and small tweaks from there.
Change-Id: I1b665135b5fef9b9a0c3b340ffe9daf874d0174c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373120
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Tests that we can use JSAny? as the type without
violating cross-origin policy. This will then be
used in package:web to implement a wrapper.
Change-Id: Ic30557138b61e27e421747ead81ea2fb7f6db240
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381886
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Clean up and optimize some RegExps, and fix uses of `.group`.
Switch to a newer language version, to be able to use newer features.
Add a little documentation about why some RegExps are as they are.
Add (tentative) warning for multitests.
Change-Id: I59f73b87ce30caaeca1c0e0aa7954af1b97abd1b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382620
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Srujan Gaddam