No error in CFE when mixin invokes an abstract super method

[sgrekhov]

The following code produces an error in Analyzer and no issues in CFE.

abstract class A {
  int get index;
}

mixin M on A {
  int get index => super.index + 1;
}

class AM extends A with M { // Analyzer error here. The class doesn't have a concrete implementation of the super-invoked member 'index'. - mixin_application_no_concrete_super_invoked_member 
  int get index => 42;
}

main() {
  AM am = new AM();
  print(am.index);  // prints 42 in VM
}

cc @eernstg to confirm that analyzer's behavior is right here

Tested on Dart SDK version: 2.15.0-168.0.dev (dev) (Thu Sep 30 12:23:13 2021 -0700) on "windows_x64"

[eernstg]

Yes, we have this:

It is a compile-time error to apply $M$ to $S$ if $S$ does not implement,
directly or indirectly, all of $T_1$, \ldots, $T_n$.
It is a compile-time error if any of \metavar{members} contains a
super-invocation of a member $m$ \commentary{(for example \code{super.foo},
\code{super + 2}, or \code{super[1] = 2})}, and $S$ does not have a concrete
implementation of $m$ which is a valid override of the member $m$ in
the interface $M_S$.

This means that the existence of the super-method implementation should be checked for each mixin application. The invocation is not checked (that's done once and for all, based on the interface of the enclosing mixin/class of the mixed-in method), and this means that there can be a dynamic error (if the inherited method has a parameter which is covariant-by-declaration).

[johnniwinther]

This is a known missing check on the CFE part.

The problem with this check is that there is no natural point at which to perform it. The VM and dart2js (in its current state) could perform it as part of the their mixin transformations. DDC, however, doesn't have this point in time, because it compiles modularly using outlines, which don't contain method bodies, so there is no way to know which supercalls to check.

[eernstg]

Sounds like the outline of a mixin would need to include the names of members that are invoked in a super-invocation..

[johnniwinther]

Yes, but the purpose of the outline it to avoid parsing the body for speedy processing. - Can't have your cake and eat it too.

[sigmundch]

Yes, but the purpose of the outline it to avoid parsing the body for speedy processing. - Can't have your cake and eat it too.

Given that super calls are already using the reserved keyword super, would it be possible to use a naive/diet traversal of the token stream to extract the member names? For example, extracting the identifier in ... super.<identifier> ... regardless of context?