Support `@virtual` annotation on fields in DDC

[jmesserly]

these are being added to strong mode in #27384

[jmesserly]

Also we need to support @checked on fields.

[jmesserly]

given an example like:

import 'package:meta/meta.dart';

abstract class A {
  @virtual
  final Object x = 0;

  A() { print(x); }
}


class B extends A {
  Object get gee => super.x;
}

class C extends B {
  final Object x = 42;
}

main() {
  var c = new C();
  print(c.x);
  print(c.gee);
  print("foo");
}

it would be great to generate something like:

  bin__t.A_getter_x = class A_getter_x extends bin__t.A {
    new() {
      var setterProp = { configurable: true, set: function(x) {
        this[super_A_x] = x;
        delete this.x;
      } };
      Object.defineProperty(this, "x", setterProp);
      super.new();
    }
    get x() {
      return this[super_A_x];
    }
    set x(value) {
      this[super_A_x] = value;
    }
  }

  const super_A_x = Symbol(bin__t.A.name + "." + 'super_x'.toString());

  bin__t.B = class B extends bin__t.A_getter_x {

Whenever a class starts referring to super.x, or when a field x is overwritten (by a getter/setter or another field), insert this class in the hierarchy.

thanks to @floitschG for writing that up!

[jmesserly]

Note, above does not work if a mixin introduces a field override. Not in the way DDC currently expands mixins, at least: we currently merge all of the mixins together. But mixins could define the same field, effectively overriding between the mixins or in relation to the extended class. We might have to expand each level of mixins.

Another possible problem is anything that changes how the hierarchy looks has the potential of messing up mirrors. I don't think we rely on that, but it's a potential risk.

[jmesserly]

It turns out we already have some bugs related to how mixins are handled -- the existing support for a field that overrides a getter/setter also doesn't work correctly: #28059 ... so for now I will ignore mixins or possibly try to fix that bug before this one.

[jmesserly]

hit another snag, in this test: https://github.com/dart-lang/sdk/blob/master/tests/language_strong/super_field_2_test.dart#L17, because there's the super.foo reference. The problem is, we we want to use a JS instance property for foo we can't call super.foo. If fields are not allowed to be overridden, we can safely generate this.foo there. However that does not work in the face of field overrides that could happen later.

If we allow the field to be overridden, we need to treat B as overriding foo even though it doesn't actually do so. So we need to search for a super reference in the class body before we know if we need to override any fields.

That seems like a bridge too far, so I've backed out of that approach. Will link my updated CL.

[jmesserly]

https://codereview.chromium.org/2571363002/ -- note this patch relies on @virtual. I was not able to get it working without (see above).

[floitschG]

I'm not sure I understand your concerns wrt super.foo in https://github.com/dart-lang/sdk/blob/master/tests/language_strong/super_field_2_test.dart#L17

Why is it a problem to search for super.foo in the method bodies?