Preliminary testing shows, this increases performance by around 20%. The
main benefit is by re-using a warmed-up VM and not start one from
scratch for every compilation.
Going forward we can do more optimizations, e.g. reading the platform
dill file only once into memory (instead of repeatedly) ...
=> This requires us using the new state-full IKG compiler.
Issue https://github.com/dart-lang/sdk/issues/31585
Change-Id: I2d3448783fc118611baf4671187a897227a65a6c
Reviewed-on: https://dart-review.googlesource.com/28400
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Some of these are data files that weren't picked up by the migration
script. Some are files that slipped between blocks of tests.
Change-Id: I184dc4701758b280444d54ec55c225ade30f3276
Reviewed-on: https://dart-review.googlesource.com/26423
Reviewed-by: Emily Fortuna <efortuna@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
If a .dill file is specified on the VM command line (dart/dart_bootstrap),
and --kernel-binaries is not specified, then this dill file is used as
the source of platform libraries.
It supports the case of AOT-compiling a self-contained .dill file.
Change-Id: I42956a20b98958b9a2440f156fbbef17bfc359f8
Reviewed-on: https://dart-review.googlesource.com/24341
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Preliminary testing shows, this increases performance by around 20%. The
main benefit is by re-using a warmed-up VM and not start one from
scratch for every compilation.
Going forward we can do more optimizations, e.g. reading the platform
dill file only once into memory (instead of repeatedly) ...
=> This requires us using the new state-full IKG compiler.
Change-Id: I74db7dbb1aa79289d1045ef41f960215cf5b3b35
Reviewed-on: https://dart-review.googlesource.com/28240
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Switch it to use pkg/vm/tool/dart2 which is the source of truth for what
Dart 2 VM configuration means. Don't pass any additional flags from
tools/test.py itself.
Align pkg/vm/tool/dart2 with what tools/test.py was passing to VM on _2 suites.
Make default invocation `tools/test.py -c dartk --strong -m release,debug`
green by updating status files and skipping suites that are not Dart 2.0
compliant. I have filed issues #31588 for isolate suite and #31587 for
service suite.
Change-Id: I882b28f6a011eabf69c349ff0792b275434e39ff
Reviewed-on: https://dart-review.googlesource.com/27820
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
A path like
E:\b\build\slave\[...]\short27_al_args_concrete_subclass_test\E:\b\[...]
is not going to work on Windows, and while a path like
/whatnot/path/blah//whatnot/path
does work in Linux it doesn't look great.
This should fix it (somewhere else than before).
Bug:
Change-Id: I3e926ceb5a5e510b411328872ddc5da9efdf9f2e
Reviewed-on: https://dart-review.googlesource.com/27740
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Required a new flag for test.py; passing tests may have multiple test
cases and to collect that we need the stdout. So you can now pass
--print_passing_stdout to get that.
Parse the result, doing some dances to handle
MM:SS +PP -FF Some tests failed
vs
MM:SS +PP All tests passed!
With even an extra line-ending in the latter case.
Bug:
Change-Id: Ic0b5591b4867508edd3f23a61a7764aa88762be6
Reviewed-on: https://dart-review.googlesource.com/24701
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
A path like
E:\b\build\slave\[...]\short27_al_args_concrete_subclass_test\E:\b\[...]
is not going to work on Windows, and while a path like
/whatnot/path/blah//whatnot/path
does work in Linux it doesn't look great.
This should fix it.
Bug:
Change-Id: I72ef0da3a5fa2d33115745460a3d03f5df506f9f
Reviewed-on: https://dart-review.googlesource.com/27100
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
* The tool pkg/vm/bin/precompiler_kernel_front_end.dart is renamed to
gen_kernel.dart and extended with --aot option (off by default).
Change-Id: I0aaa6c6b4acd1600beba736193fa2ee2d723a581
Reviewed-on: https://dart-review.googlesource.com/26363
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Update dartkp status files, since --strong is now properly passed to the runtime.
Change-Id: I36dcc04a70f46730b24b5aaa2f118ed9baf42cbd
Reviewed-on: https://dart-review.googlesource.com/26561
Reviewed-by: Régis Crelier <regis@google.com>
Obviously, if there is no runtime, a runtime error is never going to
occur. It's silly to force people maintaining status files to have to
manually handle this case. (There are 28 "runtime != none" clauses in
our status files right now.)
Change-Id: Id94157a9fc2635fe6ee9435ce97156b6c4daed5f
Reviewed-on: https://dart-review.googlesource.com/23144
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
If for instance running ddc kernel tests via
tools/test.py -mrelease -cdartdevk language_2 -v
one is told that a http server is started with a command line that will
create a http server listening to 0.0.0.0, while generally the one
actually launched by the testing scripts only listen to 127.0.0.1.
This CL adds the extra --network output to the command line given.
Bug:
Change-Id: Ifd9278360efb0b12249fe866c49ed923f7e73b0e
Reviewed-on: https://dart-review.googlesource.com/24102
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
I was working on adding support for treating RuntimeError as Pass if
runtime == none and I noticed a lot of dead or redundant code, so
cleaned it up some.
Change-Id: I0be451a7075d99bc07d1407883861fb06d777c02
Reviewed-on: https://dart-review.googlesource.com/22800
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This involves a few main pieces:
- Add code to the GN scripts to generate DDC's patched SDK and then
compile it to summaries and JS in the build output directory.
- Add support to the underlying DDC build scripts to support controlling
which files are built where.
- Update test.dart to use the DDC SDK from the build directory.
- Update create_sdk to use the built SDK instead of the checked in one.
- Fix various internal DDC tools to build their own copy of the SDK
(since they can't easily find the one in the build directory because
it's path if config-specific) and use those.
- Delete the checked DDC SDK JS and summaries.
I think I got everything working. The built Dart SDK looks fine -- it's
identical to one built using the old build scripts.
The various tools and DDC's little test runner I *think* work, but there
may be a bug or two in there. I tried the various things I could and it
seems like they work but it's hard to tell since they may be kind of
broken right now anyway.
Bug:
Change-Id: Iea77915a5c1cc8450f60ebfbdf8c725c7ea2f32c
Reviewed-on: https://dart-review.googlesource.com/18144
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Also, --limit-ints-to-64-bits is enabled when running tests in _2 test
suites.
This is the re-landing of 92ebd8aefa with
fixes:
* Revert changes in pkg/dev_compiler/test/browser/language_tests.js
and tests/language/language_dart2js.status as they describe
'language' test suite, not 'language_2'
* Correct tests/standalone_2/io/fuzz_support.dart as file_fuzz test was
timing out on Windows and failing on android/arm.
Closes https://github.com/dart-lang/sdk/issues/31396
Change-Id: If9ca77fca300ddc605f17a7be39d1707e9724e25
Reviewed-on: https://dart-review.googlesource.com/21700
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
* kernel-service.dart is moved to pkg/vm/bin and renamed to
kernel_service.dart
* LICENSE, pubspec.yaml and analysis_options.yaml added to pkg/vm.
* Kernel isolate name is corrected to be independent of URI passed
in --dfe VM option.
Change-Id: I5b7b860297314e240e557af80913e7ac3e6324ad
Reviewed-on: https://dart-review.googlesource.com/21260
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This CL modifies the Dart source used from test.py such that it takes
`syntax error` into account as an expected outcome in test files (so
that we can have `//# 01: syntax error` with a similar meaning as
`//# 01: compile-time error`).
For all tools except the spec_parser, `syntax error` is the same
outcome as `compile-time error`; that is, nobody else will see the
difference.
For the spec_parser, `syntax error` is the outcome where parsing has
failed; `compile-time error` is taken to mean some other compile-time
error, i.e., the spec_parser is expected to _succeed_ when the
expected outcome is `compile-time error`.
Test files in language and language_2 have been adjusted to use the
outcome `syntax error` where appropriate.
The status files in language and language_2 for the spec_parser have
been adjusted such that they fit all the new `syntax error` outcomes
in test files.
Other status files have been adjusted in a few cases where tests were
corrected (because a compile-time error which was clearly not intended
to be a syntax error turned out to be caused by a typo, which means
that the actual compile-time error has never been tested).
The spec grammar Dart.g was adjusted in a few cases, when some bugs
were discovered. In particular, the treatment of Function has been
changed: It is now known by the parser that Function does not take
any type arguments. This makes no difference for developers, because
they cannot declare a type named Function anyway, but it means that
a number of tricky parsing issues were resolved.
Dart.g was also adjusted to allow `qualified` to contain three
identifiers, which is an old bug (preventing things like metadata on
the form `@p.C.myConst`).
Change-Id: Ie420887d45c882ef97c84143365219f8aa0d2933
Reviewed-on: https://dart-review.googlesource.com/18262
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
If you pass "-c" or "-r", but not both, choose a smart default for the
other instead of simply yelling at the user and telling them they
forgot something.
Change-Id: Ic47a20fa8f137a8f6488f16cf883839999e2225b
Reviewed-on: https://dart-review.googlesource.com/16905
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This allows dartdevk to compile tests that import packages like expect.
There are a few pieces to this:
- Add support to build_pkgs.dart to build the kernel summaries for each
test package (in addition to the analyzer summaries it already
builds).
- Plumb that through the dartdevc_test target in the GN build as well.
- While we're at it, use GN to build the ddc_sdk.dill file and have
test.dart load that one instead of the manually built one from calling
./tool/kernel_sdk.dart.
- Add command-line arguments to dartdevk for passing in the path to the
SDK summary and the other summaries to compile against.
- Fix a little typo in processed_options.dart that was preventing it
from resolving "package:" URIs.
- In test.dart, when compiling a test, link in the summaries for all of
the test packages.
At runtime, it still uses the JS for those packages generated from the
old analyzer-based front end since the kernel-based compiler isn't
complete enough to compile any of those packages yet.
With all of this, if I change a test to:
import "package:expect/expect.dart";
main() {
Expect.equals("a", "b");
}
Then it compiles but fails at runtime. The compiler is completing, but
the generated code has some bugs. I don't know enough to fix them
myself, but here's what I've found out:
- In _libraryToModule(), the Library we get from kernel has a null
fileUri, so this returns an empty string. That in turn means the
generated JS tries to use "$" as the module name.
Using this works around it temporarily:
if (moduleName.isEmpty) moduleName = library.name;
- In _emitTopLevelNameNoInterop(), it doesn't handle the case where the
NamedNode is a static method on a class. It just generates the library
and method name, skipping the class, so "Expect.equals(1, 2)" gets
compiled to "expect.equals(1, 2)" instead of
"expect.Expect.equals(1, 2)".
Change-Id: I6bd9d98bc9706965160d8fb7cf70b20eeebab3a8
Reviewed-on: https://dart-review.googlesource.com/16687
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This will make sure that the result.log file will always exist, even if no tests
are run. This also means that the delete result.log step for recipes can be
removed.
Bug:
Change-Id: Idf097acb990b047146a874715f992657deacf65a
Reviewed-on: https://dart-review.googlesource.com/16483
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Morten Krogh-jespersen <mkroghj@google.com>
There was an error so these tests were run unless the --report flag was
present. This fixes that error. Testing for compile-time errors in non-browser
cases is sufficient.
Bug:
Change-Id: Ifeed1a3835297a9308a94de15cabfa119604c75a
R=mkroghj@google.com
Reviewed-on: https://dart-review.googlesource.com/14480
Reviewed-by: Morten Krogh-jespersen <mkroghj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: William Hesse <whesse@google.com>
- Clean up browser test failure output. Instead of barfing a giant blob
of JSON, show just the runtime error and its stack trace. In verbose
and on the buildbots, it still shows all the events, but even there
they are formatted nicely.
- Don't redundantly show the failure summary when most of the output is
already failure text.
- Color the failure summary end message.
Change-Id: I49724b204be55a297fc5e723b80b32e0e00748f0
Reviewed-on: https://dart-review.googlesource.com/15767
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This CL adds handling of previously introduced 'strong-aot'
implementation (target-specific) option into VM target.
After this change, it will be possible to enable strong-mode
whole-program optimizations in Flutter (in addition to standalone VM).
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I054b75ce4ba1b9bcf150e0b7f25fa7ca1bdd187e
Reviewed-on: https://dart-review.googlesource.com/15644
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
It's added as a new compiler, so pass "-c dartdevk" to use it.
It doesn't support any test packages yet, so tests that, say, import
package expect won't compile. I'll work on that next, but it will
require adding some stuff to the build scripts to build .dill files for
those packages.
This does get test.dart invoking the compiler, running the resulting
test, and correctly reporting the result:
- A test that doesn't throw an exception and stays within the bounds of
what is currently implemented in dartdevk passes.
- A test that compiles correctly but fails at runtime fails with a
RuntimeError.
- A test that contains a compile error fails with a non-zero exit code
and is reported as a CompileTimeError.
Change-Id: Icacbf1ff54dfe7aa4d245382d3b0aeb375cf105b
Reviewed-on: https://dart-review.googlesource.com/15420
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Of course, if you're not using the color formatter, it stays uncolored.
But this gets rid of some unnecessary empty lines and section headers
that have no content.
Change-Id: I5b83345c583b79468af84f4e67a12ee757a3105f
Reviewed-on: https://dart-review.googlesource.com/14720
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Aske Simon Christensen