Some test files were included, where only their data actually
depended on line endings.
Some tests didn't actually depend on line ending at all.
(They may date back to a time where multiline strings didn't
normalize their newlines.)
Fix some syntax tests that had been formatted, and exempt
all files depending on line endings from formatting.
Change-Id: I6c003e9c4f03d3b2af102bfca59d4a7bc8e6d63f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434380
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
By tracking `isCallOnInterceptor`, we avoid the need for class context
information in the `sourceElement` to compute the value. `sourceElement`
is now purely advisory to the choice of local names in codegen, and
can't be the wrong kind of element as in issue #60793.
Bug: #60793
Change-Id: I8bb68b6bf864a3a6f9f2beb40f68a6254431d49a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432003
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
`needsCapture` will ensure that any variables used within an async scope get included in the 'asyncScope' object that's created for that scope.
The variables used to lower Dart late variables in particular get emitted separately. But they can still be used across async scopes so they need the special capture logic as well.
Bug: https://github.com/dart-lang/sdk/issues/60748
Change-Id: I2486fce41f88f186fd799029c2cc59635f7ad8f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429780
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
To make sure Dart values with typed data types like `Uint8List`, `List`,
`String` etc. hold the right type of JS values, check types of JS
references in boxing functions that return Dart typed data types.
To reflect what the functions actually do, and for consistency with
other functions, boxing factory names are changed from `fromJSArray` to
`fromRef`.
New boxing functions `fromRefUnchecked` added for the call sites that
already know the reference type to be the right type, for example in
`dartifyRaw`.
These unchecked functions will also be used in CL 424021 where we
replace some `dartifyRaw` calls with more precise "dartify" functions
that only converts when the type is right. (`dartifyRaw` always boxes
the argument regardless of the type)
Issue: https://github.com/dart-lang/sdk/issues/60357
Change-Id: Icdfb49b9b235d35af2af0c4be51b295ee68d99fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429362
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
When we create a `Selector` we compute various information
based on all members belonging to that selector. Before this
CL this was split up: Some things like `ParameterInfo` was
calculated&updated while discovering members, others was
calculated after all members were discovered.
We now make all fields whose value depends on knowing all
members `late final` and initialize those fields after
having found all members of a selector.
When we compute the `ParameterInfo` of the selector we take
special care:
If there's non-abstract implementations and the selector is
not overridable by dynamic modules then we create the
`ParameterInfo` by looking only at the non-abstract members
=> This increases precision as we ignore the types and
default values of optional parameters for abstract members
If there's no implementations of the selector it may still be
referred to by instance invocation AST nodes (which are
unreachable). The current code generator still needs a
`Selector.signature` in order to evaluate arguments for such
nodes.
=> We calculate `ParameterInfo` based on the abstract member
and use `defaultSentinel` for optional parameters.
If a selector can have implementations in dynamic modules
then we cannot determine whether all implementations have
the same default value of optional parameters.
=> We calculate `ParameterInfo` using `defaultSentinel`
value for all optional parameters. Ensuring the caller
doesn't pass them but the callee will default to it's
default value if it wasn't passed by caller.
See added test case for when we (before this CL) may
use unreachable members in the param info / signature
calculation and how that could lead to a compiler bug
(before this CL) due to a missing
`VariableDeclaration.initializer`
TEST=web/wasm/unreachable_selector_implementation_test
Change-Id: I3628177f8e93c5d24ff0eb0ff8fee6121a4a08d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428541
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This test was intended to capture the existing state of
object members for JS interop and dart:html objects. At some
point, it started failing in ddc, so we add the correct
compiler-specific expectations instead to get it to pass.
Change-Id: I130efc9927a5cb74dafa1b5beb856c7a6ee5a9aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425882
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
html_mocks_with_static_interop_test is currently failing in
the DDC d8 bot. Both this test and object_members_test should be
filtered out in this bot instead of just for dart2js. The latter
is currently failing in the DDC d8 bot as well.
Change-Id: I540056d070fa826b0d4b8e61a6f095c5a9568256
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425881
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
In V8, the only way to pass a Wasm integer or float to JS without
allocation is by passing it as a 31-bit integer.
This can be done by:
1. Passing as `i32`. If the integer fits into 31 bits it's passed
without allocation.
2. Passing as externalized `i31ref`.
(1) requires importing the JS function with different signatures: for
each `int` argument we would need a signature with the `i32` as the Wasm
argument type, and another with `externref` (or `f64` if we want to pass
large integers as `f64`).
This is not feasible as with a JS function with N `int` arguments we
would need `2^N` imports. So we implement (2): we import each interop
function with one signature, passing `externref` as the argument, as
before. When the number fits into 31 bits we convert it to an `i31ref`
and externalize it. Otherwise we convert the number to `externref` as
before, by calling the JS function `(o) => o` imported with type `[f64]
-> [externref]`.
New benchmark checks `int` passing for small (31 bit) and large (larger
than 31 bit) integers. Results before:
WasmJSInterop.call.void.1ArgsSmi(RunTimeRaw): 0.020 ns.
WasmJSInterop.call.void.1ArgsInt(RunTimeRaw): 0.018 ns.
After:
WasmJSInterop.call.void.1ArgsSmi(RunTimeRaw): 0.014 ns.
WasmJSInterop.call.void.1ArgsInt(RunTimeRaw): 0.018 ns.
Issue: https://github.com/dart-lang/sdk/issues/60357
Change-Id: I749001e0e7e9784114415439298c2f3e0fb974b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/419880
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The "new" rti library has been standard for years now and no one should
be passing `--experiment-new-rti` or `--use-old-rti`. We can now clean
up any references to different versions of rtis.
Change-Id: I4421b8943fe5034ed4d259477e8112b25ba0c763
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416326
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
Transform factory calls to default map and set classes to the
constructor calls to the classes to improve kernel.
Also remove some redundant null checks in VM's transformer.
`source_map_simple_optimized_test.dart` is updated: with improved kernel
wasm-opt now eliminates the `testMain` function, so the stack trace
doesn't mention it.
Fixes https://github.com/dart-lang/sdk/issues/60343.
Tested: minor refactoring in VM doesn't need testing. Wasm tested with
existing tests.
Change-Id: Ie448d1374ff0e1b278859f22bc250899e0e4cfd0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416640
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
When parsing `--define` or `-D` arguments don't split the the value by
commas.
This is consistent with how dart2js handles `-D`, but inconsistent with
how VM handles it.
Example:
void main() {
print(const String.fromEnvironment("FOO"));
}
When compiled with `dart compile js -DFOO="a, b"` and run, dart2js
prints
a, b
VM prints (when compiled to exe)
a
Between these two, I think dart2js' behavior is more common, so we
follow dart2js.
Also update compile_benchmark to avoid splitting a single argument "a b"
into "a" and "b" when parsing the arguments and then splicing them back
before calling `dart2wasm`.
Also update the test runner and ddc batch mode argument parser to handle
splitting quoted arguments in `// dart2jsOption = ...` and the same
options for ddc and dart2wasm, by moving dart2js's `splitLine` to a new
library and reusing it in the test runner and ddc.
Fixes https://github.com/flutter/flutter/issues/164873.
See also https://github.com/dart-lang/sdk/issues/60341 for relevant
future work.
Change-Id: Idbdf69072fa212c8e4a390990577eb5a57b49e8a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415280
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This test is a regression test for a dart2wasm compiler crash. It tests
that the compiler doesn't crash anymore but the error happens at
runtime.
The particular error that will happen at runtime is that `unreachable`
will be hit (in the place where a unboxed double is attempted to be cast
to an unboxed integer).
Since we run binaryen with `--traps-never-happen` it may optimize this
`unreachable` away and make the test accidentally pass.
So we force this to be run in `-O0` mode, which means we don't run
binaryen on it.
Change-Id: I6460982d4b32d773ee763e9687c8fec0bffa00f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415881
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@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 async state machine uses a single state in the heap to store the current exception and stacktrace when within a catch block in case they need to be rethrown. When catch blocks are nested this state can be overwritten.
With this new change, before entering a new catch we store the current value of the exception/stacktrace in a local that we can restore after exiting the associated catch blocks. A wasm catch can represent multiple Dart catch blocks so we only need to store the state per wasm catch.
Fixes: https://github.com/dart-lang/sdk/issues/59981
Change-Id: I738084fdecdf5aceac65c5d3698e40b791175171
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/405920
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
In dart2wasm, when a comparison like `x == "hello"` is true, we can't
assume that the class of `x` is the same as the class of `"hello"`:
- If `x` is received from JS, it will be `JSStringImpl`.
- If it's a substring of a `TwoByteString`, it will be `TwoByteString`.
- Otherwise it will be `OneByteString`.
Update `Target` with the new method
```
bool get canInferStringClassAfterEqualityComparison => true;
```
to allow TFA to *not* infer classes of string values after comparisons.
Override the method to return `false` in dart2wasm's `Target`
implementation.
Fixes#59901.
Tested: web/wasm/issue_59901_test
Change-Id: I1a6c8deaf27c54240dd4e821dbd8160914502ad7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404562
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Some scopes that are capturable by closures are not getting marked as such. Instead the parent scope (e.g. the enclosing member) is being treated as the captured scope that owns all the variable declarations down to the closure. The scopes are then being shared across different closures and variables with the same name are able to be overwritten.
This bug occurs for any block that isn't a loop or function (i.e. raw blocks, if blocks, try blocks). Loops are correctly handled as defining a scope and therefore those already work correctly.
Note: This may cause some small code size increase. There may now be extra assignements reseting capture boxes in more scopes.
Bug: https://github.com/dart-lang/sdk/issues/59843
Change-Id: Ic5009188795daabc1544f703fbeca01c0f1951d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403263
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
If the switch's expression has type 'dynamic' and all the case expressions have the same type, we compare them using '=='. This requires a cast to ensure all the types match for the dispatch to the '==' function. However, we don't check that the type of the switch expression matches the type of the case expressions. So the cast fails if they don't match.
This adds a guard to ensure the types match before running through the case expressions. If the guard fails, we either jump to the default case or if there isn't one, we skip the switch entirely.
Fixes: https://github.com/dart-lang/sdk/issues/59782
Change-Id: I12e81f98d1c2046ee47e8ca4371642fd40620636
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/402460
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
HArrayFlagsSet is compiled to a JavaScript statement, but the codegen predicate testing for when a condition subgraph can be compiled to an expression accepts HArrayFlagsSet because it tests for an instruction that has control flow (mostly jumps and checks).
Test for `isJsStatement()` instead.
Bug: #59790
Change-Id: Iafc21aa25490cb93503bb2be1f11dec2f71b5054
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403204
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
The struct type for closures requires the context value be a struct. If the tearoff is on an unboxed value, it first has to be boxed before being used to create the closure struct.
The new test currently fails at runtime (or via assertions at compile time) with this error:
"BoxedInt.abs tear-off" failed: struct.new[2] expected type (ref struct), found local.get of type i64
Change-Id: Ie861bc12a34b21f8b3415edadf55ce3d59f97580
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/402560
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This was missed in the original implementation of the sync* transformer because prior to my recent change, ScopedIds couldn't end up within a DestructuredVariable.
Change-Id: I2733ce1e01edb50659634347204bac1769269615
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401080
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Some wasm engines have started to optimize the `js-string` builtin
proposal (e.g. V8) and those that haven't yet are probaly going to
do soon.
So we can start taking advantage of it in dart2wasm.
=> We make use of them in the JS<->Dart string copy code.
=> This will also provide a better baseline when evaluating whether
switching to JS stringes entirely makes sense.
A somewhat unrelated (but necessary for this CL) change is to tighten
the types we use in `@pragma('wasm:import')` and
`@pragma('wasm:export')` in some cases:
We should only use 'pure' wasm types (i.e. not wasm struct / function
types we define for dart classes & functions) and mostly non-composed
types in import/exports as the `--closed-world` optimizations from
binaryen rely on that (and error otherwise).
Overall this leads to significant improvements in Dart<->JS
string copies.
The `WasmDataTransfer.*{From,To}BrowserString` benchmarks
improve something between 50-100%.
Change-Id: I2048113c462ecb2047402c0616d2b3b1f45773f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/400641
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
The async rewriter was ignoring these variables since they were only used for non-user variables that didn't need to be captured. Now that we use these ScopedIds for user variables we need to capture some of them. "userDefined" specifies if the variable should be captured.
Change-Id: I2dbb86e1834982b59883a3d107612ee8f8e2284a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/400662
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Given input on stdin it has no path to resolve the relative paths that
exists in a status file from. It will thus complain about almost all
lines which is not ideal.
This CL changes it so it doesn't check for it when given data on stdin.
This also means that - because there are no old errors on that account -
if there are such errors now you will be forced to fix it.
The current errors in the status files I could find have also been
fixed.
This should for instance have flaggen when I in
https://dart-review.googlesource.com/c/sdk/+/400320 updated the
pkg.status file but forgot to actually rename the underlying file
(as fixed in https://dart-review.googlesource.com/c/sdk/+/400560).
Technically I suppose it _did_ flag it, but there were also hundreds of
lines of false positives caused by the old status file been given at
stdin to check if there were existing errors - which there then was, thus not forcing me to do anything.
Logical follow-up to https://dart-review.googlesource.com/c/sdk/+/370886
TEST=ci
Change-Id: Ib3533ede88b6d99a31f8b423c00930857e0ba49f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/400620
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This avoids the following error on dart2js bots:
EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'".
Change-Id: I8db11022547566706ced612af86146b7731c35c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397980
Auto-Submit: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@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: I3d6346d31581772dc8e1701594bf9d919f28db7d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396104
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
In the flattened control flow state machine generated for dart2js and ddc async functions, there is a single error state variable per function. However, functions can have nested error handling that may try to access stacked errors separately. When we enter a nested try/catch we should avoid clobbering the outer exception as the outer handler may need it later.
To fix this we maintain a stack of errors that we 'push' to when we enter a new try/catch and which we 'pop' from at the end of executing that try/catch.
Fixes: https://github.com/dart-lang/sdk/issues/57046
Change-Id: Ib96a44ab4152f6f9e444f2ee959ec9aa252800f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395580
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Dart does not incorporate immutability into it's type system.
Though the WasmGC type system does have such a concept:
* mutable wasm arrays: they are invariant in the element type
* immutable wasm arrays: they are covariant in the element type
Currently we use the mutable wasm array types for e.g.
const foo = const WasmArray<WasmI32>.literal([0]);
which will be compiled to
(type $Array<WasmI32> () (array (field (mut i32))))
(global $globalFoo
(ref $Array<WasmI32>)
(i32.const 0)
(array.new_fixed $Array<WasmI32> 1
)
=> Notice the **mut** in `array (field (mut i32))`
This CL introduces a `ImmutableWasmArray` which is analogous to
`WasmArray`. The array supports only reading methods since the
contents of the array cannot be modified.
Future CLs will make use of this new array type in various places.
=> This will allow binaryen to optimize things better as it knows the
array contents cannot change.
=> So loads from a (final) global with immutable contents can be
folded away at compile time if the index is known at compile-time.
NOTE: The `WasmArray`& `ImmutableArray` classes are not related to
each other. The reason is that in WasmGC a mutable array isn't a
subtype of a immutable array.
Change-Id: I3a764b5aaa3ac47827332f3064035133ab01f1b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392900
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@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>
This allows tests that would fail in JS compatibility mode (e.g. tests that do a lot of string manipulation) to disable the mode for their own execution.
Also ensure dart2wasm-*-jscm-* builds do a "create_sdk" so that the dart2js platform dill is available for the test.
The alternative I considered was skipping the test but "--js-compatibility" is a dart2wasm-specific flag and the test infra is unaware of it so we can't skip the test via a status file.
Bug: https://github.com/dart-lang/sdk/issues/56858
Change-Id: I60179eaab2e4522acf1fe0b47c7c02ccb1ca957b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388644
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
After these changes the tests pass 100% of the time on all expected configurations.
- Emit 'unittest-suite-wait-for-done' at the start of tests to allow for async code loading. Tests must therefore emit 'unittest-suite-done' when they complete. Calling `asyncStart` and `asyncEnd` helpers will achieve this.
- Fix test_runner runtime.
- Add file deps on necessary files (dart2js platform dill & flute) to dart2wasm_hostasserts config.
- Mark dart2js compilation test as slow.
Change-Id: Iee993deb3905ccd50068325a5c5fd0bf0512a513
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386980
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Currently when the .wasm file path passed to run_wasm.js is a relative
path, `Uri.base` becomes something like `file://test.wasm`, which is not
a valid file URI, so it causes crashes in `Uri.toFilePath`.
When the file path is relative add a omit `file://` prefix.
`Uri.base` values before and after:
- Before, relative .wasm path: `file://test.wasm` (invalid)
- Before, absolute .wasm path: `file:///home/user/test.wasm`
- After, relative .wasm path: `test.wasm` (fixed)
- After, absolute .wasm path: `file:///home/user/test.wasm` (same as before)
Change-Id: I0d1c43716e07a9ee926e7feeeab514c2c66bac16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385700
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Lasse R.H. Nielsen