Fix #5433: check that the implemented super-accessor is valid

[smarter]

Relying on matchingDenotation is not enough as demonstrated by
i5433.scala: in Fail, B#foo matches C$$super$foo
but it cannot implement it since X is a supertype of Y

Note that scalac seems to have the same bug (but at least in Dotty this
is detected by -Ycheck:all).

For reference, here's what the spec says on resolving super accessors:

A reference super.m refers statically to a method or type m in the
least proper supertype of the innermost template containing the
reference. It evaluates to the member m′ in the actual supertype of that
template which is equal to m or which overrides m.

This seems like it should be clarified to indicate that the member m'
may be found not only in "the actual supertype" (defined elsewhere) but
in any supertype of the actual supertype.

[odersky]

@smarter I did the change we discussed. Can I go ahead merging this?

[allanrenucci]

Note that it doesn't fix the original compilation order issue. What used to be a Ycheck failure is now a compilation error:

-- Error: dotty/scala2-library/src/library/scala/collection/mutable/IndexedSeqView.scala:46:37 
46 |  private[collection] abstract class AbstractTransformedX[B] extends super.AbstractTransformedS[B] with TransformedX[B]
   |                                     ^
   |                        illegal mixin super call target:
   |                        
   |                          override def tail: => scala.collection.SeqView[B, Coll]  in class AbstractTransformedS
   |                        
   |                        does not conform to expected target type
   |                        
   |                          => Repr

Can be reproduced by sorting the files from the compileStdLib test

[odersky]

@allanrenucci Yes, unfortunately the standard library is in error here. Since it would be a pain to fix, and since the standard library is also going away I would recommend to simply keep the old ordering, which compiles OK. I.e. try to work around the error in the stdlib.

[smarter]

Since it would be a pain to fix

Not really, we just need to replace some instances of super.tail by super[Something].tail.

@smarter I did the change we discussed. Can I go ahead merging this?

The fix is OK but I'd like to improve the error message to give more details (explain that the issue comes from the linearization orders, which mixins are involved, how the issue could be solved by replacing super.foo by super[X].foo, ...). This isn't critical to merge this if you want to go ahead.

[odersky]

No, I guess if you have improvements in the pipeline we can leave this open.

[adriaanm]

This one looks related: explicitly targeting an abstract super method should also yield an error, right?

scala/bug#8693

[smarter]

Alright, I've now made the error message as helpful as I could:

-- Error: tests/neg/i5433.scala:17:6 -------------------------------------------
17 |class Fail extends B with C // error
   |      ^
   |class Fail cannot be defined due to a conflict between its parents when
   |implementing a super-accessor for foo in trait C:
   |
   |1. One of its parent (trait C) contains a call super.foo in its body,
   |   and when a super-call in a trait is written without an explicit parent
   |   listed in brackets, it is implemented by a generated super-accessor in
   |   the class that extends this trait based on the linearization order of
   |   the class.
   |2. Because B comes before C in the linearization
   |   order of Fail, and because B overrides foo,
   |   the super-accessor in Fail is implemented as a call to
   |   super[B].foo.
   |3. However,
   |   X (the type of super[B].foo in Fail)
   |   is not a subtype of
   |   Y (the type of foo in trait C).
   |   Hence, the super-accessor that needs to be generated in Fail
   |   is illegal.
   |
   |Here are two possible ways to resolve this:
   |
   |1. Change the linearization order of Fail such that
   |   C comes before B.
   |2. Alternatively, replace super.foo in the body of trait C by a
   |   super-call to a specific parent, e.g. super[A].foo
one error found

/cc @adriaanm it'd be nice to align the messages between scalac and dotty here: scala/scala#7641