Analyzer performs override check between superinterfaces and superclass

[askeksa-google]

abstract class I {
  foo([a]);
}

abstract class A {
  foo() {}
}

abstract class B extends A implements I {}

class C extends B {
  foo([a]) {}
}

The analyzer complains (at the declaration of B) that the foo method in A is not a valid override of the foo method in I.

There is no override relationship between those two methods, so having them both in B is valid, because all of the following hold:

• One of the methods has a signature which is a valid override of the other (so there is a most specific one for the interface of the class).
• The class is abstract, so it doesn't have to have implementations for all methods in its interface.
• Every concrete subclass has an implementation that is a valid override of both methods (so the method implementation satisfies the override rules and the class implements its interface properly).

This looks like it could be some mix-up between override checking and checking that every concrete class conforms to its interface.

[jmesserly]

@leafpetersen - did we do this on purpose?

IIRC, strong mode initially did not allow abstract members to override concrete ones with a different signature. But that may have been for simplicity of the implementation. We could certainly relax this and accept this example. (Not sure if there's a Dart 2 spec for how this should work?)

As I was thinking about this, it occurred to me that abstract member overrides could probably break soundness in Analyzer, and sure enough:

class C {
  Object foo() => 42;
}
abstract class D extends C {
  String foo([int x]);
}
class E extends D {}

main() {
  String s = E().foo(123); // OOPS!
  print(s.trim());
}

So we've got to fix something here regardless. If we fix how concrete classes are checked against their interfaces, both of these examples will behave correctly (accepting the initial example, rejecting my example above).

[askeksa-google]

I have filed the missing interface checks in the analyzer as #34507.

[eernstg]

The current language specification specifies overriding in such a way that we must update it; e.g., it makes covariant parameters a compile-time error here (line 1479, 5dff98f):

It is a compile-time error if an instance method $m_1$ overrides an instance
member $m_2$ and the type of $m_1$ is not a subtype of the type of $m_2$.

So we can't just take everything from the language specification and be done with it.

However, the language specification does insist that the interface 'overrides' and 'inherits' relations treat all superinterfaces identically, so it would be a breaking change to start giving the superclass a different treatment than the classes that the current class implements.

Now, when we have several different member signatures for a given name and none is most specific, the language specification specifies that we will compute an interface whose type annotations are all dynamic. This is clearly not what we want to do in Dart 2. (The resulting method signature would of course also be a compile-time error today in many cases, and it was even an error in Dart 1 when it required a signature with both kinds of optional parameters at the same time ;-).

So we discussed how to update the specification on this topic. The following feature spec is in the pipeline (though not yet landed): interface-conflicts.md, introduced by this CL.

This feature spec specifies, exactly as stated by @askeksa-google, that all superinterfaces (i.e., the interface of the superclass as well as the interface of each class that it implements) are treated identically, and there is no requirement that any of them must override any others. (In particular, it is not required that a method signature in the interface of a class that it implements must override a signature with the same name from the interface of the superclass, nor the converse). So we just have the requirement that one of the method signatures must be more specific than all others, again exactly as @askeksa-google said. If no such most-specific signature is given then the developer must explicitly write one, we won't invent a solution.

@leafpetersen, @lrhn, do you agree that there is no doubt about the symmetric treatment of all superinterfaces? Do you foresee any changes to said feature spec with respect to the treatment of conflicts?

PS: The feature spec has a discussion about erasing certain top types to Object, but that's not part of the proposed specification, just a non-breaking extension that we can discuss later.

[scheglov]

OK, given that the specification is not complete, I'm moving this out of Dart2.1 milestone for analyzer.

[lrhn]

There is no doubt that we want the symmetric approach where the most specific member declaration among all super-interfaces is the interface signature inherited by the subclass (when it doesn't declare a signature itself). That has been the intended behavior for Dart 2.0 all along.

[eernstg]

Actually, dartLangSpec.tex does specify an error, as of a07b2a1, whenever there is no most-specific signature for a given member m (so the superinterfaces have multiple signatures for m, none of which is most specific, and the subclass itself does not declare m). I thought that change was part of a non-landed CL. But this means that there is no doubt that such a conflict is an error, and there is certainly no reason to consider this issue blocked on any spec updates.

[leafpetersen]

This would be good to fix for 2.1.

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/76061 (re)implements handling inheritance according to the updated spec, and how it was explained to me in mail. This fixes Analyzer for the original code, so it does not report any error.