CFE constant initializers sometimes have duplicate optional argument keys.

[Markzipan]

For the following snippet:

const a = A();

class A extends Z<int> {
  const A() : super();

  @override
  final int defaultValue = 100;
}

class Z<T> {
  final T defaultValue;
  const Z({this.defaultValue});
}

main() {
  print(a.defaultValue);
}

the CFE generates:

main = sta::main;
library from "org-dartlang-app:/static1.dart" as sta {

  class A extends sta::Z<core::int*> {
    @#C1
    final field core::int* defaultValue = 100;
    const constructor •() → sta::A*
      : super sta::Z::•()
      ;
  }
  class Z<T extends core::Object* = dynamic> extends core::Object {
    final field sta::Z::T* defaultValue;
    const constructor •({sta::Z::T* defaultValue = #C2}) → sta::Z<sta::Z::T*>*
      : sta::Z::defaultValue = defaultValue, super core::Object::•()
      ;
  }
  static const field sta::A* a = #C4;
  static method main() → dynamic {
    core::print(sta::a.{sta::A::defaultValue});
  }
}
constants  {
  #C1 = core::_Override {}
  #C2 = null
  #C3 = 100
  #C4 = sta::A {defaultValue:#C3, defaultValue:#C2}
}

The VM and DDC print 100, but DDK prints null because it emits both defaultValue arguments from left-to-right without any de-duping logic.

Are default parameters supposed to be de-duped in the CFE, or is there some sort of prescribed evaluation order (right-to-left here)? This pattern is used a bit in google3.

[askeksa-google]

The CFE outputs references to the actual fields, which are distinct. The textual Kernel output contains just the names of the fields, which is confusing, but it is not related to the problem we see in DDK.

When a field is overridden, DDK outputs an object with duplicate keys:

dart.defineLazy(CT, {
  get C0() {
    return C0 = dart.const({
      __proto__: $37839.A.prototype,
      defaultValue: 100,
      defaultValue: null
    });
  }
});

In this case, where the field is virtual (as defined by ClassPropertyModel.virtualFields), it should output the actual keys of the underlying fields, i.e.

dart.defineLazy(CT, {
  get C0() {
    return C0 = dart.const({
      __proto__: $37839.A.prototype,
      [Symbol("A.defaultValue")]: 100,
      [Symbol("Z.defaultValue")]: null
    });
  }
});

I couldn't figure out how to get at these names, in particular since the ClassPropertyModel seems to only be available while compiling the class.

But there is a workaround that we can implement quickly, which will work as long as the overriding class does not bypass the field override explicitly by using super. We can simply output the fields in the opposite order, which will output subclasses after superclasses. This is not a specified and enforced order in the Kernel output, but it is what the CFE constant evaluator does, so it can work until we establish a more complete solution. I uploaded a CL for the workaround here: https://dart-review.googlesource.com/c/sdk/+/113060

[johnniwinther]

An example of the code the doesn't work with the workaround is:

class A {
  final field;
  const A(this.field);
}
class B extends A {
  final field;
  const B(this.field, fieldA) : super(fieldA);
  get fieldA => super.field;
}
main() {
  print(const B(1,2).fieldA); // prints 'null' instead of '2' with the workaround.
}

[Markzipan]

We filed bug a bit after this one that might actually be the same issue manifested differently. The DDK property model seems to be missing something: #37855

[vsmenon]

@Markzipan - with the workaround landed, is this still an internal blocker for DDK?

[Markzipan]

Unless someone's doing what Johnni pointed out internally, technically no. But I won't know that until tonight's presubmit.