Support "advanced" Closure compilation

[ochafik]

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 (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 integrate with existing JS module systems #284) to let Closure connect classes accross files.

[jmesserly]

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.

[vsmenon]

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.

[ochafik]

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