The experimental `dart:ffi` support predates deferred loading
implementation. Any use of FFI features would lazily import `ffi.memory`
into the (fixed coded) main module.
This CL now lazily imports the `ffi.memory` module into all modules that
operate on the memory.
=> This will now allow a flutter app that is compiled with dart2wasm
in deferred loading mode to possibly defer parts of flutter
engine code that uses FFI into deferred modules.
Issue https://github.com/dart-lang/sdk/issues/56952
Change-Id: Idf821ce2dd92c36ac1be9dae24307516a1ae86d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510760
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
When generating SSA jump instructions (HContinue and HBreak) for AST break statements, ensure that we only select labels from the target's label list that are explicitly marked as valid continue (isContinueTarget) or break (isBreakTarget) targets.
Previously, handler.labels.first was selected indiscriminately if non-empty, which caused unlabeled continue statements inside loops that had an outer break label to incorrectly generate labeled continue jumps targeting the break label.
Fixes: https://github.com/dart-lang/sdk/issues/63456
Change-Id: Ic497776141a192edb0930f4585cdaae2feecb3d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510280
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
The CFE constructor tear-off lowerings introduce extra static methods.
Tear-off constants refer to them as `StaticTearOffConstant`s. They
just forward the call to the actual generative, factory or
redirecting factory constructors.
We can avoid these intermediary methods by not using the CFE lowerings.
Change-Id: I1dc1203d6b3023cf1f13bc204a2628ec8a3aebc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508562
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Some features in `dart:_wasm` are relevant for all WebAssembly targets
(like interop types or memory intrinsics). Others, in particular the
helper methods to convert between `WasmExternRef` and `JSAny`, don't
make sense for the standalone target.
To be able to remove the `js_interop` library from the standalone
target, we need to stop importing it from `dart:_wasm`. To prepare that
step, this moves the helpers to a new library (`dart:_js_interop_wasm`)
and re-exports them from `dart:_wasm`.
Once Flutter has migrated to the new import, the export can be removed.
Bug: https://github.com/dart-lang/sdk/issues/63166
Change-Id: I13fe875e509a13d16c48d420a5927d3130b90736
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505080
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Simon Binder <oss@simonbinder.eu>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
When deferred loading was enabled the dynamic dispatch class ID table
was incorrectly assigning class IDs to the wrong module. If a contiguous
target segment included classes/targets from different modules, all of
them were getting assigned to the module of the first class/target in
that segment.
This was causing spurious NSM exceptions as the necessary rows in the
table might not be populated for a dynamic call if the module the
segment was assigned to wasn't loaded yet.
To fix this we end the segment if the next target does not belong to the
same module as the active segment.
The new test fails with an NSM exception prior to this fix.
Change-Id: I07bc4fdb5a8bff1bfad5fe17f45c8076a965a775
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502860
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
In some cases, closure contexts were being left out of the parent chain
of their children because they were empty at the time the child closure
was created. If a usage appeared later in the visit of the parent, the
context would no longer be empty but the child would already be created
without a parent.
This was easiest to recreate in sync* function because unlike async, it
doesn't introduce hoisted helper variables (these immediately mark the
parent as non-empty).
In the attached bug the repro only happens with named parameters because
TFA transforms the named parameter into a Let that introduces a variable
before the closure with the usage in the let body after the closure. The
new test explicitly introduces the same pattern of a variable declared
before the closure and used after it.
The fix here is to not eagerly check for emptiness of the parents.
Instead we post-process the Contexts and relink the parent tree skipping
any empty nodes.
Bug: https://github.com/dart-lang/sdk/issues/63264
Change-Id: I2f75506b9fa879544b1a606d8f157fbd44ba8ce2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500680
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This gives around 0.2% improvement in compressed e main module.
In Dart a function with `void` return type can actually return values
that callers can observe. But most of the time this doesn't happen, most
times those functions return `null` values and callers don't observe
them.
Let's use inferred return value information to see if a function is
guaranteed to only return `null`. If so we make the wasm function
signature not return any values. Callers will then synthesize a `null`
which may immediatly be dropped or (in rare cases) actually be used.
This leads to less less instructions in the callee (as a callee doesn't
need to push the null onto the stack) and the caller (as the caller
doesn't have to drop it from the stack).
Change-Id: I3ed1be7592798ad0c697c5bc3ab2c4b64c156f03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/497620
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
This is a re-land of 152cc24, which has been reverted in 3f9ae7. Unlike
the original change, this doesn't alter the `dart:_wasm` library.
We can revisit an API split to remove `js_interop` APIs there once the
standalone target has progressed further.
Original change's description:
> [dart2wasm] Split patch files by whether they use JS interop
>
> The eventual goal of the `dart2wasm_standalone` platform is to not rely
> on a JavaScript environment, which requires rewriting everything that
> currently relies on `js_interop` or `JS()` helpers.
>
> Since most of the patches are still written in Dart and we don't want
> to duplicate that code for the standalone target, this splits patch
> files by whether they rely on JS-interop or not. The main entrypoint
> for each patch (e.g. `lib/_internal/wasm/lib/core_patch.dart`) no
> longer relies on JS-interop and can safely be used in the standalone
> target. Part files that previously needed to use JS-interop have been
> moved into separate patches now, which allows us to migrate them
> incrementally.
>
> In some cases, it was easier to add new patch files:
>
> - Similar to the split between `boxed_int` and the `toString` helper
> patch, we now have the same for `boxed_double`.
> - The functionality to copy from JS typed data wrappers into Dart typed
> lists wouldn't work with standalone, so I've moved it into a separate
> method we can patch to be a noop.
> - `dart:_wasm` exposes APIs to convert between `JSAny` and `externref`.
> This is part of a public API, but I had to move those declarations
> into a patch file because they wouldn't work with standalone.
> Arguably, a separate library (`dart:_wasm_js_interop`?) would be
> cleaner but it might be fine as long as `dart:_wasm` is experimental?
>
> For now, new patch files relying on JS interop are also applied to the
> standalone target. They are marked with a comment indicating that they
> need to be migrated though.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try
Change-Id: I98a628f96cba7e0f0af7e86e058cda43c2c73898
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495302
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This reduces essentials main module around -0.4% and possibly
opens up for changes in the inlining (specifically to possibly
not force-inline all initializers anymore)
This shrinks the amount of information
* initializer result values
* the body parameters
* the allocator needs to forward less from initializer to body
We do that by analyzing constructor parameters to see
which parameters are needed for the constructor
Change-Id: I967fa4102ea6e9d498ff07aedabc368b038e1085
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496341
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This reverts commit 152cc247e0.
Reason for revert: Broken web_ui analysis (see flutter-analyze)
Original change's description:
> [dart2wasm] Split patch files by whether they use JS interop
>
> The eventual goal of the `dart2wasm_standalone` platform is to not rely
> on a JavaScript environment, which requires rewriting everything that
> currently relies on `js_interop` or `JS()` helpers.
>
> Since most of the patches are still written in Dart and we don't want
> to duplicate that code for the standalone target, this splits patch
> files by whether they rely on JS-interop or not. The main entrypoint
> for each patch (e.g. `lib/_internal/wasm/lib/core_patch.dart`) no
> longer relies on JS-interop and can safely be used in the standalone
> target. Part files that previously needed to use JS-interop have been
> moved into separate patches now, which allows us to migrate them
> incrementally.
>
> In some cases, it was easier to add new patch files:
>
> - Similar to the split between `boxed_int` and the `toString` helper
> patch, we now have the same for `boxed_double`.
> - The functionality to copy from JS typed data wrappers into Dart typed
> lists wouldn't work with standalone, so I've moved it into a separate
> method we can patch to be a noop.
> - `dart:_wasm` exposes APIs to convert between `JSAny` and `externref`.
> This is part of a public API, but I had to move those declarations
> into a patch file because they wouldn't work with standalone.
> Arguably, a separate library (`dart:_wasm_js_interop`?) would be
> cleaner but it might be fine as long as `dart:_wasm` is experimental?
>
> For now, new patch files relying on JS interop are also applied to the
> standalone target. They are marked with a comment indicating that they
> need to be migrated though.
>
> Change-Id: I583f23f6cc1a3fc7332962292d69f3a7b0327409
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489660
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I21428bdabcabdbdd07f3453384bb31154083c8aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494920
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The eventual goal of the `dart2wasm_standalone` platform is to not rely
on a JavaScript environment, which requires rewriting everything that
currently relies on `js_interop` or `JS()` helpers.
Since most of the patches are still written in Dart and we don't want
to duplicate that code for the standalone target, this splits patch
files by whether they rely on JS-interop or not. The main entrypoint
for each patch (e.g. `lib/_internal/wasm/lib/core_patch.dart`) no
longer relies on JS-interop and can safely be used in the standalone
target. Part files that previously needed to use JS-interop have been
moved into separate patches now, which allows us to migrate them
incrementally.
In some cases, it was easier to add new patch files:
- Similar to the split between `boxed_int` and the `toString` helper
patch, we now have the same for `boxed_double`.
- The functionality to copy from JS typed data wrappers into Dart typed
lists wouldn't work with standalone, so I've moved it into a separate
method we can patch to be a noop.
- `dart:_wasm` exposes APIs to convert between `JSAny` and `externref`.
This is part of a public API, but I had to move those declarations
into a patch file because they wouldn't work with standalone.
Arguably, a separate library (`dart:_wasm_js_interop`?) would be
cleaner but it might be fine as long as `dart:_wasm` is experimental?
For now, new patch files relying on JS interop are also applied to the
standalone target. They are marked with a comment indicating that they
need to be migrated though.
Change-Id: I583f23f6cc1a3fc7332962292d69f3a7b0327409
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489660
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This reduces e main module size by ~ 0.5-1%
When compiling with deferred loading, we optimize each module
individually with open world assumptions.
Currently we run only one -Os pass which leaves code behind that can be
optimized by another -Os. See e.g. discussion at [0].
The additional -Os pass is much faster than the first, so it doesn't add
meaningful compile-time.
[0] https://github.com/WebAssembly/binaryen/issues/8077
Change-Id: Id8c5e49d97439e28b2f7d9c5a0c206eec0893cad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/490101
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The `Match.operator[]` does the same thing and is
generally recommended (and shorter).
(I want to deprecate `group` and `groups`)
Tested: Refactoring.
CoreLibraryReviewExempt: Calling equivalent function.
Change-Id: I4c758968ae622fe16b7322be1b29b05b91e7fcd9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489021
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Currently a dynamic call will call a helper which will create
3 array objects (for type, positional and named arguments).
It will then pass those wasm arrays to type checker methods.
Those will then get values out of the array, type check and call
the target.
We change this now such that in the normal case (**) we avoid
the array creations. Instead we make a dynamic forwarder function
per target and call shape.
We also outline the array creation when creating `Invocation`
objects. So for simple caller shapes - such as `clone()` the
creation of an `Invocation` object is a call without arguments
instead of various array creations.
Issue https://github.com/dart-lang/sdk/issues/62640
(**) If the dynamic call could be call-via-field we still create
those arrays, as we use them for closure type checking.
Change-Id: Ia8f3f3cd95f650bd8706a15ed68a43db4de80a6e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/487020
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Dart2wasm started using RTA to significantly speed up compilation.
However, a side effect of this is less exact type info during TFA.
In _invokeMain we conditionally use some js-interop logic when a
program's main takes arguments. On the web, most programs don't expect
any arguments so this is usually dead code. However, RTA sees
_invokeInternal is live and blindly treats all reachable classes as live
including the unused interop helper types in the other branches.
This code refactors the patching logic to make sure only the relevant
entry point is considered live.
This change uncovered a different bug that was suppressed by these
implicitly instantiated types. Dart2wasm was not marking some internally
instantiated classes as allocated in the function logic so entries in
the dispatch table were empty for those types. Instead any time we
generate the code for a constructor (which may not be reached via a
ConstructorInvocation like we were assuming before), we record the class
as allocated.
Change-Id: I556d3733c00b4a3e3455fa1ee2c90206d54c81f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/484540
Commit-Queue: Nate Biggs <natebiggs@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>
This updates JS exception catching as discussed in #55481:
- Only catch JS exceptions when the exception type is `dynamic`,
`Object`, or an extension of `JSValue`. (nullable or not)
(Previously we also caught JS exceptions when the type is `Error`.)
- When the JS value caught in Wasm is `null` or `undefined`, box it as a
non-interop class. For compatibility with dart2js, this class is
copied from dart2js and has the same `toString` as the dart2js class.
- In other cases: box the JS values as `JSValue`. This means the value
can be passed as any of the interop types, and can be passed back to
JS without manual jsification.
Fixes#55481.
Issue: https://github.com/dart-lang/sdk/issues/55481
Change-Id: I23e73074729f740b90df2ca8b3c713fb39966556
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/479640
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
- The dependencies of a class should also include the initializers for its fields. These are used to initialize the class object. And they are not represented in the constructor Initializers list.
- Super gets/sets/invocations should all visit their children as well. These aren't leaf nodes.
Change-Id: I552bc87cf1bbc35b11b0dd7bcbd167b2fa5bcbe7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481680
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Today "dummy values" are generated per-module to stand in for things
like default parameter sentinels (where a given selector has multiple
default values for an optional parameter).
However, these values can end up crossing between modules. The logic is
set up to use ref_eq to check if an argument is one of these dummy
values. However, if one of these dummy values crosses between modules,
the passed value vs the ref_eq checked value will be different. Since
each module has its own canonical dummy value per type.
This new layout simplifies our handling of these dummy values by
treating them as Constants so that our normal module canonicalization
logic applies to them. We already have plenty of logic to canonicalize
constants across modules. This avoids the need for custom handling of
these dummy value globals.
Change-Id: Ia9c79923c788d7712b16705193ffbf3142141b5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480320
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Add more Wasm SIMD intrinsics and instructions to support efficient
vector operations, specifically targeting the requirements of types
like Offset and Size.
- Implement new intrinsics in `dart2wasm`:
- `anyTrue` for V128.
- `allTrue` for I64x2.
- `pmin`/`pmax` (pseudo-minimum/maximum) for F64x2.
- `fromLaneValues` for F32x4 and F64x2.
- `shuffle` for F64x2.
- Update `wasm_builder` with support for the following instructions:
- `v128.any_true`
- `i8x16.all_true`, `i16x8.all_true`, `i32x4.all_true`, `i64x2.all_true`
- `i8x16.shuffle` (including serialization and deserialization)
- Add `tests/web/wasm/simd/vector_test.dart`, which implements `Offset`
and `Size` using these new SIMD intrinsics, demonstrating their
practical utility and correctness.
- Update `tests/web/wasm/simd/simd_test.dart` with additional coverage.
Change-Id: Ifa5ba0fb265b0fa46c0a3469d9331f32a025c9ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478860
Commit-Queue: Kevin Moore <kevmoo@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>
If a mixin application class gets copies of the members of a mixin, the
copies may reside in a different library. That means the copied member
body's references to import prefixes are "dangling" (or "pointing" to a
prefix of a different library).
We had a fast case: If there's no deferred import in a library we didn't
visit the body to lower `CheckLibraryIsLoaded` AST nodes.
=> We remove this optimization which will fix the bug.
=> Long term libraries may be allowed to refer prefixes of other
libraries (as part of work on [0])
[0] https://github.com/dart-lang/sdk/issues/61764
Fixes https://github.com/dart-lang/sdk/issues/62683
Change-Id: I74e81418ff2df176ff5481ea36f3b68ab3df4d4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480940
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
In `_JavaScriptError`, instead of using `toString` method of the caught
objects, use the `String` constructor.
Fixes crashes when printing `null` and `undefined` exception values.
This is not directly related to #55481, but the issue was caught while
working on it.
Change-Id: Id6f7124730b4ffa125bd9d0fc8bcf3ed4de15a81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478367
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Currently when we catch an exception thrown from JS we assume that it's
an `Error`, with a `stack` property.
This causes crashes when the exception value is not an `Error`, and the
behavior is also inconsistent with dart2js, which returns an empty stack
trace.
This fixes the crash and makes the behavior consistent with dart2js. To
make sure the behavior stays consistent, the relevant test is updated
and moved from a dart2wasm-specific directory to a web directory.
Change-Id: Ic6af7d919678ba585854c6531a103c0a5764e099
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478400
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reuse dart2js's source map extension format to map minified class names
shown in error messages and runtime type strings ("minified:Class123")
to original class names.
The extension field is only generated when minifying, and with multiple
modules, only in the main module's source map.
- Without minification runtime type strings and error messages already
include the full class name, so mapping is not necessary.
- With multiple modules, the existing tools use the main module's source
map to deobfuscate errors.
Because wasm-opt is not aware of this custom section and it also changes
the names section, when optimizing, we read the original names before
calling wasm-opt, and write the section back to the source map file for
the optimized Wasm.
When not optimizing we generate the source map with the custom section
directly.
Example deobfuscation using the new source maps:
$ dart pkg/dart2js_tools/bin/lookup_name.dart test.wasm.map Class123
Class123 => AsyncError (a global name)
The custom section is a bit verbose for what dart2wasm needs: we could
map numbers to name indices instead of strings to name indices, as
dart2wasm minifies class names to numbers. However to avoid updating a
bunch of tools in g3, SDK, maybe also in Flutter and devtools, we reuse
dart2js's format, at least for now.
Issue: https://github.com/dart-lang/sdk/issues/60711
Change-Id: I2cda331723c6f0c7e7ef5f4772feaf420dc8c6ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/474660
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Split JS-to-Dart conversion functions into two categories:
- Those that handle `null` and `undefined` and return Dart `null`.
- Those that don't expect `null` or `undefined`.
Then based on the return value of an interop function, call the right
one.
This moves null checks from interop call sites to conversion functions,
effectively outlining the duplicated null checks.
Boxing functions like `JSInt8ArrayImpl.fromArrayRef` are renamed as
`fromRef`, for consistency with other boxing functions, and also because
`fromRef` is more accurate. These functions already check the type and
so they can be passed any `externref`, not just those that represent JS
arrays.
Fixes#61906.
Issue: https://github.com/dart-lang/sdk/issues/61906
Change-Id: I54e80fe2e541ae6ef384c2c008f2dbc1e7e3bd76
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/473261
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This adds the `Memory` class to `dart:_wasm`, allowing Dart code to
load and store numeric types in linear memory.
Since `dart2wasm` doesn't generate a memory instance by default, there
is no singleton instance of `Memory`. Instead, memories are defined as
`external` top-level getters annotated with a pragma like
`@pragma('wasm:memory-tyype', MemoryType(limits: Limits(1, 10)))` to
declare their type.
Interop happens in a static way: Methods on `Memory` cannot be torn-off
and, since the target memory is encoded directly in the store/load
instruction, there's also no polymorphism for memories in Dart.
Attempting to call methods on a memory instance that isn't a direct
reference to its definition is a compile-time error.
Memories can also be imported and exported through the existing
`wasm:import` and `wasm:export` pragmas.
TEST=tests/web/wasm/memory_test.dart
Change-Id: I726f33ac2ec04afab55c5a2b6bc09079d0193e02
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/470020
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This issue was partially fixed by:
https://dart-review.googlesource.com/c/sdk/+/428541
However, this only looked at the case of a member in an abstract class
that itself was made abstract if it was unused. TFA does not make the
member abstract if the enclosing class is not abstract:
pkg/vm/lib/transformations/type_flow/transformer.dart#L2289
Instead we can use the unreachable metadata to identify these
unreachable body members (that have default values cleared):
pkg/vm/lib/transformations/type_flow/transformer.dart#L736
Attached test fails prior to this fix.
Bug: https://github.com/dart-lang/sdk/issues/62273
Change-Id: I1ccb818ec41bbe805ee828be0b96ba23e73beae4
Tested: Introduced unit test.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469280
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Example:
import 'dart:js_interop';
@JS()
external void eval(String code);
@JS()
external void throwFunction();
void main() {
eval('''
self.throwFunction = function() {
throw new Error('Hi from JS');
}
''');
try {
throwFunction();
} catch (e, st) {
print(e);
print(st);
}
}
Output before: ("..." parts are code locations, omitted)
JavaScriptError
at module0.main ...
at module0._invokeMain ...
at InstantiatedApp.invokeMain ...
at main ...
at async action ...
at async eventLoop ...
Output after:
Error: Hi from JS
at self.throwFunction ...
at _277 ...
at module0.main ...
at module0._invokeMain ...
at InstantiatedApp.invokeMain ...
at main ...
at async action ...
at async eventLoop ...
Fixes#62218.
Issue: https://github.com/dart-lang/sdk/issues/62218
Change-Id: Ia9347e938af209b8b87752479d35b6236f721acf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469062
Reviewed-by: Martin Kustermann <kustermann@google.com>
There was a bug in `CallTarget.signature` which triggers if there's only
one entry that's statically dispatched against, which causes us to
inline the polymorphic dispatcher, which relies on this (previously
incorrect) signature.
The CL also changes the dispatch table building logic to not allocate
table entries for the statically dispatched regions (as they would
never be used).
Change-Id: Ic2d0c387e8863e89ef811e1892642fe81df9189a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468000
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The generated callback wrappers were referring to exported functions via
'dartInstance.exports' which is always the main module. But in order to
avoid bloating the main module we put some of these JS exports into
submodules.
So the wrapper must be fetched from the correct module that defines the
wrapped function. In order to facilitate this we give each module a
self-reference that it can then pass up to the JS wrapper as an
externref.
Change-Id: Id2514de2c13d38a0cee1f6c935e45a9ef826f805
Fixes: https://github.com/dart-lang/sdk/issues/62094
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464820
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
When accessing a constant under a load guard we can push the constant to
the deferred module (as we only access it under the guard that the
module has been loaded). The access has to therefore also use the
constant initializer function from the deferred module.
We also remove `--extra-compiler-option` prefix for
`--enable-deferred-loading` as the prefix isn't recognized by
dartdev.
Change-Id: I58489303dc10bb265ef730c05a4fc78a8f598edb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464980
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The script was incorrectly handling source maps when deferred
loading is enabled and we emit & optimize multiple wasm modules
(the source maps very completely bogus)
Change-Id: Ib65b72a4d2a3c8958bbe80e94c76145b6e1a0e5b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464480
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
This reduces acx main: module -0.35%, global section: -2.3%
Previous change in [0] made dynamic call sites have per-caller-shape
dynamic forwarders.
In this change we utilize this: Since we know the dynamic caller shape
we can make the dynamic forwarder call via a closure representation that
matches this caller shape (modulo the type arguments - as a dynamic call
without type arguments may get default type arguments of unknown count).
=> This means we no longer have to pass types, positionals and named
arguments as wasm arrays to dynamic call forwarder. Instead we can
pass the arguments unpacked to the vtable.
Additionally we change `Function.apply`: If we know there's no
`Function.apply` usage with named arguments, we can enumerate all
possible closure representations and call the corresponding vtable
entry. We use 2 `br_table` instructions for this:
* branch on number of type parameters
* branch on number of positional parameters
Together these two changes means that neither dynamic forwarders nor
`Function.apply` will use the dynamic call entry.
=> We remove the dynamic call entry from the vtable construction
The only exception to the above are:
* If dynamic submodules is enabled we don't compute closed world
information about closures and always call via dynamic call entry
* If `Function.apply` is used with named arguments then call via dynamic
call entry (and make vtables have it).
[0] https://dart-review.googlesource.com/c/sdk/+/461720
Issue https://github.com/dart-lang/sdk/issues/60458
Change-Id: I26e6a2a48ee37616061d701dc4d4327c2e109e82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462060
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Martin Kustermann