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>
This still doesn't *display* then very nicely (they are buried in the
giant blob of "events" JSON in the output), but it captures them and
plumbs them out of the browser into test.dart.
Change-Id: I54ab024ed55f18af89da7742967117f0a212673d
Reviewed-on: https://dart-review.googlesource.com/15005
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Vijay Menon <vsm@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 can compile and run tests on Chrome. There are a lot of failing tests
that I (or the team) will need to triage, but I think at least basic
tests are working as expected.
There is code that could be cleaned up to more neatly factor how dart2js
and dartdevc are handled now that there are two separate compilers to
JS. There's also some redundant code between the path for testing
compile errors (enqueueStandardTest()) and the path for running a test
in the browser.
R=whesse@google.com
Review-Url: https://codereview.chromium.org/2947473002 .
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
- in the base config they are disabled
- in htmnl config they are enabled unless a certain meta tag is present in the
page.
- in vm config they are enabled unless a --no-fancy-stacks flag is in the
Options.
The test runner adds a fancy_stacks flag that can be used to control this
behavior, but by default turns off fancy stacks for all tests.
There were a couple of test runner tests that were affected and have kludgy
fixes where I strip out the new argument from Options first.
This has passed a baseline set of tests; I'm still running a more comprehensive
set.
R=kustermann@google.com, nweiz@google.com
Review URL: https://codereview.chromium.org//22859009
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@26560 260f80e4-7a28-3924-810f-c04153c831b5
The timing of main() execution in dart2js currently occurs after 'loaded' which is quite late in the page load phase (after all images) and is inconsistent with Dartium.
In order to get the timing more consistent with Dartium and more consistent in general this CL makes a couple of changes:
- dart2js generated code is now executed synchronously- this gives end developers more control over timing of main().
- A warning is generated if main() is executed during document parse time- this is primarily to ease the transition and let users know what needs to be done to more closely match Dartium behavior.
- dart.js bootstrapper no longer waits for DOMContentLoaded- the modified script tags will be executed after parse phase, the additional delay should not be necessary.
Breaking changes:
- dart2js main() execution in standard project templates now occurs after document parse but before all assets have been loaded
- Script tags directly referencing dart.js files will now execute synchronously. It's recommended that defer tags be added to these, or that they be moved to the end of the body tag.
- dart.js bootstrapper will now only auto-load script tags which occur before it on the page.
BUG=4718
R=sra@google.com, vsm@google.com
Review URL: https://codereview.chromium.org//22488002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@26149 260f80e4-7a28-3924-810f-c04153c831b5
This is causing issues on dartium builders where we actually only run because there is a build/Release (and out/Release or xcodebuild/Release for mac/linux) on the bot that has been created inside src/dart.
Also, fix the http server in the testing script to serve files from the output directory - otherwise the tests will not be accessible if an alternative build directory is used.
Review URL: https://codereview.chromium.org//12183022
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@18176 260f80e4-7a28-3924-810f-c04153c831b5
Vijay Menon