In dart2wasm, implementation class methods for `filled` and `generate`
are much faster:
- In `filled` we use a single `array.fill`.
- In `generate` we update the array directly without bounds checks.
In VM, this shouldn't make things worse, but it may make things better
as the `result[i] = ...` lines will have a more precise receiver types
in the implementation class methods.
This replaces the explicit loops in `List.filled` and `generate`
factories with implementation class `filled` and `generate` methods.
Tested: Existing tests.
Change-Id: Ib24e5be687df325a43d335657a7142f7d9f980ce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321040
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This will allow us to create a better baseline for our MemoryCopy
benchmark optimizations.
TEST=ci
Change-Id: I1ca3928e72fbe49d0239b64ea4f4b78ca0b0a3bb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321160
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This is likely more useful than returning globalThis always. It
allows users to workaround issues with lowerings without having
to worry about browser compatibility differences.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I01479211fe6b573c845de5b134d36338c40fc10d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319301
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Fixes https://github.com/dart-lang/sdk/issues/52955
Instead of globalThis, dart2js and DDC will now use the same global
context that they did for non-static interop. dart2wasm will
continue to use globalThis.
Change-Id: Iec899fc73ed35c50cd688d9b45b980e94f101c0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318520
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
If inlined force-optimized function has to deoptimize, it deoptimizes to before-the-call.
BUG=https://github.com/dart-lang/sdk/issues/38985
TEST=Inliner_InlineForceOptimized, Inliner_InlineAndRunForceOptimized
Change-Id: I6aa4bf1b7ce4d19791132d252e01fc38394c9fcc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317522
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Previously we had started to move core patch files to libraries for
better code organization.
However moving implementation classes to separate libraries required
making the implementation types and internal members public.
This has two problems:
1. The members can be accessed by end users via `dynamic`.
2. More importantly, because those public internal members can impact
TFA results.
We don't care about (1) too much, but (2) is important.
So in this CL we make the libraries part of `core` again, while keeping
the file structure the same when possible.
With implementation files listed as "patches" they can still have their
own imports, but hey won't be importing each other as they're all part
of the same library.
This is the first CL in series that merges `_boxed_int` and
`_boxed_double` libraries back to `core`, and `_typed_data` back to
`typed_data`. Follow-up CLs will merge the other libraries back to
`core`.
The conventions for files is:
- Files that patch core types are named `..._patch.dart`.
- Implementation classes are in separate files. Names of the
implementation files is either the implementation class name (e.g.
`boxed_double.dart` for `_BoxedDouble`), or when implementing multiple
class, name of the library being implemented (e.g. `typed_data.dart`).
Following these conventions, `double.dart` is renamed to
`double_patch.dart`.
Because we lose namespacing for helpers, the helper intrinsics like
`double` `_toInt` are moved to class members, as before.
One problem in the current CL is that in `libraries.yaml`, when I
`include` a target, I can't add more `core` patches to the included
target, the patch section overrides the included patches. I don't know
if this is a bug yet. If it is, we can refactor `libraries.yaml` after
it's fixed.
Tested: Changes covered by existing tests.
Change-Id: Iba7d81d383deff61aad521000f0ca9cf9276dcfb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319500
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This change is intended to be a temporary fix until the broken
internal test is fixed.
Change-Id: I0f6c334bd54c605306318b95836e91755252580f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320340
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This reverts commit 58f4b3a7a6.
Reason for revert: Causes build failures in google3 - b/295404395
Original change's description:
> [dart2js] Use symbols for isolate tags
>
> All supported browsers have JavaScript Symbols so use Symbols.
> Avoiding string property names should fix a bug where separate
> programs running in separate iframes arrive at using the same
> property.
>
> Issue: #53154
> Change-Id: I470dc47de3ad381aeab670cf62d62e53f2e72873
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319865
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Commit-Queue: Stephen Adams <sra@google.com>
Issue: #53154
Change-Id: I581fe08aee6ac9e2d74e813641a942223553cf5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319980
Auto-Submit: Oleh Prypin <oprypin@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Oleh Prypin <oprypin@google.com>
Adds special representations of runtime types for the interface types
`Object`, `Function` and `Record`. With this change, all types with
non-interface subtypes have special representations, which avoids some
special cases down the line.
Change-Id: I61b4da20fa1cc62d42e1770278a3272028c9e2a0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318681
Reviewed-by: Joshua Litt <joshualitt@google.com>
All supported browsers have JavaScript Symbols so use Symbols.
Avoiding string property names should fix a bug where separate
programs running in separate iframes arrive at using the same
property.
Issue: #53154
Change-Id: I470dc47de3ad381aeab670cf62d62e53f2e72873
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319865
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
With this change the Dart Core Object members (`.hashCode`,
`.runtimeType`, `.noSuchMethod()`, `.toString()`, and
`operator ==`) are no longer installed onto the native JavaScript
Object prototype. This is done because the Object prototype will be
sealed as a security precaution in some environments to avoid
prototype pollution exploits.
This means that dispatching to these APIs will change when the
compiler cannot know if the receiver may be null or a value from
JavaScript interop. In those cases a call to a helper method is
inserted instead. The helpers will probe for the API on the value,
call it if available or execute a default version.
NOTE: Many other native JavaScript prototypes are still modified. This
change is only for the Object prototype.
Issue: https://github.com/dart-lang/sdk/issues/49670
Change-Id: Iddb3a48e790dd414aa3254d729535c4408e99b3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310971
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The interceptors provide a Dart `toString` method that uses the JavaScript `toString` method.
Issue: #53106
Change-Id: I1cf1df9e24fb4fd2d79679f1f014f39f083be7e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319563
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This reverts commit 1948b0a9fe.
Reason for revert: causes `promiseToFuture` to become undefined - b/295129286
Original change's description:
> [analyzer] simplify the libraries.dart file
>
> Change-Id: I86bc196eaddd9a80c02f38c8d947d3c0f4c63394
> CoreLibraryReviewExempt: the sdk_library_metadata/libraries.dart is only used by the analyzer
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317803
> Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
> Commit-Queue: Devon Carew <devoncarew@google.com>
Change-Id: I4810c408b996cefd46c0a40cc36818d34aa86071
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319402
Auto-Submit: Oleh Prypin <oprypin@google.com>
Commit-Queue: Oleh Prypin <oprypin@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
This is mainly used in [1] to allow using unboxed int lists when a
factory type argument is `int`, which then allows inlining unboxed int
list `[]` and `[]=` and storing and loading `int` values unboxed.
This implementation is mostly a copy of VM's transformer with the same
name. However we can't reuse VM's pass as we do different
transformations in [1].
[1]: https://dart-review.googlesource.com/c/sdk/+/318680
Change-Id: I16c06fc2b2edb1a5498807fc5c0fee839c003965
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318921
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Change-Id: I86bc196eaddd9a80c02f38c8d947d3c0f4c63394
CoreLibraryReviewExempt: the sdk_library_metadata/libraries.dart is only used by the analyzer
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317803
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Devon Carew <devoncarew@google.com>
Using setProperty triggers assertInterop, which prevents a Dart
Function from being boxed.
Change-Id: Ifa8a068abb7191ccb1c50f2733e6d85df411c945
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317847
Commit-Queue: Joshua Litt <joshualitt@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
- Make Shape class final and more fields final.
- Add minor optimizations to `==`, `.hashCode` and `.toString`.
Cleans up or avoids a few issues I noticed while debugging some performance
regressions when calling Dart Core Object members on record values.
Change-Id: Ida7fdb5c562d03c03330e245e94c80321dc433c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317320
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Flipped the ordering of the equality operation so that the compiler
can see it is being dispatched to a string literal and can generate
a faster check.
Change-Id: I5c2f6b123ebe0f6cb81efba94fe4bf81168bec74
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317261
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Sorting is 2-3x faster for a 1024 element list and simple comparison function.
Change-Id: Iecb4dceb7155e430fcc2c0ddef977003d747ab9c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315760
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This change is almost trivial. The closure is stored on the callback's
RawReceivePort, not in the VM. So we can basically just remove the CFE
check and it pretty much works. The only problem is that we can't set
function.FfiCallbackTarget anymore, so most of the CL is dealing with
that.
A few places were deciding whether an FFI trampoline was a call or a
callback based on whether function.FfiCallbackTarget() was null. But
now the target will be null for async callbacks. So instead I've added
a new value to the FfiCallbackKind enum (and renamed it), and changed
those checks.
Sync callback closures will be a separate CL, because they're more
complicated.
Bug: https://github.com/dart-lang/sdk/issues/52689
Change-Id: I8e5dfb557362e679f66195b735c3c382e6792840
TEST=async_void_function_callbacks_test.dart
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316160
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Following the refactoring we started in previous CLs, this splits string
and int patch files into (1) patch files that only patch and don't add
implementation classes (2) files for implementation classes (3) helpers.
Changes:
- `string_patch` is split into `string.dart` and `string_patch.dart`.
- VM's `integers_patch.dart` copied as `int_patch.dart` and updated.
This was needed as `integers_patch` requires VM's library paths in
imports.
We needed to copy this file to be able to optimize based on
dart2wasm's implementation classes. However in this CL we copy the
file as-is and update import paths.
- VM's `string_buffer_patch.dart` copied to be able to use the string
implementation classes from the new library.
`string_buffer_create.dart` is merged ino `string_buffer_patch.dart`.
- `getHash` and `setHash` to set object identity moved to
`object_helper.dart`, to be able to use in string implementations.
- Redundant `new` keywords in copied files removed.
One TODO added in `string_buffer_patch.dart` when allocating a new
string to the buffer:
// _parts = _GrowableList.withCapacity(10)..add(str);
// TODO(omersa): Uncomment the line above after moving list
// implementations to a library.
_parts = [str];
We can enable the old code again after moving list implementations to a
library.
Change-Id: Ice5dba40b3ba894797028987d4b42cb0c0f0c230
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315821
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
The change in [0] has propagated now everywhere, so we can use
`utf8.encode()` instead of the longer `const Utf8Encoder.convert()`.
As the checked-in SDK has been rolled to include [0] we can now rely on
the better return type.
[0] https://github.com/dart-lang/sdk/issues/52801
TEST=ci
CoreLibraryReviewExempt: Minor cleanup.
Change-Id: I2c0144023e03b2c265582d83a7fb9469b02f1570
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313563
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Define debugger runtime API so the debugger can display objects without knowing DDC implementation details.
- Add new DDC debugger runtime API in `debugger.dart`
- Add helpers for getting some type information in new and old type systems
- Add tests
Closes: https://github.com/dart-lang/sdk/issues/52773
Change-Id: I8efa4cacebb0d73ef58b5360979089cba2039379
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311154
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
- Use `array.copy` and `array.fill` when possible.
- Use the Wasm array directly (instead of `[]` and `[]=`) when possible
to avoid redundant bounds checks.
- `_GrowableList.insert` is rewritten to avoid a redundant write when
the element is not added to the end.
- Remove redundant bounds checks when calling `Lists.copy`.
Change-Id: I08d96b56201cbb4ff24ca969b7fde8bcc1315e4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315120
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Several locations in the core SDK contain `!` or `?.` operations that
will become unnecessary once the language feature `inference-update-2`
(which provides field promotion) is enabled. For example, in this
method from the class `_IOOverridesScope`, `_previous` refers to a
private final field, so after field promotion is enabled, the test `if
(_previous != null)` will promote it, and the `!` in
`_previous!.createDirectory` will become unnecessary:
Directory createDirectory(String path) {
if (_createDirectory != null) return _createDirectory!(path);
if (_previous != null) return _previous!.createDirectory(path);
return super.createDirectory(path);
}
Since the SDK is built in a mode where warnings like this result in
build failures, we need to temporarily change the logic into a form
where the same promotion effect is achieved through local variable
type promotion:
Directory createDirectory(String path) {
if (_createDirectory != null) return _createDirectory!(path);
var previous = _previous;
if (previous != null) return previous.createDirectory(path);
return super.createDirectory(path);
}
(Note that `_createDirectory` doesn't need to change, because it is a
non-final field, so it won't undergo promotion).
After `interface-update-2` has been enabled, I will make a follow-up
CL that removes the local variables and simply takes advantage of
field promotion, e.g.:
Directory createDirectory(String path) {
if (_createDirectory != null) return _createDirectory!(path);
if (_previous != null) return _previous.createDirectory(path);
return super.createDirectory(path);
}
Note: in theory it would be possible to do all this in a single step,
by atomically enabling field promotion and changing the SDK in the
same CL. However, I prefer breaking it up into stages like this,
because the act of flipping a langauge flag on tends to have
wide-ranging consequences, so I want the CL that does the flip to be
as small as possible.
Change-Id: I421c7661348bf407093ee64ef7f9dbfc0c04a353
Bug: https://github.com/dart-lang/language/issues/2020
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/314500
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Because it can, and therefore should.
Also update the methods to use `??` more, which should be
safe now that unsound null safety is no longer a thing.
Avoid chains of override-scopes by inlining the parts of the
outer scope which is not overridden.
Fix two bugs:
* `statSync` was checking whether `_stat` was non-`null`, then
calling `_statSync`.
* `socketConncet` did not pass source port to function.
CoreLibraryReviewExempt: Affects only VM.
Change-Id: I9d4971271305c52948d334f69ae71d750587ed97
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/314880
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Brian Quinlan <bquinlan@google.com>
New typed data implementation that optimizes the common cases.
This uses the best possible representation for the fast case with a
representation like:
class _I32List implements Int32List {
final WasmIntArray<WasmI32> _data;
int operator [](int index) {
// range check
return _data.read(index);
}
void operator []=(int index, int value) {
// range check
_data.writeSigned(index, value);
}
...
}
This gives us the best possible runtime performance in the common cases
of:
- The list is used directly.
- The list is used via a view of the same Wasm element type (e.g. a
`Uint32List` view of a `Int32List`) and with aligned byte offset.
All other classes (`ByteBuffer`, `ByteData`, and view classes)
implemented to be able to support this representation.
Summary of classes:
- One list class per Dart typed data list, with the matching Wasm array
as the buffer (as shown in the example above): `_I8List`, `_U8List`,
`_U8ClampedList`, `_I16List`, `_U16List`, ...
- One list class per Dart typed data list, with mismatching Wasm array
as the buffer. These classes are used when a view is created from a
list, and the original list has a Wasm array with different element
type than the view needs. `_SlowI8List`, `_SlowU8List`, ...
These classes use `ByteData` interface to update the buffer.
- One list class for each of the classes listed above, for immutable
views. `_UnmodifiableI32List`, `_UnmodifiableSlowU64List`, ...
These classes inherit from their modifiable list classes and override
update methods using a mixin.
- One `ByteData` class for each Wasm array type: `_I8ByteData`,
`_I16ByteData`,
...
- One immutable `ByteData` view for each `ByteData` class.
- One `ByteBuffer` class for each Wasm array type: `_I8ByteBuffer`,
`_I16ByteBuffer`, ...
- A single `ByteBuffer` class for the immutable view of a byte buffer.
We don't need one immutable `ByteBuffer` view class per Wasm array
type as `ByteBuffer` API does not provide direct access to the buffer.
Other optimizations:
- `setRange` now uses `array.copy` when possible, which causes a huge
performance win in some benchmarks.
- The new implementation is pure Dart and needs no support or special
cases from the compiler other than the Wasm array type support and
intrinsics like `array.copy`. As a result this removes a bunch of
`entry-point` pragmas and significantly reduces code size in some
cases.
Other changes:
- Patch and implementation files for typed data and SIMD types are split
into separate files. `typed_data_patch.dart` and `simd_patch.dart` now
only contains patched factories. Implementation classes are moved to
`typed_data.dart` and `simd.dart` as libraries `dart:_typed_data` and
`dart:_simd`.
Benchmark results:
This CL significantly improves common cases. New implementation is only
slower than the current implementation when a view uses a Wasm array
type with incompatible element type (for example, `Uint32List` created
from a `Uint64List`).
These cases can still be improved by overriding the relevant `ByteData`
methods. For example, in the example of `Uint32List` view of a
`Uint64List`, by overriding `_I64ByteData.getUint32` to do a single read
then requested bytes don't cross element boundaries in the Wasm array.
These optimizations are left as future work.
Some sample benchmarks:
vector_math matrix_bench before:
Binary size: 133,104 bytes.
MatrixMultiply(RunTime): 201 us.
SIMDMatrixMultiply(RunTime): 3,608 us.
VectorTransform(RunTime): 94 us.
SIMDVectorTransform(RunTime): 833 us.
setViewMatrix(RunTime): 506 us.
aabb2Transform(RunTime): 987 us.
aabb2Rotate(RunTime): 721 us.
aabb3Transform(RunTime): 1,710 us.
aabb3Rotate(RunTime): 1,156 us.
Matrix3.determinant(RunTime): 171 us.
Matrix3.transform(Vector3)(RunTime): 8,550 us.
Matrix3.transform(Vector2)(RunTime): 3924 us.
Matrix3.transposeMultiply(RunTime): 201 us.
vector_math matrix_bench after:
Binary size: 135,198 bytes.
MatrixMultiply(RunTime): 42 us.
SIMDMatrixMultiply(RunTime): 2,068 us.
VectorTransform(RunTime): 12 us.
SIMDVectorTransform(RunTime): 272 us.
setViewMatrix(RunTime): 82 us.
aabb2Transform(RunTime): 167 us.
aabb2Rotate(RunTime): 147 us.
aabb3Transform(RunTime): 194 us.
aabb3Rotate(RunTime): 199 us.
Matrix3.determinant(RunTime): 70 us.
Matrix3.transform(Vector3)(RunTime): 726 us.
Matrix3.transform(Vector2)(RunTime): 504 us.
Matrix3.transposeMultiply(RunTime): 53 us.
FluidMotion before:
Binary size: 121,130 bytes.
FluidMotion(RunTime): 270,625 us.
FluidMotion after:
Binary size: 110,674 bytes.
FluidMotion(RunTime): 71,357 us.
With bound checks omitted (not in this CL), FluidMotion becomes
competitive with `dart2js -O4`:
FluidMotion dart2js -O4:
FluidMotion(RunTime): 47,813 us.
FluidMotion this CL + boud checks omitted:
FluidMotion(RunTime): 51,289 us.
Fixes#52710.
Tested: With existing tests.
Change-Id: I33bf5585c3be5d3919a99af857659cf7d9393df0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312907
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Now that we no longer need to put boxes in `core.dart`, it makes sense to move them out of `core.dart` so that we can patch these classes and their helper functions. This CL moves `BoxedInt` and `BoxedDouble` out of core patch, and moves some of their intrinsics / helpers to side libraries.
Tested: Dart2Wasm internal refactor of patch files.
Change-Id: I1dac95089a8bd9e2c8ee4f467a0d6f2792f9d665
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313900
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
In the new type system, allow native types that have a "peer" on
the Dart side to use that Dart type as their reified type.
This matches the semantics of the old type system for these types.
Change-Id: I62bf6cb1654d33549a6ea2c757e7e65fa81677a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313700
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
The purpose of the wasm_js_compatibility target is to facilitate experiments with a JS compatibility mode for Dart2Wasm. Initially, we're just going to focus on typed data, but this will give us a place to experiment with moving List and String to JS as well.
In addition, someday down the road we hope to experiment with two additional compatibility changes:
1) Exclusively using double for all Dart numbers
2) Allowing undefined to flow as null.
The two major benefits of this approach are:
1) Much faster JS interop
2) To make it easier to bring up Dart2JS applications on Dart2Wasm
The only downside will be access overhead on the Wasm side, but the JS builtins proposal could potentially bring us close to parity with Wasm builtins someday.
Tested: Wasm specific trivial refactor.
Change-Id: I2c09426b6999507c1de6e584e9bc7072a088bda9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313240
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: William Hesse <whesse@google.com>
