Highlights
* compile one module at a time
* use summaries to speed up compiles
* use command runner so we can add more commands later
* some long needed renames and file organization
* various other technical debt has been addressed
Lowlights
* lost node.js runner/tests (node output format still supported)
* possibly lost some closure support/workarounds (format still supported)
* needs more end-to-end tests of the new system
R=vsm@google.com
Review URL: https://codereview.chromium.org/1879373004 .
This change removes functionality that is not part of the core Dart Dev
Compiler, in particular those features that were not designed for
incremental/modular compilation.
For a while, the primary way to use DDC will be as a compiler invoked by
a build system, e.g. make or bazel or some node.js based-build system.
We'd love to see the user functionality provided by these return.
In particular, a well designed server+watcher system would be a huge
boost to productivity!
I'll see about moving over HTML reporting to Analyzer CLI. It has a lovely UI.
Thanks to everyone who contributed these features.
The following features were removed:
* DDC transformer. Transformers require whole world, in memory files.
* DDC server. The server has its own mini-build system.
* Various kinds of reporting. These should be moved to Analyzer CLI.
Note: batch compiler and the node runner are left for now.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1788973002 .
function f(a, opts) {
let b = opts && 'b' in opts ? opts.b : null;
let c = opts && 'c' in opts ? opts.c : c_default;
...
After:
function f(a, {b = null, c = c_default} = {}) {
...
Note:
- Still reverting to old code when any parameter clashes with reserved JS names (see discussion in https://github.com/dart-lang/dev_compiler/issues/392)
- When a parameter clashes with a Object.prototype property, using a clean default opts value (Object.create(null)).
- Passing opts through in aliased constructors, both for speed/concision and correctness (since default param value semantic is weird there)
BUG=
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1484263002 .
this avoids reloading file contents many times during a compile. `.contents.data` == bad!
also fixes#73, using Analyzer's LineInfo instead of FileSpan to avoid finding line breaks over and over
I did some manual testing on sunflower as well as diffing SDK messages before and after
The one baseline change (23 -> 22) seems more accurate than it was before.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1141013002
Now the HTML can include a hash in the URL for cachable resources, and the serve knows how to include cache-control headers.
In the process of doing so, I had to change a couple things that made it possible to fix#92 as well (producing different output in the command-line than in server mode).
R=vsm@google.com
Review URL: https://codereview.chromium.org/993213003
This fixes the compiler so that all error messages in dependency_graph are reported via the reporter and unifies how errors are constructed in other places as well. With all errors reported together, we use a widget (adapted from polymer) to display the error messages as part of the app in server mode.
R=vsm@google.com
Review URL: https://codereview.chromium.org/988483006
As part of this change I made codegen synchronous. Technically is not necessary,
but I think it reduces complexity a lot. For example, keeping it async would
have required more changes to the testing infrastructure. Let me know if you
want to keep that change separate though.
With this change, I'm removing one more use of element.node, which is necessary
to achileve our goal. There is only one more use of this API, for which John has
a CL out.
BUG=
R=jmesserly@google.com
Review URL: https://chromereviews.googleplex.com/145167013
