js: fix core.Object, output order, static const fields

js: fix core.Object, output order, static const fields

These are a few fixes trying to get the compiled SDK to load

R=vsm@google.com

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

[Jennifer Messerly, 2015-03-17 15:51:19]

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

[Jennifer Messerly, 2015-03-17 15:51:54]

Patchset #1 (id:1) has been deleted

[vsm, 2015-03-17 18:27:32]

lgtm

https://codereview.chromium.org/1011153002/diff/10001/lib/src/codegen/js_code...
File lib/src/codegen/js_codegen.dart (right):

https://codereview.chromium.org/1011153002/diff/10001/lib/src/codegen/js_code...
lib/src/codegen/js_codegen.dart:69: // in the main library's compilation unit.
Is there a way to assert that the first is a library and the rest are parts? 
Maybe a TODO.

[Jennifer Messerly, 2015-03-17 18:58:45]

thanks Vijay! Please take another look

https://codereview.chromium.org/1011153002/diff/10001/lib/src/codegen/js_code...
File lib/src/codegen/js_codegen.dart (right):

https://codereview.chromium.org/1011153002/diff/10001/lib/src/codegen/js_code...
lib/src/codegen/js_codegen.dart:69: // in the main library's compilation unit.
On 2015/03/17 18:27:32, vsm wrote:
> Is there a way to assert that the first is a library and the rest are parts? 
> Maybe a TODO.

Done. Introduced "LibraryUnit" type to assert the structure we expect. It turns
out dart_codegen was using a similar workaround in its generateLibrary, so that
got cleaned up a bit too.

https://codereview.chromium.org/1011153002/diff/20001/lib/src/info.dart
File lib/src/info.dart (right):

https://codereview.chromium.org/1011153002/diff/20001/lib/src/info.dart#newco...
lib/src/info.dart:56: Iterable<CompilationUnit> get units sync* {
=D

[Jennifer Messerly, 2015-03-17 19:03:05]

https://codereview.chromium.org/1011153002/diff/20001/lib/src/info.dart
File lib/src/info.dart (right):

https://codereview.chromium.org/1011153002/diff/20001/lib/src/info.dart#newco...
lib/src/info.dart:57: yield library;
on second thought... we could just reverse the order here. In other words, maybe
we should just put "parts" first in the list, and always visit that way, in
codegen and checker. WDYT?

Maybe `libraryThenParts` and `partsThenLibrary` getters? to make the distinction
obvious. that would further simplify both codegens

[Jennifer Messerly, 2015-03-17 19:11:52]

https://codereview.chromium.org/1011153002/diff/20001/lib/src/info.dart
File lib/src/info.dart (right):

https://codereview.chromium.org/1011153002/diff/20001/lib/src/info.dart#newco...
lib/src/info.dart:57: yield library;
On 2015/03/17 19:03:05, John Messerly wrote:
> on second thought... we could just reverse the order here. In other words,
maybe
> we should just put "parts" first in the list, and always visit that way, in
> codegen and checker. WDYT?
> 
> Maybe `libraryThenParts` and `partsThenLibrary` getters? to make the
distinction
> obvious. that would further simplify both codegens

I went ahead and made both orders possible.
Kept around LibraryUnit, as it's sometimes useful to go straight to the
library's unit.

[vsm, 2015-03-17 19:25:58]

lgtm

[Jennifer Messerly, 2015-03-17 20:11:38]

Committed patchset #3 (id:30001) manually as
b6d4a590e1bb7edca10dd4dce28157e134e0fe10 (presubmit successful).