Fun with overrides

[DarkDimius]

Simple example. Fails in scalac\javac, succeeds in Dotty.

class A[T] {
  def foo(x: T): T
  def foo(x: Int): Int
  new A[Int]().foo(1) // what foo should be called? scalac/javac issue an error here. Dotty calls the lexically-first one
}

More complicated example:

abstract class A {
  type C[X]
  def foo[B](x: C[B]): C[B]       = {println("A.C"); x}
  def foo[B](x: List[B]): List[B] = {println("A.List"); x}
  def give[X]: C[X]
}

class B extends A {
  type C[X] = List[X]
  override def give[X] = Nil
  override def foo[B](x: C[B]): C[B] =  {println("B.C"); x} 
                                           // which method is overriden? 
                                           // should any bridges be generated?
  val a: A = this
  a.foo(a.give[Int]) // what method should be called here in runtime?
}

In this example neither scalac nor dotty generate bridges.
Ping @retronym @adriaanm

[retronym]

scala> class C[A]{def foo(a: A) = 0; def foo(i: String) = 1}; class D extends C[String]
defined class C
defined class D

scala> new D().foo("")
<console>:14: error: ambiguous reference to overloaded definition,
both method foo in class C of type (i: String)Int
and  method foo in class C of type (a: String)Int
match argument types (String)
       new D().foo("")
               ^

scala> (new D(): C[String]).foo("")
<console>:14: error: ambiguous reference to overloaded definition,
both method foo in class C of type (i: String)Int
and  method foo in class C of type (a: String)Int
match argument types (String)
       (new D(): C[String]).foo("")
                            ^

scala> (new D(): C[_]).foo("")
res12: Int = 1

Compare with:

public class Test {
    public static class C<A> {
        public int foo(A a) { return 0; }
        public int foo(String i) { return 1; }
    }
    public static class D extends C<String> {}
}

% javac sandbox/Test.java
sandbox/Test.java:6: error: methods foo(A) from C<String> and foo(String) from C<String> are inherited with the same signature
    public static class D extends C<String> {}
                  ^
  where A is a type-variable:
    A extends Object declared in class C
1 error

I'd argue we should perform the same check in refchecks.

We're in good company with this omission, JetBrains only fixed it in their Java support three months ago.

IntelliJ Java: https://youtrack.jetbrains.com/issue/IDEA-67838
JDT: https://bugs.eclipse.org/bugs/show_bug.cgi?id=80739

[retronym]

In

class A[T] {
  def foo(x: T): T = ???
  def foo(y: Int): Int = ???
}
class Test { def test(a: A[Int]) = a.foo(1) }

dotc picks the first foo in filterDisjoint in:

    /** All members of this class that have the given name.
     *  The elements of the returned pre-denotation all
     *  have existing symbols.
     */
    final def membersNamed(name: Name)(implicit ctx: Context): PreDenotation = {
      val privates = info.decls.denotsNamed(name, selectPrivate)
      privates union nonPrivateMembersNamed(name).filterDisjoint(privates)
    }

This seems incorrect to me. I think the root problem might be considering that one method matches another, even though they have the same owner, and hence can never override one another.

Compare with the related code in FindMembers in scalac:

    // True unless the already-found member of type `memberType` matches the candidate symbol `other`.
    protected def isNewMember(member: Symbol, other: Symbol): Boolean =
      (    (other ne member)
        && (    (member.owner eq other.owner)                         // same owner, therefore overload
             || (member.flags & PRIVATE) != 0                         // (unqualified) private members never participate in overriding
             || (other.flags & PRIVATE) != 0                          // ... as overrider or overridee.
             || !(memberTypeLow(member) matches memberTypeHi(other))  // do the member types match? If so, it's an override. Otherwise it's an overload.
           )
      )

[odersky]

I'd argue we should perform the same check in refchecks.

I tend to agree. @DarkDimius can specialization avoid generating this pattern?

[odersky]

@retronym Actually, I do not see an obvious reason why javac insists on different signatures.

Can you explain the logic behind

sandbox/Test.java:6: error: methods foo(A) from C<String> and foo(String) from C<String> are inherited with the same signature
    public static class D extends C<String> {}
              ^
  where A is a type-variable:
    A extends Object declared in class C
 1 error

?

[DarkDimius]

@DarkDimius can specialization avoid generating this pattern?

I will try and see If it could.

[retronym]

@odersky I haven't thought too deeply about whether it would be sufficient to flag an error at call sites, rather than also preventing the clash at the point of inheritance

However, this seems like an area where we ought to justify a deviation from javac.

Here's the bug and test case that seems to have been the genesis of the checks in 2003 era Java by @gafter.

https://bugs.openjdk.java.net/browse/JDK-4906586
http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/tip/test/tools/javac/Ambig3.java
http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/tip/test/tools/javac/Ambig3.out

One problem (perhaps not quite sufficient to motivate the "same signature" error) is that within such a class any attempt override the methods would be ambiguous.

I'll think about it a bit more and see if I can find an unsoundness that wouldn't be prevented by the call site check.

[odersky]

On Sun, May 1, 2016 at 6:39 AM, Jason Zaugg notifications@github.com
wrote:

@odersky https://github.com/odersky I haven't thought too deeply about
whether it would be sufficient to flag an error at call sites, rather than
also preventing the clash at the point of inheritance

However, this seems like an area where we ought to justify a deviation
from javac.

Here's the bug and test case that seems to have been the genesis of the
checks in 2003 era Java by @gafter https://github.com/gafter.

https://bugs.openjdk.java.net/browse/JDK-4906586

http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/tip/test/tools/javac/Ambig3.java

http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/tip/test/tools/javac/Ambig3.out

One problem (perhaps not quite sufficient to motivate the "same signature"
error) is that within such a class any attempt override the methods would
be ambiguous.

But would that be a problem? After erasure, the two methods have different
signatures (or else we would have already gotten a signature clash error in
erasure). That means one or both of them get a bridge. We will thus get one
overriding method that overrides both of them.

• Martin

I'll thing about it a bit more and see if I can find an unsoundness that
wouldn't be prevented by the call site check.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1240 (comment)

Prof. Martin Odersky
LAMP/IC, EPFL

[odersky]

@retronym run/i1240.scala contains a possibly problematic case, where it is not clear
which of two methods should override. It turns out all compilers pick one of the two methods
over the other. javac does give an error, but only in a special case.

[retronym]

That's a good test case.

I disagree with "It would be acceptable if this produced an error instead." for the code associated with the call to b1.foo. You would need to outlaw C[D], which seems to restrictive.

Maybe javac is being unnecessarily restrictive by disallowing C[D] as a parent type of a class. I still can't think of a case where removing this restriction would immediately lead to an unsoundness.

A useful principle to keep in mind is that overriding relationships (and hence, bridging) decisions must be statically made in the class that defines the potentially-overriding-methods, and can't be made individually at call sites that select from some particular instantiation of the class type parameters.

We will thus get one overriding method that overrides both of them.

What would a call to super mean in that method? An ambiguity error?

Incidentally, I found a related compiler error from javac if we use interfaces rather than classes.

    public interface C<A> {
        default int foo(A a) { return 0; }
        default int foo(String i) { return 1; }
    }
    public interface D extends C<String> {}

⚡ javac sandbox/Test.java
sandbox/Test.java:6: error: interface D inherits unrelated defaults for foo(String) from types C and C
    public interface D extends C<String> {}
           ^
1 error

[odersky]

What would a call to super mean in that method? An ambiguity error?

If the super is explicit in the source, that's what I would expect. For a super-accessor of a trait, it's not clear. The current solution will report a merge error.