Fixes to get Swarm demo working again.

Fixes to get Swarm demo app working again.
The key fix is that we correctly specialize the parent of a generic type, and ensure that inherited generic members are created on the correct concrete type. Otherwise, we end up pulling the base method into the derived ConcreteType, potentially pulling it into a totally different library and messing up private member access. To make this work in the generated code, we need to also pull these members into the derived ConcreteType's prototype.

Committed: https://code.google.com/p/dart/source/detail?r=1670

[Jennifer Messerly, 2011-11-18 18:51:29]

Here's an example of the main issue. Consider:

#library('lib1');
class Base<T> {
  foo() => _bar() + 42;
  _bar() => 100;
}
#library('lib2');
class Derived<T> extends Base<T> {
  baz() => foo();
}
main() { new Derived<int>().baz(); }

What we used to do is put ConcreteMember for "foo" onto Derived$int, which meant
that the "_bar" lookup happened in lib2 instead of lib1. Now we put the
ConcreteMember for "foo" on Base$int (which is also now the parent of Derived
$int).

http://codereview.chromium.org/8588060/diff/1001/frog/gen.dart
File frog/gen.dart (right):

http://codereview.chromium.org/8588060/diff/1001/frog/gen.dart#newcode308
frog/gen.dart:308: Object.getOwnPropertyNames(parent).forEach(function(name) {
Not sure if it makes sense to do this on the JS side. This is inspired by
traitjs, but simpler because we don't need to worry about conflict resolution,
enumerable/non-enumerable, etc.

I tried doing it in both the JS side and directly emitting the right assignments
in gen.dart--this version was smaller code, because I didn't need to duplicate
the logic from _writeType, _writeMethod, _writeField, _writeProperty, etc.

http://codereview.chromium.org/8588060/diff/1001/frog/gen.dart#newcode829
frog/gen.dart:829: if (f.isField && !f.isStatic) {
these can be ConcreteMembers too

http://codereview.chromium.org/8588060/diff/1001/frog/gen.dart#newcode954
frog/gen.dart:954: for (var member in allMembers) {
this fixes an inconsistency: the loop above was using getAllMembers, but this
one wasn't.

http://codereview.chromium.org/8588060/diff/1001/frog/type.dart
File frog/type.dart (right):

http://codereview.chromium.org/8588060/diff/1001/frog/type.dart#newcode111
frog/type.dart:111: void _checkOverride(Member member) {
this was extract:method

http://codereview.chromium.org/8588060/diff/1001/frog/type.dart#newcode122
frog/type.dart:122: Member _createNotEqualMember() {
this and _getMemberInParents are just moved from DefinedType so ConcreteType can
also take advantage of them.

http://codereview.chromium.org/8588060/diff/1001/frog/type.dart#newcode532
frog/type.dart:532: Type get parent() {
addressing this TODO is what caused the fallout in gen.dart with $inheritMembers

http://codereview.chromium.org/8588060/diff/1001/frog/type.dart#newcode619
frog/type.dart:619: // through superclass/interfaces is handled below.
ensures we don't put a member from a supertype onto this ConcreteType

[Jennifer Messerly, 2011-11-18 19:54:36]

When I merged, I had to temporarily disable swarm_test again due to DOM changes
yesterday. Vijay is looking into it. In the meantime, going to check this in so
we have the generics fix.

[Siggi Cherem (dart-lang), 2011-11-18 20:09:58]

minor drive-by comment

http://codereview.chromium.org/8588060/diff/3003/frog/gen.dart
File frog/gen.dart (right):

http://codereview.chromium.org/8588060/diff/3003/frog/gen.dart#newcode320
frog/gen.dart:320: }""");
should this code be in corejs.dart?

[Jennifer Messerly, 2011-11-18 21:30:07]

http://codereview.chromium.org/8588060/diff/3003/frog/gen.dart
File frog/gen.dart (right):

http://codereview.chromium.org/8588060/diff/3003/frog/gen.dart#newcode320
frog/gen.dart:320: }""");
On 2011/11/18 20:09:58, sigmund wrote:
> should this code be in corejs.dart?

Similar to _ensureInherits, it can't be, because we don't know we need it until
we start writing stuff, at which point it's too late--corejs has already been
generated.

I tried really hard to keep the corejs helpers generated near corelib, because
it produces nicer looking output.

[Siggi Cherem (dart-lang), 2011-11-18 21:31:44]

On 2011/11/18 21:30:07, John Messerly wrote:
> http://codereview.chromium.org/8588060/diff/3003/frog/gen.dart
> File frog/gen.dart (right):
> 
> http://codereview.chromium.org/8588060/diff/3003/frog/gen.dart#newcode320
> frog/gen.dart:320: }""");
> On 2011/11/18 20:09:58, sigmund wrote:
> > should this code be in corejs.dart?
> 
> Similar to _ensureInherits, it can't be, because we don't know we need it
until
> we start writing stuff, at which point it's too late--corejs has already been
> generated.
> 
> I tried really hard to keep the corejs helpers generated near corelib, because
> it produces nicer looking output.

makes sense - thanks!

[jimhug, 2011-12-14 19:00:56]

lgtm

http://codereview.chromium.org/8588060/diff/3003/frog/gen.dart
File frog/gen.dart (right):

http://codereview.chromium.org/8588060/diff/3003/frog/gen.dart#newcode20
frog/gen.dart:20: CodeWriter _mixins;
<smile>

http://codereview.chromium.org/8588060/diff/3003/frog/value.dart
File frog/value.dart (right):

http://codereview.chromium.org/8588060/diff/3003/frog/value.dart#newcode182
frog/value.dart:182: where = 'library "${context.library.name}"';
Nice message fix.