Mixin on implementation doesn't show docs on hover

[FMorschel]

If you have the following:

abstract class Base {
  /// Documentation for foo.
  void foo();
}

// --------------------------

abstract class Base1 implements Base {
  @override
  void foo();
}

mixin MyMixin1 on Base1 {
  @override
  void foo() {}
}

// --------------------------

abstract class Base2 extends Base {
  @override
  void foo();
}

mixin MyMixin2 on Base2 {
  @override
  void foo() {}
}

On MyMixin1.foo the hover doesn't show the docs. But on MyMixin2.foo it does. The problem is that Base1 actually implements Base and Base2 extends it. That seems to be the problem. I'll see if I can fix it and open a CL when I have some time.

[dart-github-bot]

Summary: Hover documentation for methods in mixins is not displayed when the mixin is applied to a class that implements the base class, but it works when the mixin is applied to a class that extends the base class. This suggests an issue with how the documentation is inherited when using mixins with implemented interfaces.

[FMorschel]

https://dart-review.googlesource.com/395562

[bwilkerson]

I understand why the current behavior is the way it is. The on type (Base2) must be in the superclass chain for any class that mixes in MyMixin2, so the method foo will be an override of Base2.foo, and the convention is to copy the documentation from a superclass if a method doesn't already have it. This probably matches what dart doc does. (@srawlins to confirm)

That isn't the case with types in the implements clause. I don't have a problem with taking the documentation from an implemented type, but we'll need to consider the case where there are multiple implemented types that define the same member but with different docs. (Maybe take the docs from the lexically first type that has one?)

I don't know what dart doc does in any of the implements cases, but the analysis server should do the same thing (whichever one needs to be changed).

[FMorschel]

I'm not sure what is the preferred order but when you use multiple mixins in a class:

abstract class Base {
  void foo();
}

mixin MyMixin on Base {
  /// Docs for MyMixin.foo
  @override
  void foo() {}
}

mixin MyMixin2 on Base {
  /// Docs for MyMixin2.foo
  @override
  void foo() {}
}

class C1 extends Base with MyMixin, MyMixin2 {
  @override
  void foo() {}
}

class C2 extends Base with MyMixin2, MyMixin {
  @override
  void foo() {}
}

On C1.foo you have the docs for MyMixin.foo and on C2.foo you have the docs for MyMixin2.foo. Of course, this only overrides if the Base.foo declaration has no docs as well.

Just so we know what is done in different cases as well.

[bwilkerson]

Am I missing something, or are C1 and C2 semantically identical (only the names are different)?

If that's true, then I consider it a bug that the behavior isn't consistent.

[FMorschel]

Oops, I've tested with the mixins swapped and when coping the code over I forgot to make that a thing. Nice catch, will edit the previous comment. Sorry 🙃