fixes #219, able to compile multiple entry points

fixes #219, able to compile multiple entry points
also speeds up codegen_test by reusing the analysis context
BatchCompiler is pretty close to how analyzer_cli works now (other than missing features)

R=vsm@google.com

Committed: https://github.com/dart-lang/dev_compiler/commit/e260ddaa284a9b6ac054a14696895accf050882d

[Jennifer Messerly, 2015-07-15 21:37:18]

Patchset #1 (id:1) has been deleted

[Jennifer Messerly, 2015-07-15 21:41:38]

jmesserly@google.com changed reviewers:
+ vsm@google.com

[Jennifer Messerly, 2015-07-15 21:41:39]

Essentially introduces a new BatchCompiler API, splitting it off the
server/dependency graph code. The idea is to have something that is structurally
similar to how analyzer_cli works.

Also, tool/test.sh now runs in 11s. Before was 73s. But crucially we can scale
this up by adding more tests that need to be compiled. Each one adds a minuscule
amount of time, instead of seconds.

[Jennifer Messerly, 2015-07-15 21:44:18]

On 2015/07/15 21:41:39, John Messerly wrote:
> Essentially introduces a new BatchCompiler API, splitting it off the
> server/dependency graph code. The idea is to have something that is
structurally
> similar to how analyzer_cli works.
> 
> Also, tool/test.sh now runs in 11s. Before was 73s. But crucially we can scale
> this up by adding more tests that need to be compiled. Each one adds a
minuscule
> amount of time, instead of seconds.

also this unblocks another round of *Options cleanup, but I didn't do that yet,
because we might be able to remove a lot of them soon...

[Jennifer Messerly, 2015-07-15 21:45:15]

https://codereview.chromium.org/1235503010/diff/20001/test/codegen/expect/exp...
File test/codegen/expect/expect.js (right):

https://codereview.chromium.org/1235503010/diff/20001/test/codegen/expect/exp...
test/codegen/expect/expect.js:69: let stringDifference =
Expect._stringDifference(dart.as(dart.as(dart.as(expected, core.String),
core.String), core.String), dart.as(dart.as(dart.as(actual, core.String),
core.String), core.String));
Eeeeep. We appear to be mutating the AST. Investigating...

[Jennifer Messerly, 2015-07-15 22:31:35]

Added a workaround for that issue.

https://codereview.chromium.org/1235503010/diff/20001/test/codegen/expect/exp...
File test/codegen/expect/expect.js (right):

https://codereview.chromium.org/1235503010/diff/20001/test/codegen/expect/exp...
test/codegen/expect/expect.js:69: let stringDifference =
Expect._stringDifference(dart.as(dart.as(dart.as(expected, core.String),
core.String), core.String), dart.as(dart.as(dart.as(actual, core.String),
core.String), core.String));
On 2015/07/15 21:45:15, John Messerly wrote:
> Eeeeep. We appear to be mutating the AST. Investigating...

aha, so this is the problem we knew we were going to hit if we reuse the same
analysis context, CoercionReifier mutates the AST. We're generating expect.dart
twice because codegen_test fires up two BatchCompilers on the same analysis
context.

this is super tricky to actually fix =| ... AstCloner doesn't work because we
lose attachment to the element model. I'm probably going to put in a hack for
the short term, since the bug already existed.

[vsm, 2015-07-16 13:58:16]

https://codereview.chromium.org/1235503010/diff/40001/lib/src/analysis_contex...
File lib/src/analysis_context.dart (right):

https://codereview.chromium.org/1235503010/diff/40001/lib/src/analysis_contex...
lib/src/analysis_context.dart:41: if (context.libraryResolverFactory is!
LibraryResolverWithInference) {
Will this ever fail?  It's checking if a factory is actually a resolver.

https://codereview.chromium.org/1235503010/diff/40001/lib/src/compiler.dart
File lib/src/compiler.dart (right):

https://codereview.chromium.org/1235503010/diff/40001/lib/src/compiler.dart#n...
lib/src/compiler.dart:134: // once on the same unit.
How do we end up with the same unit more than once here?

[Jennifer Messerly, 2015-07-16 16:36:19]

https://codereview.chromium.org/1235503010/diff/40001/lib/src/analysis_contex...
File lib/src/analysis_context.dart (right):

https://codereview.chromium.org/1235503010/diff/40001/lib/src/analysis_contex...
lib/src/analysis_context.dart:41: if (context.libraryResolverFactory is!
LibraryResolverWithInference) {
On 2015/07/16 13:58:16, vsm wrote:
> Will this ever fail?  It's checking if a factory is actually a resolver.

doh! good catch :)

https://codereview.chromium.org/1235503010/diff/40001/lib/src/compiler.dart
File lib/src/compiler.dart (right):

https://codereview.chromium.org/1235503010/diff/40001/lib/src/compiler.dart#n...
lib/src/compiler.dart:134: // once on the same unit.
On 2015/07/16 13:58:16, vsm wrote:
> How do we end up with the same unit more than once here?

explained in my initial CL comments:
https://codereview.chromium.org/1235503010/diff/20001/test/codegen/expect/exp...

it happens because codegen_test reuses the same AnalysisContext, but with
different BatchCompiler instances (so it loses the _compiled map). The issue is
that JSGenerator mutates the AST, thus polluting AnalysisContext's cache.

[Jennifer Messerly, 2015-07-16 22:03:52]

I'm also going to look at analysis message order, it seems to come back somewhat
randomly (hash table somewhere?). IIRC, analyzer_cli sorts them by position
first.

[vsm, 2015-07-16 23:56:40]

lgtm!

https://codereview.chromium.org/1235503010/diff/60001/lib/src/compiler.dart
File lib/src/compiler.dart (right):

https://codereview.chromium.org/1235503010/diff/60001/lib/src/compiler.dart#n...
lib/src/compiler.dart:268: // TODO(jmesserly): do we need an option for this?
Might be nice at some point, but easy enough to add later.

https://codereview.chromium.org/1235503010/diff/60001/lib/src/compiler.dart#n...
lib/src/compiler.dart:308: /// * package:qux/qux.dart -> qux/qux
at some point, we might want to prefix the packages to avoid potential conflicts
with non-package files.

https://codereview.chromium.org/1235503010/diff/60001/lib/src/summary.dart
File lib/src/summary.dart (left):

https://codereview.chromium.org/1235503010/diff/60001/lib/src/summary.dart#ol...
lib/src/summary.dart:107: _lines = lines == null ? lines : 0;
oops!

[Jennifer Messerly, 2015-07-17 00:41:38]

Committed patchset #3 (id:60001) manually as
e260ddaa284a9b6ac054a14696895accf050882d (presubmit successful).