Support (de)serialization from command-line

pkg/compiler/lib/src/commandline_options.dart

 // Copyright (c) 2015, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 library dart2js.cmdline.options;
 
 /// Commandline flags used in `dart2js.dart` and/or `apiimpl.dart`.
 class Flags {
   static const String allowMockCompilation = '--allow-mock-compilation';
   static const String allowNativeExtensions = '--allow-native-extensions';
@@ skipping 40 matching lines @@
 
   static const String conditionalDirectives = '--conditional-directives';
 
   // Experimental flags.
   static const String genericMethodSyntax = '--generic-method-syntax';
 }
 
 class Option {
   static const String showPackageWarnings =
       '${Flags.showPackageWarnings}|${Flags.showPackageWarnings}=.*';
+
+  // Experimental options.

[Siggi Cherem (dart-lang), 2016/05/14 01:10:31]

Several ideas/comments about how to expose the flags:

a. "*-source": it would be good to support a list of sources right away :)

b. "*-target": let's make the feature itself a boolean flag instead, and
overload the `--out` flag to specify the output file if so desired.

c. let's use a word that better describe the feature we are exposing. So instead
of "serialization", maybe we could use refer to "resolution" or the fact that
this is lowering to a shared ir? For example:
  --emit-resolved-data
  --resolve-only
  --output=ir // overload the output=dart flag we used to have :)
  --summarize // this is the term used by dart-analyzer/ddc

Other ideas? Currently `--resolve-only` is the one that is winning for me. I
guess later on we will have separate binaries, so the flags can be more
straightforward.


Putting this together I can imagine an API like this:

- compile a.dart into a.js:
    dart2js a.dart

- compile a.dart into foo.js:
    dart2js -o foo.js a.dart

- emit the resolution data for a.dart into a.data
    dart2js --resolve-only a.dart

- emit the resolution data for a.dart into foo.data
    dart2js --resolve-only -o foo.data a.dart

- emit the resolution data for a.dart and b.dart into foo.data
    dart2js --resolve-only -o foo.data a.dart b.dart

- use resolution data from i.data and j.data
    dart2js --resolve-only --input=i.data,j.data -o foo.data a.dart b.dart

 Or, we could overload the list of arguments too, for example:

    dart2js --resolve-only -o foo.data a.dart b.dart i.data j.data

Thoughts?

[Johnni Winther, 2016/05/17 12:37:33]

The --serialization-X are not meant to last but we something to start testing.
(That's why I put them under 'experimental options' and did not document them in
the help text in 'dart2js.dart')

Regarding the actual (user-facing) command line options we still need to figure
out good strategies for sharding (dart:* in one file, each package in its one,
etc.), ability to autoload data (deploying the sdk with data for dart:*, loading
data if present (and up-to-date) and otherwise use .dart files (maybe autosave
as well).

[Siggi Cherem (dart-lang), 2016/05/17 21:54:25]

I understand, I was also thinking we'd keep the new flags in experimental. It
might still be worth using flags closer to how we imagine them to be in the
future, though. For example, how about this combination:
  - Use `--resolve-only` to enable serialization (this will be an experimental
flag added here)
  - Remove `--serialization-target` and use `--out` (with a default)
  - keep the `--serialization-source` extra flag, maybe rename to
`--resolution-input` to match the other flag name. 
Agree, all good questions. My thinking on this:
 - re sharding: I'm inclined to be explicit about it on the command line, for
example: specify which files should go into the same output. For example:

  dart2js --resolve-only --resolution-input=a.z --out=o.z b.dart c.dart

will include B and C in the output o.z file.

 - re file is present/not-present: I'm inclined to keep it simple, if it is not
in the input list and it is not loaded in an existing serialized chunk, then we
issue an error. In other words: 

   In the example above if b.dart imports c.dart and a.dart, then this fails
because c is not found (the file should've been given as an input like the
example above)

    dart2js --resolve-only --resolution-input=a.z --out=o.z b.dart

  this also fails, because a's resolution input is missing:
    dart2js --resolve-only --out=o.z b.dart c.dart

+  static const String serializationSource = '--serialization-source=.+';
+  static const String serializationTarget = '--serialization-target=.+';
 }