dev_compiler icon indicating copy to clipboard operation
dev_compiler copied to clipboard

Published 20 hours ago • verified publisher icon dart-archive

Support "advanced" Closure compilation

Open ochafik opened this issue 9 years ago • 3 comments

Note that DDC supports basic type annotations (when --closure is set #286), but Closure doesn't currently accept DDC's output, not even in SIMPLE mode (#312).

Here are some of the the ADVANCED mode-specific blockers:

  • Minification: need to take care of string vs. identifier mismatches (can use JSCompiler_renameProperty to create renamable strings, see branch closure-annotations-rename-properties)
  • Generics: DDC's pattern isn't recognized (Closure looses track of types). We could:
    • Skip generics altogether (see branch closure-annotations-no-generics)
    • Change the way we build generics (pass optional params in constructor?), which seems rather fiddly.
    • Write a DDC-specific Closure pass that would magically fix things (unclear how, see stubbed pass in branch closure-pass).
  • JS Runtime: right now DDC has a mix of hand-written and compiled code. To get them all to follow the Closure limitations / settings, we'd need to write all of the runtime in Dart (#310) and probably be able to generate a different runtime on the fly (& cache it).
  • Module system: probably need to use goog.module (see #284) to let Closure connect classes accross files.

ochafik avatar Sep 08 '15 17:09 ochafik

I wonder if it would be helpful to stage these.

The things that are for SIMPLE_OPTIMIZATIONS, or for Closure's type checker, seem totally good to tackle first.

I'm a bit more hesitant about ADVANCED_OPTIMIZATIONS. There seems to be a good amount of overlap with what dart2js does for us already. That's fine and I can totally see us getting there. But we were trying to simplify our initial story by making tree shaking/inlining non-goals.

jmesserly avatar Sep 08 '15 19:09 jmesserly

Hey @ochafik , could you break this into 2 issues? One for simple and one for advanced? It's not clear in your list what's needed for simple.

  • Does simple include lowering to ES5?
  • Are current Dart generics an issue for simple?

From a deployment perspective, Closure-simple might already be really useful to smaller scale users who don't need tree shaking or advanced ops.

vsmenon avatar Sep 08 '15 19:09 vsmenon

Split SIMPLE out to #312 (note: that does the ES5 lowering), and filed first-of-many tree-shaking issue for signatures (#313).

ochafik avatar Sep 09 '15 13:09 ochafik