Fasta: Missing override checks for mixins

[stereotype441]

Consider the following program:

class Base {
  void foo() {
    print('Base.foo called');
  }
}
class M1 {
  void foo({x}) {
    print('M1.foo called, with x=$x');
  }
}
class BaseWithM1 = Base with M1;
class M2 {
  void foo() {
    print('M2.foo called');
  }
}
class Derived extends BaseWithM1 with M2 {}
main() {
  new Derived().foo();
}

I'm not certain what the behavior of this program should be, but I think it should be either:

• Undefined due to an error (since the mixin application BaseWithM1 with M2 attempts to override foo({x}) with foo(), and overrides may not drop optional parameters.
• Prints M2.foo called.

If I run this under the VM, it reports no errors and prints M1.foo called, with x=null. That seems definitely wrong. So even though I'm not certain what the correct behavior should be I'm filing this as a VM bug. Feel free to reclassify if I'm wrong about this.

Note that this is a reduction of a situation arose in practice during development of the analyzer/front_end integration. The actual classes/methods involved were:

• Base -> Generator
• M1 -> KernelExpressionGenerator
• BaseWithM1 -> KernelGenerator
• M2 -> ContextAwareGenerator
• Derived -> KernelContextAwareGenerator
• foo -> buildCompoundAssignment

I'll shortly upload a CL that modifies the parameters of buildCompoundAssignment to work around this issue.

Cc @leafpetersen, @eernstg, and @lrhn to weigh in on what the correct behavior should be.

[eernstg]

That program should have a compile-time error, so it's the "Undefined" case that applies, for exactly the reason stated.

With the new mixin declaration and the associated new rules, the error will be detected during mixin application because of the incorrect override relationship from M2.foo to M1.foo.

Also, based on the specification of mixin composition (current spec, 12.2 Mixin Composition), application of a mixin to a superclass is 'equivalent to' a particular ordinary class declaration, which would also ensure that this is a compile-time error because of an override that does not satisfy the associated constraints.

[Edit: PS: It may be helpful to consider the sequence of mixins: Derived = [{}, M2, M1, Base, Object], where {} stands for the class body that occurs in the same line as class Derived. With that, it's easier to see that the relevant override relation is "M2.foo overrides M1.foo".]

[kmillikin]

Yeah, it's an error that should be signaled by the front end.

[eernstg]

Stray thought: I thought that the common front end would eliminate mixins by rewriting them (pretty much like section 12.2 says) into regular class declarations, so why doesn't that override relation get checked just like all other override relations?

[kmillikin]

We don't eliminate mixins that way because it's a whole-program transformation and hostile to separate compilation. (It's ML defunctorization.)

What we do do is we name all the mixin application classes, so the output of Fasta doesn't have anonymous mixin applications. We could check the mixin application classes for invalid overrides, but we don't and that's why I say it's a bug in Fasta.

[dhil]

By looking at the implementation of checkMethodOverride it seems that all the necessary machinery is in place, it just happen that the machinery is disabled for this particular case. The start of the method reads

bool checkMethodOverride(
    ClassHierarchy hierarchy,
    TypeEnvironment typeEnvironment,
    Procedure declaredMember,
    Procedure interfaceMember) {
  if (declaredMember.enclosingClass != cls) {
    // TODO(ahe): Include these checks as well, but the message needs to
    // explain that [declaredMember] is inherited.
    return false;
  }
(the remainder is omitted)
}

I suppose the "these checks" refer to the subsequent ~140 lines of code. Indeed I have confirmed that by removing the conditional statement fasta detects the error (the program bug.dart contains the example above):

$ fasta compile --strong bug.dart
bug.dart:13:8: Error: The method '_Derived&BaseWithM1&M2::foo' has fewer named arguments than those of overridden method 'M1::foo'.
  void foo() {
       ^
bug.dart:7:8: Context: This is the overriden method ('foo').
  void foo({x}) {
       ^

Thus it seems that we can fairly quickly patch this issue. [EDIT: the standard library fails to compile if one simply removes the conditional. Some more thought is required.] The proper solution would be to hoist out the hard-coded assumptions after the conditional statement in the body of checkMethodOverride, and instead parameterise the body such that we can generate specialised/better error messages.