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 .
We're hitting a runtime bug on requestAnimationFrame when we compile
against the latest dart:html in the analyzer (45) but run against the
DDC one (based on 39).
Adding the new type name by hand as a workaround until we roll, but
longer term we'll need to compile and run against the same sdk.
R=alanknight@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/1849133003 .
A couple notes:
- regress_18535_test started failing at runtime. It's using unimplemented mirrors code, so perhaps a static failure before.
- typed_data_sublist_type_dart started failing at runtime. It was inferring Is<EfficientLength> with the type omitted. :-(
- my local chrome is newer than the one on travis failing on generators. not seeing that error.
TBR=jmesserly@google.com
Review URL: https://codereview.chromium.org/1847163002 .
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 .
* factor the class heritage workaround so it's out of the way & easier to remove later.
* always emit type parameters in the AST, and pass the flag to the printer to skip printing them.
* cleanup an unnecessary sync* method for closure field decls.
* also, reformats. I think I forgot to do that in previous CL.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1767803002 .
fixes https://github.com/dart-lang/dev_compiler/issues/471
Changes here are:
* Analyzer now infers list/map literals
* Analyzer changed how isPotentiallyMutated* APIs work, so we need to track current function
* Another fix to arrow functions. We shouldn't skip generating covariant arg checks. If there were any, we use `=> { block }` form rather than `=> expr` form.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1757343002 .
Some of the high level changes are:
* visit catch body, fixes#463
* handle temps created by the compiler. These were in some cases treated incorrectly as non-null (see tests diff)
* compute nullable in the same pass as visiting assignments
* simplify visiting += and ++, fix ++ (it was dead code, #463)
* simplify _isNullable
* if we fail to see a variable declaration, treat it as nullable
* stack trace in catch is treated as non-null
R=vsm@google.com
Review URL: https://codereview.chromium.org/1751963002 .
Main goal here is to isolate some code that was treating parameter declarations differently from other SimpleIdentifiers.
(We're going to need to emit generic method instantiations for SimpleIdentifiers in some cases, so it's going to be important to split out parameters from other expressions)
R=vsm@google.com
Review URL: https://codereview.chromium.org/1744453002 .
Two more small bug caught/fixed in the process:
* Dart lambdas must generate as `=>` functions or we'll get the wrong `this`
* Another case where generators we using destructuring in a mismatched way
R=vsm@google.com
Review URL: https://codereview.chromium.org/1736723002 .
Jacob Richman