Generate all runtime files from dart.

Generate _runtime.js from dart (https://github.com/dart-lang/dev_compiler/issues/310)

The following part files were ported from the original .js (lib/runtime/dart/_foo.js -> input_sdk/private/foo.dart):
- input_sdk/private/rtti.dart
- input_sdk/private/types.dart
- input_sdk/private/classes.dart
- input_sdk/private/errors.dart
- input_sdk/private/generators.dart
- input_sdk/private/operations.dart
- input_sdk/private/runtime.dart

Notes:
- Introduced genericTypeConstructor intrinsic: `JS('', '#(type)', genericTypeConstructor(List))` generates `core.List$(type)`
- Used new JS quasiquotes everywhere
- Depends on new internal `@JSExportName` annotation to alias symbols like dart.{as, is, const, assert, export, implements, throw, async, dynamic, void} (see https://codereview.chromium.org/1580413002/)

BUG=
R=jmesserly@google.com

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

[ochafik, 2015-12-15 05:32:26]

Description was changed from

==========
Generate all runtime files from dart.

- Used regexps to stub the js->dart conversion:
  https://gist.github.com/ochafik/099900f4cb9bb17016ae

- Introduced genericTypeConstructor helper to get Foo$ from
genericTypeConstructor(Foo) (with qualifications)
- Reintroduced a JsName to choose target js name (decl + resolution)


BUG=
==========

to

==========
Generate all runtime files from dart.

- Introduced genericTypeConstructor helper to get Foo$ from
genericTypeConstructor(Foo) (with qualifications)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure there's no disturbance of the
Force
- Reintroduced a JsName to alias functions like
dart.{as_,is_,const_,asset_,export_,...}
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826
- Note: diff would be easier to read after
https://codereview.chromium.org/1524843002


BUG=
==========

[ochafik, 2015-12-15 05:36:44]

Description was changed from

==========
Generate all runtime files from dart.

- Introduced genericTypeConstructor helper to get Foo$ from
genericTypeConstructor(Foo) (with qualifications)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure there's no disturbance of the
Force
- Reintroduced a JsName to alias functions like
dart.{as_,is_,const_,asset_,export_,...}
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826
- Note: diff would be easier to read after
https://codereview.chromium.org/1524843002


BUG=
==========

to

==========
Generate all runtime files from dart.

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias functions like
dart.{as_,is_,const_,asset_,export_}
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826
- Note: diff would be easier to read after
https://codereview.chromium.org/1524843002


BUG=
==========

[ochafik, 2015-12-15 05:38:49]

ochafik@google.com changed reviewers:
+ jmesserly@google.com, leafp@google.com, vsm@google.com

[ochafik, 2015-12-15 05:38:50]

Hey guys, I've finally managed to get a green Karma with runtime fully generated
from dart files... Sorry for the diff length & relative abundance of hacks,
enjoy!

[ochafik, 2015-12-15 05:40:39]

Description was changed from

==========
Generate all runtime files from dart.

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias functions like
dart.{as_,is_,const_,asset_,export_}
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826
- Note: diff would be easier to read after
https://codereview.chromium.org/1524843002


BUG=
==========

to

==========
Generate all runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias functions like
dart.{as_,is_,const_,asset_,export_}
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826
- Note: diff would be easier to read after
https://codereview.chromium.org/1524843002


BUG=
==========

[ochafik, 2015-12-15 05:49:37]

Description was changed from

==========
Generate all runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias functions like
dart.{as_,is_,const_,asset_,export_}
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826
- Note: diff would be easier to read after
https://codereview.chromium.org/1524843002


BUG=
==========

to

==========
Generate all runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias symbols like dart.{as, is, const,
asset, export, implements, throw, async, dynamic, void} (both when declaring
them and when re-exporting them)
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826
- Note: diff would be easier to read after
https://codereview.chromium.org/1524843002


BUG=
==========

[ochafik, 2015-12-15 05:50:02]

Description was changed from

==========
Generate all runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias symbols like dart.{as, is, const,
asset, export, implements, throw, async, dynamic, void} (both when declaring
them and when re-exporting them)
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826
- Note: diff would be easier to read after
https://codereview.chromium.org/1524843002


BUG=
==========

to

==========
Generate all runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias symbols like dart.{as, is, const,
assert, export, implements, throw, async, dynamic, void} (both when declaring
them and when re-exporting them)
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826
- Note: diff would be easier to read after
https://codereview.chromium.org/1524843002


BUG=
==========

[ochafik, 2015-12-16 19:56:08]

Description was changed from

==========
Generate all runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias symbols like dart.{as, is, const,
assert, export, implements, throw, async, dynamic, void} (both when declaring
them and when re-exporting them)
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826
- Note: diff would be easier to read after
https://codereview.chromium.org/1524843002


BUG=
==========

to

==========
Generate all runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias symbols like dart.{as, is, const,
assert, export, implements, throw, async, dynamic, void} (both when declaring
them and when re-exporting them)
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826


BUG=
==========

[ochafik, 2015-12-16 20:00:37]

Regenerated with 1-line ifs, the diff should be easier to review now (best =
side-by-side diff + focus on right side).

[ochafik, 2015-12-18 11:50:03]

ochafik@google.com changed reviewers:
+ devoncarew@google.com

[ochafik, 2015-12-18 15:19:35]

Description was changed from

==========
Generate all runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS string interpolation everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias symbols like dart.{as, is, const,
assert, export, implements, throw, async, dynamic, void} (both when declaring
them and when re-exporting them)
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826


BUG=
==========

to

==========
Generate all runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS quasiquotes everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias symbols like dart.{as, is, const,
assert, export, implements, throw, async, dynamic, void} (both when declaring
them and when re-exporting them)
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826


BUG=
==========

[ochafik, 2015-12-18 16:02:17]

Note: added a phony intermediate patchset to see a diff between the original .js
and the converted .dart, for instance:

https://codereview.chromium.org/1530563003/diff2/170001:190001/tool/input_sdk...

[ochafik, 2015-12-18 16:04:14]

Description was changed from

==========
Generate all runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS quasiquotes everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias symbols like dart.{as, is, const,
assert, export, implements, throw, async, dynamic, void} (both when declaring
them and when re-exporting them)
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826


BUG=
==========

to

==========
Generate the following runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310):
- input_sdk/private/rtti.dart -> lib/runtime/dart/_rtti.js
- input_sdk/private/types.dart -> lib/runtime/dart/_types.js
- input_sdk/private/classes.dart -> lib/runtime/dart/_classes.js
- input_sdk/private/errors.dart -> lib/runtime/dart/_errors.js
- input_sdk/private/generators.dart -> lib/runtime/dart/_generators.js
- input_sdk/private/operations.dart -> lib/runtime/dart/_operations.js
- input_sdk/private/runtime.dart -> lib/runtime/dart/_runtime.js

Notes:
- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS quasiquotes everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias symbols like dart.{as, is, const,
assert, export, implements, throw, async, dynamic, void} (both when declaring
them and when re-exporting them)
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826


BUG=
==========

[Jennifer Messerly, 2016-01-07 20:18:05]

I looked at the js_codegen changes. Below are some comments. 

The meta-comment: it's usually better to change the private SDK input libraries,
rather than adding meta-programming code to the compiler. Compilers are already
complex beasts, so any complexity that can be pushed out of them is almost
certainly a net win.

The new JS interop feature around customizing top-level names (for
classes/properties/functions?) looks nice, but would be easier to review if it
was split out into its own CL with tests.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
File lib/src/codegen/js_codegen.dart (right):

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:133: static final _runtimeLibUris = new
Set<String>.from([
ideally we wouldn't need to hard code these, or generate code differently when
we are compiling these. If possible, I'd prefer to express the relevant
differences in the library files themselves. (Perhaps an annotation if needed.)

Otherwise when I look at the SDK source, I have to know which libraries will be
treated differently.

(Even a naming convention would be better than a hard coded list)

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:228: addImport('dart/_runtime', _runtimeLibVar);
can we just import this library explicitly?

    // in the input .dart file
    library dart._rtti;
    import 'dart:_runtime';

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:235: addImport('dart/_classes', _classesLibVar);
same here, can we import this explicitly?

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:244: if (otherLibUri == 'dart:_utils') return
true;
can we just add these cases to the existing corelibOrder list? Its job is to
enforce an import order for core libraries.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:246: // recognized by the loader: we help it out
here.
can you explain the problem with this? I'm not following what is going on.

We can try and fix how rtti.LazyTagged works. We could throw all of our helpers
in one file if that was the blocker.

I get nervous when we have special logic for compiling certain libraries, it
means constraints from the input sources are leaking into the compiler, adding
compiler complexity and meaning we can hit bugs because things are not handled
uniformly.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:304: String _getJsName(Element e) {
I'm a little confused about this function. It could use a doc comment & more
clear name. Is it supposed to only accept LibraryElements? What does it do in
other cases, and under what conditions does it need to be called?

Mapping Dart names to JS names needs to be done *super* carefully given the join
goals of interop guarantees and generating valid JavaScript. Feels a bit like
walking a tightrope.

I think this is trying to support renaming of more kinds of top-level elements,
but it's not entirely clear which ones. If we need a new JS interop feature it
might be better to do as separate CL and also R=jacobr@google.com, since we will
want to ensure every place that can generate a reference to that name is
checking for the JsName.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:338: throw new StateError('Cannot set js name on
more than one export');
Can this error be triggered by user code?

If so, we should definitely not throw! Compiler should never throw unless it has
a bug. If this is an error or warning we must report it to the user, with enough
information that they can fix it.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:633: js.call('#.generic', [_isDartRuntime ?
_classesLibVar : _runtimeLibVar]);
I made this comment elsewhere, but I don't think we should switch on
`_isDartRuntime`.

Maybe it's worth a longer design discussion, but...

The way the libs were structured:

we had things like _rtti, _classes. They can import eachother, but they never
import dart:* SDK libs. They depend on loader.

dart:_runtime re-exports all of them.

All other Dart code we compiled implicitly depended on dart:_runtime.

That's a problem now that we're trying to compile _rtti, _classes, etc. How do
we bootstrap?

One answer here is we shouldn't keep separate libraries. That was just how we
structured the JavaScript. We could use "part" in Dart, and merge these all into
dart:_runtime. That would simplify a lot of code I suspect.

Another answer is keep them in separate libraries, but instead always refer to
those libraries.

We chatted a bit about this here and were leaning towards the "part" approach --
seems like it might really simplify the bootstrapping of dart_runtime.js

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:1406: // Note: this allows silently passing args
through to the body, which only
I don't think you need the "Note" anymore?

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:1624: var name = _getJsName(element) ??
element.name;
This is related to my other comment on _getJsName, but ... could we fold this
check into _maybeQualifiedName?

And maybe rename that function, _emitTopLevelName perhaps. (_maybeQualifiedName
is not a great name.)

I don't think we want to rename things in the other code paths. And that would
also cover _emitTypeName, which otherwise we would miss.

Generally speaking when we generate JS code for Dart code, the Dart names fall
into a few different categories:
* parameters and local variables: these can be freely renamed by the compiler
* class members, hence _emitMemberName
* top level names, which go through _maybeQualifiedName
* classes are special enough that they use _emitTypeName (which delegates to
_maybeQualifiedName)

Libraries (ES modules) also have names but those aren't relied on. For modules
their URL (the string path fragment) determines their identity. The name we
import that library as is just a temp that can be renamed.

(We also generate some JS names that are presumed to be from the JS global
scope, like "dart." and "dartx." -- but those didn't come from Dart Elements. At
least not prior to this CL)

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:1943: JS.Expression
_emitGenericTypeConstructor(Expression typeExpression) {
I don't understand why this is needed. Given a type name, _emitTypeName will
emit it.

This may be related to my earlier comment about the _getJsName in
visitSimpleIdentifier path.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:1963: return
_emitGenericTypeConstructor(node.argumentList.arguments.single);
I don't understand why this case is needed. It seems totally broken to take a
method call, and generate only the first argument ...

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:3499: if (name == 'dart._utils') return
_utilsLibVar;
I don't think these special cases could be needed.

You could just ask for the _libraryName(_classesLib) where _classesLib is the
LibaryElement for dart:_classes.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:3500: else if (name == 'dart._classes') return
_classesLibVar;
also, relying on the library name is super risky. Anyone could impersonate it.
Only the URI is reliable way to determine if something is from the SDK.

[ochafik, 2016-01-13 13:12:37]

Description was changed from

==========
Generate the following runtime files from dart
(https://github.com/dart-lang/dev_compiler/issues/310):
- input_sdk/private/rtti.dart -> lib/runtime/dart/_rtti.js
- input_sdk/private/types.dart -> lib/runtime/dart/_types.js
- input_sdk/private/classes.dart -> lib/runtime/dart/_classes.js
- input_sdk/private/errors.dart -> lib/runtime/dart/_errors.js
- input_sdk/private/generators.dart -> lib/runtime/dart/_generators.js
- input_sdk/private/operations.dart -> lib/runtime/dart/_operations.js
- input_sdk/private/runtime.dart -> lib/runtime/dart/_runtime.js

Notes:
- Runtime files directly source their {fn,export,generic,setSignature} helpers
from rtti, utils or classes (avoids cycles). Other libs use the version
reexported by dart.
- Introduced genericTypeConstructor helper to get ahold of Foo$ with
`genericTypeConstructor(Foo)` (deals with (maybe)qualified paths)
- Using new JS quasiquotes everywhere
- Special-cased imports of runtime files to ensure no cycles creep in
- Reintroduced a JsName annotation to alias symbols like dart.{as, is, const,
assert, export, implements, throw, async, dynamic, void} (both when declaring
them and when re-exporting them)
- Tests are green here:
https://travis-ci.org/dart-lang/dev_compiler/builds/96909826


BUG=
==========

to

==========
Generate _runtime.js from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

The following part files were ported from the original .js
(lib/runtime/dart/_foo.js -> input_sdk/private/foo.dart):
- input_sdk/private/rtti.dart
- input_sdk/private/types.dart
- input_sdk/private/classes.dart
- input_sdk/private/errors.dart
- input_sdk/private/generators.dart
- input_sdk/private/operations.dart
- input_sdk/private/runtime.dart

Notes:
- Introduced genericTypeConstructor intrinsic: `JS('', '#(type)',
genericTypeConstructor(List))` generates `core.List$(type)`
- Used new JS quasiquotes everywhere
- Depends on new internal `@JSExportName` annotation to alias symbols like
dart.{as, is, const, assert, export, implements, throw, async, dynamic, void}
(see https://codereview.chromium.org/1580413002/)

BUG=
==========

[ochafik, 2016-01-13 13:13:21]

Thanks John!

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
File lib/src/codegen/js_codegen.dart (right):

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:133: static final _runtimeLibUris = new
Set<String>.from([
On 2016/01/07 20:18:04, John Messerly wrote:
> ideally we wouldn't need to hard code these, or generate code differently when
> we are compiling these. If possible, I'd prefer to express the relevant
> differences in the library files themselves. (Perhaps an annotation if
needed.)
> 
> Otherwise when I look at the SDK source, I have to know which libraries will
be
> treated differently.
> 
> (Even a naming convention would be better than a hard coded list)

Dropped this but kept _isDartRuntime (testing on dart:_runtime only) to decide
on function tagging + module decl.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:228: addImport('dart/_runtime', _runtimeLibVar);
On 2016/01/07 20:18:04, John Messerly wrote:
> can we just import this library explicitly?
> 
>     // in the input .dart file
>     library dart._rtti;
>     import 'dart:_runtime';

That's mainly for the "mere mortal" files

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:235: addImport('dart/_classes', _classesLibVar);
On 2016/01/07 20:18:04, John Messerly wrote:
> same here, can we import this explicitly?

Dropped now that all runtime is in dart:_runtime

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:244: if (otherLibUri == 'dart:_utils') return
true;
On 2016/01/07 20:18:05, John Messerly wrote:
> can we just add these cases to the existing corelibOrder list? Its job is to
> enforce an import order for core libraries.

Ack

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:246: // recognized by the loader: we help it out
here.
On 2016/01/07 20:18:04, John Messerly wrote:
> can you explain the problem with this? I'm not following what is going on.
> 
> We can try and fix how rtti.LazyTagged works. We could throw all of our
helpers
> in one file if that was the blocker.
> 
> I get nervous when we have special logic for compiling certain libraries, it
> means constraints from the input sources are leaking into the compiler, adding
> compiler complexity and meaning we can hit bugs because things are not handled
> uniformly.

Dropped special logic

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:304: String _getJsName(Element e) {
On 2016/01/07 20:18:04, John Messerly wrote:
> I'm a little confused about this function. It could use a doc comment & more
> clear name. Is it supposed to only accept LibraryElements? What does it do in
> other cases, and under what conditions does it need to be called?
> 
> Mapping Dart names to JS names needs to be done *super* carefully given the
join
> goals of interop guarantees and generating valid JavaScript. Feels a bit like
> walking a tightrope.
> 
> I think this is trying to support renaming of more kinds of top-level
elements,
> but it's not entirely clear which ones. If we need a new JS interop feature it
> might be better to do as separate CL and also mailto:R=jacobr@google.com,
since we will
> want to ensure every place that can generate a reference to that name is
> checking for the JsName.

Spun this out in https://codereview.chromium.org/1580413002/, with no change to
handling of package:js annotations.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:338: throw new StateError('Cannot set js name on
more than one export');
On 2016/01/07 20:18:04, John Messerly wrote:
> Can this error be triggered by user code?
> 
> If so, we should definitely not throw! Compiler should never throw unless it
has
> a bug. If this is an error or warning we must report it to the user, with
enough
> information that they can fix it. 
> 

Dropped that (no need to re-export anymore with the parts)

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:633: js.call('#.generic', [_isDartRuntime ?
_classesLibVar : _runtimeLibVar]);
On 2016/01/07 20:18:05, John Messerly wrote:
> I made this comment elsewhere, but I don't think we should switch on
> `_isDartRuntime`.
> 
> Maybe it's worth a longer design discussion, but...
> 
> The way the libs were structured:
> 
> we had things like _rtti, _classes. They can import eachother, but they never
> import dart:* SDK libs. They depend on loader.
> 
> dart:_runtime re-exports all of them.
> 
> All other Dart code we compiled implicitly depended on dart:_runtime.
> 
> That's a problem now that we're trying to compile _rtti, _classes, etc. How do
> we bootstrap?
> 
> One answer here is we shouldn't keep separate libraries. That was just how we
> structured the JavaScript. We could use "part" in Dart, and merge these all
into
> dart:_runtime. That would simplify a lot of code I suspect.
> 
> Another answer is keep them in separate libraries, but instead always refer to
> those libraries.
> 
> We chatted a bit about this here and were leaning towards the "part" approach
--
> seems like it might really simplify the bootstrapping of dart_runtime.js

Parts FTW!

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:1406: // Note: this allows silently passing args
through to the body, which only
On 2016/01/07 20:18:05, John Messerly wrote:
> I don't think you need the "Note" anymore?

Done.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:1624: var name = _getJsName(element) ??
element.name;
On 2016/01/07 20:18:04, John Messerly wrote:
> This is related to my other comment on _getJsName, but ... could we fold this
> check into _maybeQualifiedName?
> 
> And maybe rename that function, _emitTopLevelName perhaps.
(_maybeQualifiedName
> is not a great name.)
> 
> I don't think we want to rename things in the other code paths. And that would
> also cover _emitTypeName, which otherwise we would miss.
> 
> Generally speaking when we generate JS code for Dart code, the Dart names fall
> into a few different categories:
> * parameters and local variables: these can be freely renamed by the compiler
> * class members, hence _emitMemberName
> * top level names, which go through _maybeQualifiedName
> * classes are special enough that they use _emitTypeName (which delegates to
> _maybeQualifiedName)
> 
> Libraries (ES modules) also have names but those aren't relied on. For modules
> their URL (the string path fragment) determines their identity. The name we
> import that library as is just a temp that can be renamed.
> 
> (We also generate some JS names that are presumed to be from the JS global
> scope, like "dart." and "dartx." -- but those didn't come from Dart Elements.
At
> least not prior to this CL)

Moved the exported name resolution logic to down to _maybeQualifiedName (renamed
to _emitTopLevelName) in https://codereview.chromium.org/1580413002

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:1943: JS.Expression
_emitGenericTypeConstructor(Expression typeExpression) {
On 2016/01/07 20:18:04, John Messerly wrote:
> I don't understand why this is needed. Given a type name, _emitTypeName will
> emit it.
> 
> This may be related to my earlier comment about the _getJsName in
> visitSimpleIdentifier path.

This implements the new intrinsic used in the following places:
- generators.dart:
  - `const SyncIterable_E = ${genericTypeConstructor(SyncIterable)}($E);`
  - `return ${genericTypeConstructor(Future)}(T).new(function() {`
  - `this.controller = ${genericTypeConstructor(StreamController)}(T).new({`
- classes.dart:
  - `$setType($obj, ${genericTypeConstructor(JSArray)}($elementType))`

This intrinsic provides a reliable way to build generic types from JS
expressions in the runtime.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:1963: return
_emitGenericTypeConstructor(node.argumentList.arguments.single);
On 2016/01/07 20:18:04, John Messerly wrote:
> I don't understand why this case is needed. It seems totally broken to take a
> method call, and generate only the first argument ...

Sorry for the lacking doc, this is a new intrinsic that takes exacly 1 arg,
renamed predicate (+ added comments).

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:3499: if (name == 'dart._utils') return
_utilsLibVar;
On 2016/01/07 20:18:04, John Messerly wrote:
> I don't think these special cases could be needed.
> 
> You could just ask for the _libraryName(_classesLib) where _classesLib is the
> LibaryElement for dart:_classes.

Done.

https://codereview.chromium.org/1530563003/diff/190001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:3500: else if (name == 'dart._classes') return
_classesLibVar;
On 2016/01/07 20:18:04, John Messerly wrote:
> also, relying on the library name is super risky. Anyone could impersonate it.
> Only the URI is reliable way to determine if something is from the SDK.

Acknowledged.

[ochafik, 2016-01-20 01:11:46]

PTAL rebased after @JSExportName CL

[Jennifer Messerly, 2016-01-20 23:44:58]

sorry this took me so long to get to. LGTM!

https://codereview.chromium.org/1530563003/diff/390001/lib/src/codegen/js_cod...
File lib/src/codegen/js_codegen.dart (right):

https://codereview.chromium.org/1530563003/diff/390001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:1906: JS.Expression
_emitGenericTypeConstructor(Expression typeExpression) {
we chatted about moving this hack into the generated JS. either way I hope we
can fix the trailing $ sign soon

[ochafik, 2016-01-21 00:11:36]

Thanks a lot John!

https://codereview.chromium.org/1530563003/diff/390001/lib/src/codegen/js_cod...
File lib/src/codegen/js_codegen.dart (right):

https://codereview.chromium.org/1530563003/diff/390001/lib/src/codegen/js_cod...
lib/src/codegen/js_codegen.dart:1906: JS.Expression
_emitGenericTypeConstructor(Expression typeExpression) {
On 2016/01/20 23:44:58, John Messerly wrote:
> we chatted about moving this hack into the generated JS. either way I hope we
> can fix the trailing $ sign soon

So actually, JS('', '$Future\$($type)') is just JS('', r'#$(#)', Future, type)),
which conflicts with the mini js parser's syntax for named holes.

Using runtime getGenericClass instead of intrinsic genericTypeConstructor.

[ochafik, 2016-01-21 00:45:36]

Description was changed from

==========
Generate _runtime.js from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

The following part files were ported from the original .js
(lib/runtime/dart/_foo.js -> input_sdk/private/foo.dart):
- input_sdk/private/rtti.dart
- input_sdk/private/types.dart
- input_sdk/private/classes.dart
- input_sdk/private/errors.dart
- input_sdk/private/generators.dart
- input_sdk/private/operations.dart
- input_sdk/private/runtime.dart

Notes:
- Introduced genericTypeConstructor intrinsic: `JS('', '#(type)',
genericTypeConstructor(List))` generates `core.List$(type)`
- Used new JS quasiquotes everywhere
- Depends on new internal `@JSExportName` annotation to alias symbols like
dart.{as, is, const, assert, export, implements, throw, async, dynamic, void}
(see https://codereview.chromium.org/1580413002/)

BUG=
==========

to

==========
Generate _runtime.js from dart
(https://github.com/dart-lang/dev_compiler/issues/310)

The following part files were ported from the original .js
(lib/runtime/dart/_foo.js -> input_sdk/private/foo.dart):
- input_sdk/private/rtti.dart
- input_sdk/private/types.dart
- input_sdk/private/classes.dart
- input_sdk/private/errors.dart
- input_sdk/private/generators.dart
- input_sdk/private/operations.dart
- input_sdk/private/runtime.dart

Notes:
- Introduced genericTypeConstructor intrinsic: `JS('', '#(type)',
genericTypeConstructor(List))` generates `core.List$(type)`
- Used new JS quasiquotes everywhere
- Depends on new internal `@JSExportName` annotation to alias symbols like
dart.{as, is, const, assert, export, implements, throw, async, dynamic, void}
(see https://codereview.chromium.org/1580413002/)

BUG=
R=jmesserly@google.com

Committed:
https://github.com/dart-lang/dev_compiler/commit/6c1c9403788a85a98ee5d5a1f86f...
==========

[ochafik, 2016-01-21 00:45:39]

Committed patchset #24 (id:430001) manually as
6c1c9403788a85a98ee5d5a1f86ff2a3f6a61593 (presubmit successful).