The flag allows for overriding the default (amd) with the ddc module
format when using `--runtime=chrome`.
This is intended to make it easier to test and debug changes to
the ddc module system.
Change-Id: I34767e2e80e9c80af5870bb7f51bf9ebaf438336
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355507
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Ideally we would write each source next to each test to make tests more
readable, but clustering all tests to use a common test file really
helps boost the runtime of the end2end tests now that we reuse the same
page between tests that share the same code.
This CL refactos the tests to mostly use one shared test file. Doing so
speeds up tests between 2x-4x depending on the test.
Change-Id: I9afd00c6a42226899969e3f605ac18e0d2b1a906
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356285
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Since we changed how the test driver sets up breakpoints, we now we
have the ability to reuse a page for multiple tests.
Before, the test harness would follow this sequence:
* on each group of tests, it would call `_initSource`, which sets up
a boostraper and code to execute on the browser. This code was
reused by all tests in the group.
* on each test, it would indirectly call `_loadScript`, which
navigated to brand new page for each test. If there were multiple
tests in a group, this would load the boostraper and code once per
test.
This CL keeps the sequence of operations the same, except, that
`_loadScript` will reuse the existing page if it already loaded the
boostraper and DDC code needed by the next test.
This greatly reduces the total running time of some of the
expresison compiler shards. On my local machine one such test took
24s before both this and the parent CL, but now takes about 5s.
Change-Id: I7774df9e83142b42efc4ad523f589758a2a4660c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356301
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Instead of pausing the application while loading, this
changes the bootstrap logic to not invoke main immediately.
Later the test harness uses an expression evaluation to
trigger the start of the application when it is ready for
it.
This change will enable the ability to reuse the same page
and script across multiple tests, which will save a lot of
test execution time (see related child CL).
Change-Id: Ifa1050ac777aabb3e21b69953e85c6578b3e0cc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356281
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
The data shows a lot of variation by machine. The slowest test samples
bring the p90 above 4s, which explains that we often hit the limit.
I expect that we'll continue seeing flakes, but less often as a result
of this change. That said, some of the e2e test are taking close to 4
minutes, so we may need additional sharding or switch our approach if
that ocurrs more often.
Change-Id: I47c0dbce6f766edf7c2845d26f11ae7c6372a7bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355980
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The hot reload runner currently only supports d8, but I plan to add support for Chrome and VM execution.
Notable changes:
* Creates `package:reload_test` with helpers for running this suite.
* Updates the module loader with D8-specific branches and hooks for hot reload/restart.
* Exposes DDC runtime variables via a `HotReloadTestRuntime` API.
* Ports constant equality hot restart tests from webdev/dwds (validated to fail if either cache-clearing mechanism fails).
* Partially rolls DDC's d8 preamble forward (towards dart2js's).
* Wraps D8's timer implementation with custom timeout logic to better match Chrome's timing semantics when executing with native JS async.
Tests for the framework and matrix updates will be added in an upcoming change.
Change-Id: I2773b29f464cfd0330e4c653c05e117ae150b4a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350021
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Multiple end-to-end tests are failing in the bots because some steps
during the test execution are timing out. We currently have a
timeout of 5 seconds for these steps, but it's unclear if the
timeout is because of conditions in the bot machines (e.g. they are
slow), one off exceptions, or something else.
To address the flakiness, I expect we will want to increase the timeout,
but before we do it may be valuable to start measuring what is the
current distribution of timing in the bots to figure out the best value
to use.
This CL adds logging for timing data for that purpose. I've added
tracking for some interesting steps in the expresson-compiler test
framework, including the top two steps that usually hit a timeout in
practice (find-script and pause-event-for-line).
Example output on my local machine:
```
init-source: 233ms (avg), 121ms (p50), 696ms (p90), 696ms (max), 7 (total)
find-script: 18ms (avg), 18ms (p50), 21ms (p90), 25ms (max), 52 (total)
load-script: 22ms (avg), 22ms (p50), 27ms (p90), 30ms (max), 52 (total)
set-breakpoint: 0ms (avg), 1ms (p50), 1ms (p90), 2ms (max), 52 (total)
pause-event-for-line: 422ms (avg), 410ms (p50), 440ms (p90), 658ms (max), 52 (total)
check-in-frame: 459ms (avg), 446ms (p50), 480ms (p90), 695ms (max), 51 (total)
```
Change-Id: I04734b9905da8e1b4c9d06451be65a2dee32ba1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352988
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
When a macro declaration is supplied as dill, the macro api library
is not directly needed by the source libraries. Therefore, in order
to determine whether macro declarations are available, we need to also
look up the macro api library in the dill loader.
Closes#54560
Change-Id: I131d3881f557566871d9e8c9f38c19029637c534
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346000
Reviewed-by: Morgan :) <davidmorgan@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
After the switch to the new type system more code is unnecessary.
- Clean up logic for deferring classes because the new type system
allows us to flatten the search to just the immediate superclass.
- Delete more `emit<xxx>Type` helper methods.
- Further differentiate emitting a Type vs a reference to a Class.
Fixes: https://github.com/dart-lang/sdk/issues/54745
Change-Id: Ia6e1accb4c9c993967cd5444c18c65938954f7d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/348766
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
The VM target no longer supports the `foo() native "foo";` syntax. See
final removal in [0].
Dart2Wasm has never really been using it.
* In the sdk dart2wasm uses `external` functions with
recognizion in the compiler based on the name of the method.
* JS interop is using `@JS` based mechanism.
* Wasm to Wasm interop is based on `@Native<>()` annotations.
This means that only dart2js/ddc are remaining users of the
`foo() native;` syntax (without following string).
So we can clean up some code.
[0] https://dart-review.googlesource.com/c/sdk/+/266387
Issue https://github.com/dart-lang/sdk/issues/28791
TEST=ci
Change-Id: I929789f7a1ea5ed5423b0db0c6a306406e2db2af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351083
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This CL:
* adds empty dart:_dart2js_only and dart:_ddc_only libraries for use in
conditional imports,
* updates pkg/dart2js_runtime_metrics to use the new libraries rather
than dart:_dart2js_runtime_metrics and dart:js,
* and removes some unnecessary libraries, including VM-specific
implementations in pkg/dart2js_runtime_metrics and the DDC
implementation of dart:_dart2js_runtime_metrics.
Change-Id: I9500aa303fa5ad8aba0e1d413f69957c268f3f11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350681
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This adds the dart:_macros library to the SDK and adds support for accessing dart:_macros from package:macros. The library is not used yet.
This change is needed as a prestep to adding the package:macros and using it in the CFE and analyzer, and needs to be rolled in as the checked in sdk before package:macros can be supported.
TEST=ci
Change-Id: Ife3ffd48527e3a196048d2ddf7387b8b7818f3a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/348680
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Closes https://github.com/dart-lang/sdk/issues/54138
Adds a helper to do better type-checks so that users don't
accidentally using is checks or have to manually do the right
typeof or instanceof checks. In order to do this, there is
some refactoring to make ExportCreator a SharedInteropTransformer
(as it's shared across all backends) so that we can reuse an
existing visitor. In the same class, we remove unnecessary setting
of parent pointers. We should clean up the fileOffsets as well,
but dart2js verifies that those are set, so we keep them as is
for now. Also adds some static errors for edge cases.
CoreLibraryReviewExempt: Helper for web-specific library.
Change-Id: I34d818ada1349b69afd15d170d3fafa0460f65fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347225
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
* Replace `.whereNotNull()` with `.nonNulls` which is now in Dart core.
* `.firstOrNull`, `.lastOrNull`, `.singleOrNull` and `.elementAtOrNull(i)` are also in Dart core and even under the same name, so simply drop the import of 'package:collection' whenever possible.
Bug: b/322159291
Change-Id: I81eb93426680dc78a608bbcc714eb26c0eca5c62
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/348260
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Oleh Prypin <oprypin@google.com>
Fixes the for loop lowering to JavaScript when there are function
expressions in the loop initialization, condition, or updates.
Manually assign source mapping information on js_ast nodes to
make stepping in the Dart debugger make as much sense as possible.
With these mappings three steps are required on each loop variable
on each iteration but it ensures that the mapping always points to the
variable instead of some random line of code in or around the original
for loop.
Fixes the failure on language/loop/for_variable_capture_test.
Issue: https://github.com/dart-lang/language/issues/3539
Change-Id: I755b88faef11804986fb3d1b2c328da3dd08fe8d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345145
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
When landing https://dart-review.googlesource.com/c/sdk/+/342400
the ddc-mac builder (but not Linux and Windows) started failing.
I could reproduce on Linux though so I'm not sure why those builders
didn't fail (nor why it wasn't caught by the try bot), either way this
fixes the issues:
* Test update: E.g. a breakpoint at the end of the scope doesn't work
because it will not be inside the (wanted) scope.
* Test update: Evalating "this" now actually works.
* Scope finding update: DDC adds sourcemapping entries for the *end* of
things so e.g. the getter "c" will have offset and offset+1 added as
source mappings. When translating from javascript position to dart
position we might pick that and thus ask for the scope of offset+1,
but nothing will be found because no node has that offset.
Here I add a fall-back saying that if we get no results we ask again
for the nearest lower offset.
Change-Id: I7e4430d9954466494b514cf51d999358483c9f8c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345501
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Replaces all uses with the equivalent `TYPE_REF()` and
`LEGACY_TYPE_REF()` because they are used in the shared dart:_rti
library and there is no need to support both.
Change-Id: I8c04eb12856cf6933a168f3e63351a45cd5d704e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/344608
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This allows using the new scope finder and facilitates expression
compilation with and in extension types.
For now the script uri is optional (and only passable in the new json
input via package:frontend_server), and only if the script uri is passed
we'll use the new scope finder.
Flutter etc should be updated to pass the new data.
Change-Id: I36eed1ea76a825e63e4c5b9ea60daf18aee39f3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342400
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Updated the ddc canary implementation to handle variance subtyping.
Variance subtyping is currently broken on DDC. This CL emits a runtime call to `addTypeParameterVariances` from `rti.dart` to annotate the type parameter variances of each interface that's appeared in type recipes. The rest of the subtyping algorithm already exists from the Dart2JS implementation, so the variance feature should be working correctly now in DDC with these changes and after the switch to canary by default.
Existing tests now pass: language/variance/variance_in_subtyping_test, language/variance/variance_inout_subtyping_test
Fixes https://github.com/dart-lang/sdk/issues/54367
Change-Id: I8483570184de61f2a6d365f89446720ef2349608
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338651
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Previously we would encode the type of the value returned in `async`
functions as the field `futureValueType` on `FunctionNode`. For all
other kinds of functions, such as `sync`, `sync*`, and `async*`, that
field would be null. This CL renames `futureValueType` into
`emittedVAlueType`, and for functions of kinds `async`, `sync*`, and
`async*` that is expected to be the type of values emitted via
`return` or `yield` statements. For `sync` functions that field is
supposed to contain `null`.
In response to https://github.com/dart-lang/sdk/issues/54159
TEST=existing
Change-Id: I1efdbcc4e75d150f5618c7ca50cfe49a0e54fce6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341662
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Nicholas Shahan