This CL adds support to build.py and test.py for building/testing
a VM with the interpreter on x64, e.g.:
$ ./tools/gn.py -m release -a x64 --bytecode
$ ./tools/build.py -m release -a x64 --bytecode runtime
$ ./tools/test.py -m release -a x64 -r vm -c dartkb language_2
Change-Id: I956d23790636609d4a2e71129481fcbd7afef9a0
Reviewed-on: https://dart-review.googlesource.com/65206
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This includes Fasta, tools and observatory, so the checked-in SDK must
have the lower-case constants.
Change-Id: I8380ad041ad058f7d02ae19caccfecd434d13d75
Reviewed-on: https://dart-review.googlesource.com/50201
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
When testing multitests needed files are copied, but some files are
copied multiple times, creating race conditions that might cause tests
to fail because incomplete files are read.
For instance running
"python tools/test.py -m release -c dartk --strong language_2"
is fine (i.e. everything passes), but running
"python tools/test.py -m release -c dartk --strong language_2/generic_constructor_mixin3_test"
can get 0, 1 or 2 errors depending on the computers mood...
This fixes the problem by introducing a map from copied-to-path to Future,
so the same Future is returned when asked to copy a file subsequent times,
thus avoiding the race condition.
Fixes#31368.
Bug:
Change-Id: Id7d4a12424085c75f3543bd06a617121ad5eff35
Reviewed-on: https://dart-review.googlesource.com/32282
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: 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>
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>
- Fix fuzzy arrow errors.
- Default the Dart repo URI so it doesn't always need to be explicitly
set.
- Run dartfmt on everything.
- Move some members out of the garbage bin "TestUtils" class:
- Move the stuff around the Dart repo directory to a new Repository
class.
- Move absolute() into Path where it belongs.
- Move workingDirectory in Path since it is a Path.
- Delete the random number stuff since it was apparently unused.
Change-Id: I3dab3a4f1713b7a749e64b6776149d05a0ce1b69
Reviewed-on: https://dart-review.googlesource.com/14502
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This involves a few pieces:
- Add support to DDC for specifying the module name associated with a
given summary. This lets test.dart invoke DDC using summaries in the
build directory outside of the directory containing the test itself.
- Add support to the build scripts for building the packages. This adds
a new GN target that builds everything needed to run test.dart with
dartdevc. In particular, it invokes build_pkgs.dart to compile the
relevant packages to JS+summary so that the tests can use them.
This requires some changes to build_pkgs.dart so it can output to a
given directory.
- In test.dart, when tests are compiled with dartdevc, pass in the
summaries for the packages so they don't get compiled in. Then, when
the test is run, configure require.js with the right paths to their
JS files so they can be loaded.
I also removed a bunch of unneeded buildDir parameters being passed
around the various CompilerConfiguration class methods now that they
have direct access to the configuration.
Fix#29923.
R=vsm@google.com, whesse@google.com, zra@google.com
Review-Url: https://codereview.chromium.org/2955513002 .
It's still big and monolithic, but it's not as big as it was before.
- Remove old unused Polymer stuff.
- Move some of the logic out into a helper function.
- Other small tweaks.
R=whesse@google.com
Review-Url: https://codereview.chromium.org/2949823003 .
This is a pretty massive change but my hope is it will make
test.dart easier to maintain going forward. Instead of
passing around a stringly-typed Map<String, dynamic> all
throughout the program, we parse the options and then create
a Configuration object that has typed getters for all of the
various bits of configuration data.
This is a little tedious because it means declaring a new
option requires also declaring a corresponding field in the
Configuration class and passing it through the constructor.
I think it's worth it.
Also, enum-like configuration properties like architecture
and runtime now have their own classes as well. Moved a
bunch of stuff from TestUtil into those classes now that
there is an object to hang those methods off of.
In the process, I found a few typos in string literals where
the code wasn't correctly looking up a configuration
property.
Added more sanity checking and validation to status file
parsing. You will get an error at parse time if you try to
refer to a variable that isn't in the whitelist of known
variables. Also, you'll get an error if you try to compare
a variable to a value that it isn't expected to have.
Many other small-scale cleanups.
Aside from the status file validation, this should behave
mostly the same as current test.dart except that tests
may be enqueued in a slightly different order. The
rewritten code for expanding configurations iterates
through the architecture, runtime, etc. options in a
slightly different order.
R=whesse@google.com
Review-Url: https://codereview.chromium.org/2901923003 .
This removes all implicit casts and many implicit uses of dynamic. It
adds a gratuitous number of explicit "as" casts and arguably makes the
code worse.
This is an interim step towards replacing the big configuration map
with an actual typed object. These "as" casts should help catch places
where the configuration object is being used and where the code will
need to be changed to use a new object.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2903703002 .
This doesn't get rid of all implicit dynamic and casts, but it covers
many of them.
Also did some minor modernization when I noticed it:
- Using "var" for local variables where inference does the right thing.
- camelCase for variable names.
- More collection literals.
There are (or should be!) zero behavioral changes.
R=whesse@google.com
Review-Url: https://codereview.chromium.org/2863253002 .
- Fix dartanalyzer warnings about unused variables and missing returns
- Remove trailing whitespace
- Add a dummy pubspec.yaml so editors recognize it as a Dart project
R=whesse@google.com
Review-Url: https://codereview.chromium.org/2633213003 .
This CL adds
- support for fetching dependencies via 'pub get' of samples/packages
- support for building applications/samples via 'pub build' (or a custom
build.dart file)
- pkg/pkgbuild.status: Status files for all package checkouts/builds
- the '--use-public-packages' option to test.dart
- the CleanDirectoryCopyCommand, PubCommand, ModifyPubspecYamlCommand commands
The test suite can be executed with:
$ ./tools/test.py -mrelease --use-sdk pkgbuild
$ ./tools/test.py -mrelease --use-sdk --use-public-packages pkgbuild
R=ricow@google.com
Review URL: https://codereview.chromium.org//122443003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@31535 260f80e4-7a28-3924-810f-c04153c831b5
Currently test.py will look for FAIL/PASS messages in the DOM to determine if a
test has failed or not. test_controller.js will add these PASS/FAIL messages to
the DOM (in addition to other messages).
This approach has several issues:
- The test itself could create nodes in the DOM containing FAIL/PASS. This means
that the outcome of a test cannot be reliably determined.
- The test ifself can remove nodes from the DOM (e.g. setting
document.body.innerHTML). This could result in a situation where the
stacktraces/... test_controller.js prints to the DOM are lost.
- It is unclear which parts of the DOM we see in test failure messages
(reported by test.py) come from the test itself and which parts come from
test_controller.js.
This CL tries to fix this by recording all events that happend with global
variables in test_controller.js and send back a JSON string with information
about
- debug messages
- posted messages
- print() calls of the test
- DOM
- errors (from window.onerror, script.onerror ...)
Furthermore this CL fixes unittest to report
unittest-suite-success/unittest-suite-fail instead of unittest-suite-done (which
is broken).
R=ricow@google.com
Review URL: https://codereview.chromium.org//36913002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30407 260f80e4-7a28-3924-810f-c04153c831b5
William Hesse