Add the ability to spawn an isolate in Dart 2 preview mode

[nex3]

Pub users want to be able to run their executables via pub run using Dart 2 preview mode (see dart-lang/pub#1807 and flutter/flutter#14728 (comment)). Because pub run runs executables in isolates, this means it'll need to be able to spawn an isolate that uses Dart 2 preview mode.

I suggest adding a bool previewDart2 flag to Isolate.spawnUri() that will become a deprecated no-op once Dart 2 releases.

[lrhn]

I'd much rather have the Dart version embedded in the dill file that the VM uses to spawn the isolate.
I see no advantage in supporting running actual Dart 2 code from source since that will not work anyway (the VM doesn't do type inference, and Dart 2 without type inference doesn't really work).

Alternatively, make pub itself run with the flag set. Perhaps make the pub script accept the --preview-dart2 flag and run itself on a VM with that flag. The pub code should still work, and anything it spawns will inherit the flag. I assume that there would need to be a flag on pub run anyway..

[vsmenon]

@kevmoo @devoncarew How important is this for general travis testing with Dart 2?

Some options:

1. Add the isolate support as requested. Not sure it's actually possible for the VM to have some isolates on the CFE and some not (@a-siva ).

2. Get pub itself running on Dart 2 as Lasse suggested. Not clear how much work it'll be to run it and its dependences on Dart 2. We haven't gotten most of our own tools running in 2 yet.

3. Rework pub to not use isolate (and, e.g., start a new Dart process instead). @nex3 - is that feasible?

[nex3]

I'd much rather have the Dart version embedded in the dill file that the VM uses to spawn the isolate.
I see no advantage in supporting running actual Dart 2 code from source since that will not work anyway (the VM doesn't do type inference, and Dart 2 without type inference doesn't really work).

Hold on a sec--if we don't plan to support running Dart 2 code from source, that's news to me. It also has major implications for all sorts of tooling. My understanding was that the VM would embed the common front end to do the initial type checking. Isn't that how --preview-dart-2 works today?

Alternatively, make pub itself run with the flag set. Perhaps make the pub script accept the --preview-dart2 flag and run itself on a VM with that flag. The pub code should still work, and anything it spawns will inherit the flag. I assume that there would need to be a flag on pub run anyway..

#32188 is tracking this, but there are a lot of complexities involved. In addition to getting the transitive closure of pub (which includes the analyzer and dart2js) Dart-2-clean, we'd need to build both Dart 1 and Dart 2 snapshots of pub, bundle them with the SDK, and have pub's wrapper scripts parse arguments to figure out which one to invoke. It's not impossible, but it would be a lot of work.

Rework pub to not use isolate (and, e.g., start a new Dart process instead). @nex3 - is that feasible?

We used to do this, and it caused all kinds of problems around performance, signal-handling, and standard IO piping. I don't want to regress that behavior, and I'm not keen on adding an alternate code path that has more behavioral differences than just the Dart 2 semantics.

[a-siva]

@nex3 - The VM supports running Dart 2 code from source we don't plan on getting rid of that.

@vsmenon - about the ability for the VM to run some isolates in strong mode and others not - we don't currently have support for this when running from source but it should be possible to do this (currently we start the CFE isolate eagerly under the --preview-dart-2 flag but if we made that lazy then this should be possible).

[a-siva]

@rmacnak-google (see offline email about a possible way to get this working quickly)

[tvolkert]

re: #32253 (comment)

@kevmoo @devoncarew How important is this for general travis testing with Dart 2?

IMO, very important. I just rolled a new version of package:redux into Google and discovered that it didn't work in some cases under Dart 2, but there was no way to write tests that showed the failure and have those failures surface in their Travis setup.

If we're asking our ecosystem to try to be fully Dart-2 compliant by I/O, we need to give them the tools to do so...

/cc @eseidelGoogle

(I found my way here from dart-lang/pub#1807)

[tvolkert]

Discussing with @a-siva it sounds like the right solution to this is just to make pub Dart 2 compliant, which would obviate the need for this feature request to be resolved -- because the main pub isolate could be started in Dart 2.

[kevmoo]

the right solution to this is just to make pub Dart 2 compliant

Landing dart-lang/pub#1857 first will make this a lot easier, since the surface area of pub will be reduced substantially. ETA – next few days.

[eseidelGoogle]

Please confirm my understanding:

1. It is not currently possible to use/run a package:test test which use dart2 (or tests for dart2 specific issues), correct?
2. It is possible to use/run a flutter test test in dart 2 (that's the only way) due to flutter_test's different test backend.