Work in progress: front end hot reload API

Initial implementation of front_end hot reload API.

This implementation is based on the existing kernel and analysis
driver logic, using proxy classes to account for interface
incompatibilities between those components.  In future CLs, I
hope we can (a) move the necessary analysis driver logic into
front_end, and (b) reduce or eliminate the number of proxy
classes needed.

This CL represents the very first inklings of functionality; all that
is confirmed to work at this point is compilation of a single source
file containing an empty `main` method.

R=danrubel@google.com, scheglov@google.com

Committed: https://github.com/dart-lang/sdk/commit/05a417034ad69d77dc0ee606a6aa0268b100757c

[Paul Berry, 2017-01-11 17:24:15]

Not ready to review yet.  Just publishing so that we can discuss.

[Paul Berry, 2017-01-15 22:44:57]

Description was changed from

==========
Work in progress: front end hot reload API
==========

to

==========
Initial implementation of front_end hot reload API.

This implementation is based on the existing kernel and analysis
driver logic, using proxy classes to account for interface
incompatibilities between those components.  In future CLs, I
hope we can (a) move the necessary analysis driver logic into
front_end, and (b) reduce or eliminate the number of proxy
classes needed.

This CL represents the very first inklings of functionality; all that
is confirmed to work at this point is compilation of a single source
file containing an empty `main` method.
==========

[Paul Berry, 2017-01-15 22:47:02]

paulberry@google.com changed reviewers:
+ danrubel@google.com, scheglov@google.com

[scheglov, 2017-01-16 19:24:58]

lgtm

https://codereview.chromium.org/2624193003/diff/20001/pkg/front_end/lib/incre...
File pkg/front_end/lib/incremental_kernel_generator.dart (right):

https://codereview.chromium.org/2624193003/diff/20001/pkg/front_end/lib/incre...
pkg/front_end/lib/incremental_kernel_generator.dart:21: final Map<Uri, Program>
newState;
Program?
I don't know about Kernel much, but if Program the program is a collection of
libraries, then what is the Uri of an entry in the map?

https://codereview.chromium.org/2624193003/diff/20001/pkg/front_end/lib/incre...
File pkg/front_end/lib/incremental_resolved_ast_generator.dart (right):

https://codereview.chromium.org/2624193003/diff/20001/pkg/front_end/lib/incre...
pkg/front_end/lib/incremental_resolved_ast_generator.dart:17: /// The new state
of the program, as a map from Uri to resolved AST.
"to resolved library"?

[danrubel, 2017-01-17 01:41:56]

LGTM.

[Paul Berry, 2017-01-17 13:45:31]

https://codereview.chromium.org/2624193003/diff/20001/pkg/front_end/lib/incre...
File pkg/front_end/lib/incremental_kernel_generator.dart (right):

https://codereview.chromium.org/2624193003/diff/20001/pkg/front_end/lib/incre...
pkg/front_end/lib/incremental_kernel_generator.dart:21: final Map<Uri, Program>
newState;
On 2017/01/16 19:24:58, scheglov wrote:
> Program?
> I don't know about Kernel much, but if Program the program is a collection of
> libraries, then what is the Uri of an entry in the map?

It's a little confusing because we are taking advantage of kernel's modular
compilation features.  The way we're using it, each Program will contain the
complete code for one library, plus just a skeletal representation of all the
libraries that are referenced (kind of like a summary of those libraries, except
smaller, since it only contains things that are referenced).  So the Uri of an
entry in the map tells which library is fully represented in the corresponding
Program object.

https://codereview.chromium.org/2624193003/diff/20001/pkg/front_end/lib/incre...
File pkg/front_end/lib/incremental_resolved_ast_generator.dart (right):

https://codereview.chromium.org/2624193003/diff/20001/pkg/front_end/lib/incre...
pkg/front_end/lib/incremental_resolved_ast_generator.dart:17: /// The new state
of the program, as a map from Uri to resolved AST.
On 2017/01/16 19:24:58, scheglov wrote:
> "to resolved library"?

Done.

[Paul Berry, 2017-01-17 14:10:11]

Description was changed from

==========
Initial implementation of front_end hot reload API.

This implementation is based on the existing kernel and analysis
driver logic, using proxy classes to account for interface
incompatibilities between those components.  In future CLs, I
hope we can (a) move the necessary analysis driver logic into
front_end, and (b) reduce or eliminate the number of proxy
classes needed.

This CL represents the very first inklings of functionality; all that
is confirmed to work at this point is compilation of a single source
file containing an empty `main` method.
==========

to

==========
Initial implementation of front_end hot reload API.

This implementation is based on the existing kernel and analysis
driver logic, using proxy classes to account for interface
incompatibilities between those components.  In future CLs, I
hope we can (a) move the necessary analysis driver logic into
front_end, and (b) reduce or eliminate the number of proxy
classes needed.

This CL represents the very first inklings of functionality; all that
is confirmed to work at this point is compilation of a single source
file containing an empty `main` method.

R=danrubel@google.com, scheglov@google.com

Committed:
https://github.com/dart-lang/sdk/commit/05a417034ad69d77dc0ee606a6aa0268b100757c
==========

[Paul Berry, 2017-01-17 14:10:12]

Committed patchset #2 (id:20001) manually as
05a417034ad69d77dc0ee606a6aa0268b100757c (presubmit successful).