This adds support for BabelJS to test.py's dart2js compiler
configuration. When --babel is specified directly or through a named
configuration, test.py will run an additional step after dart2js that
post-processes the javascript output by running it through BabelJS with
the specified Babel configuration. BabelJS is added to the DEPS in its
standalone form. d8 is used to run BabelJS standalone to avoid adding
a dependency on NodeJS. d8 can only write to stdout but not to files or
stderr, which makes it necessary to change the test_runner to handle
commands that expect their output to be piped to a file.
Changes:
* Add --babel option to test.py.
* Add babel option to pkg/smith.
* Switch IE11 builder to use babel transformation.
* Fix option list comparison bugs in pkg/smith.
* Change dart2js compiler configuration to generate files using the
test name rather than just "out.js" (update test that relied on this).
* Remove runtime_configuration dependency on test_suite.
* Remove obsolete blocks adding --preview-dart-2 dart2js arguments.
* Make dart2js' compiler configuration more like DDC's.
* Remove createCommand method that is no longer used.
* Remove support for "OtherResources" which was only used for
dart:isolate tests on dart2js and DDC.
* Skip co19_2 tests that are slow to transform with babel.
* Simplify the timeout handling in the test runner with Future.timeout.
Change-Id: I32e4917b2a57ecbe684538e40d744f0101c552a0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/90402
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
* Source file location
* Assertion source code
This change embeds the information as strings into the compiled source. In the
future we could reconstruct the source file location at runtime from the stack
trace.
In tests with various large applications this added roughly 1MB (0.1MB
compressed) or less to the compiled file size.
Fixes: #36995
Change-Id: I2634f7eab6e54eec209094b52429987dd62c0828
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103568
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
In rare circumstances we can generate a complete monomorphic
PolymorphicInstanceCall targeting a method of Smi class.
In this case we don't need to check anything - we can simply emit a
static call.
(This fixes a bug in the incorrect fix submitted earlier as
c67b9f2331 - even if call is complete
we still need to check for a smi receiver if there are more possible
receiver classes)
Fixes#37019
Bug: 37019
Change-Id: If0250ba2811f00cc4fe595bf7cd03a7c0d820076
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103809
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
When the .packages file has changed we need to re-check all package-uris
to see if we need to invalidate the builders (if the file uri for a
package uri library (e.g. if the package was upgrade) has changed we
have to invalidate it).
This translation is semi-expensive though, so if we can avoid it that
would be a good thing.
This CL caches the "base URI" for packages from the previous run,
so we can start by comparing the base-URIs: If the base-uri for a
specific package hasn't changed, nor will the actual translation.
Only if the base uri has changed we do the actual translation,
and thus save many package-to-file-uri translations.
An internal benchmark via kernel worker of lots of outline
calculations in worker mode with reuse and the incremental compiler
(where the .packages file change every time and we have lots of
package-uri libraries) goes from ~185 seconds to ~162 seconds.
Change-Id: I3ed48b23a590dbf66f8a2379bb88e1b177f1f034
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103804
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Before this CL we removed from from the builders map, but left them in
the libraries list.
When using the incremental compiler via kernel worker (where we
continually replace dill builders) that meant that this list would just
keep growing.
This CL cleans it up and the builders map and the list should now be
in sync
An internal benchmark via kernel worker of lots of outline
calculations in worker mode with reuse and the incremental compiler
goes from ~215 seconds to ~185 seconds.
Change-Id: I254558d517f544fe31b5673e0dc8748048f0c5ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103630
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This was a left-over from when unbinding, and should no longer be needed.
An internal benchmark of lots of outline calculations in worker mode with
reuse and the incremental compiler goes from ~248 seconds to ~215 seconds.
Change-Id: Iedb6a3fb11504610c061503efb741e35919f0d32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103629
Reviewed-by: Kevin Millikin <kmillikin@google.com>
When invoking the kernel worker in worker mode, reusing previous state,
but not using the incremental compiler, we will currently leak,
see dartbug.com/36983.
This was previously fixed in the incremental compiler case, but this CL
moves the fix outside the if to fix it in every configuration.
Change-Id: I993fecbcc053d2bca64af9e65d270f75411f2e68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103626
Reviewed-by: Kevin Millikin <kmillikin@google.com>
We do not generate explicit control flow and phis for exceptional
edges. Instead CatchBlockEntry has a Parameter instruction for
each local variable. These Parameter-s represent that state
of local variables on entry into the catch block. This means
that we should mark all variables assigned on entry to the
catch block.
Previous version of the code was incorrectly marking only
direct parameters as stored.
Fixes https://github.com/dart-lang/sdk/issues/36953
Bug: 36953
Change-Id: I2e8040d75ba23d2483e451300f44bbdcef458655
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103802
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Merges InlineWeeder and InlineReductive into one visitor and computes
an InlineData object from which all decisions can be made.
Next step is to compute InlineData in the scope visitor (the first visitor
of the first modular phase).
Change-Id: I0c435ae1b3d7afdff1cee7abac657c9362995a67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103632
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This avoids (yet another) inconsistency from the imprecision of
called once. In this case the inlining of some methods that are
called once is dependent on whether we meet their call-site directly
or indirectly first, effectively making the inlining decision subject
to the enqueuing order.
Change-Id: I8d6b9c18fdb82f6d1b566e6bb58344211678daf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103631
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Vijay Menon