unsoundness in many guises

[scabug]

[Updated to consolidate demonstrations.]

class A { class E }
class B extends A { class E }
trait C { type E = Int }
trait D { type E = String }

object Test {
  // should not compile (?)
  // martin says "I'd argue about that"
  type EE[+X <: { type E }] = X#E

  def fail1() {
    val b = new B
    var x1: EE[A] = null
    var x2: EE[B] = new b.E
    x1 = x2
  }

  def fail2() {
    val b = new B
    var x1: p.E forSome { val p: A } = new b.E // should not compile
    var x2: p.E forSome { val p: B } = new b.E
    x1 = x2 // should not compile
  }

  def fail3() {
    var x1: EE[C] = 5
    var x2: EE[C with D] = ""
    x1 = x2
  }

  def wrap(label: String)(op: => Unit): Unit =
    try { op } catch { case x: ClassCastException => println("%30s %s".format(label, x)) }

  def main(args: Array[String]): Unit = {
    wrap("Variance and inner classes")(fail1())
    wrap("Conformance of existentials")(fail2())
    wrap("Linearization and type aliases")(fail3())
  }
}
//     Variance and inner classes java.lang.ClassCastException: B$E cannot be cast to A$E
//    Conformance of existentials java.lang.ClassCastException: B$E cannot be cast to A$E
// Linearization and type aliases java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-7278?orig=1
Reporter: @paulp
See #436, #902, #634
Duplicates #1557

[scabug]

@paulp said (edited on Mar 20, 2013 8:46:26 PM UTC):
Were E an abstract type, the E in B would be required to conform to the E in A. I assume the same requirement should be imposed on classes, which translates to: B#E must extend A#E.

[Update] I retitled this to point the unsoundness finger more vaguely, since martin says: "Same-named inner classes which are in no relationship with each other are explicitly allowed in both Java and Scala. I would like to tighten this - disallow then altogether or demand them to be in a subtype relationship. Unfortunately, this would break existing code [...] I believe they do not pose an unsoundness problem themselves. But they certainly are a trap to fall into in all sorts of feature interactions."

[Update] After finding another soundness hole which doesn't use existentials, I consolidated the code and retitled it even more vaguely.

[scabug]

@paulp said (edited on Mar 21, 2013 6:31:37 PM UTC):
I updated the code with a third soundness hole, this one using type aliases instead of inner classes. And I ported it so it fails on all scala versions from 2.7 onward.

[scabug]

@paulp said:
I see fail3() is not news; #1557 is reporting a variation on the problem in 2008. I am closing that as a duplicate, hoping it will receive more attention here. Enclosing the example because it exploits the problem differently.

trait A
trait B extends A

trait C {
  val x : AnyRef
  trait D { type T >: B <: A }
  val y: (D with x.type)#T = new B { }
}

class D extends C {
  trait E
  val x : AnyRef { type T = E} = null
  def frob(arg : E) : E = arg
  frob(y)
}

new D

[scabug]

@retronym said (edited on May 31, 2013 9:21:22 PM UTC):
Merging #7535 as a duplicate.

Code that provokes LinkageError

trait Def {
  type Element >: Null
  trait Motor {
    type Element = Def.this.Element
  }
}

trait Def2 extends Def {
  trait Element
  trait Motor extends super.Motor {
    def foo(parent: Element): Any
    foo(null)
  }
}

trait Def3 extends Def2 {
  trait Element // or extends super.Element2, same result.
  new super.Motor {
    def foo(e:Element): Any = null
  }
}

new Def3 {} // java.lang.AbstractMethodError: Main$$anon$3$Def3$$anon$2.foo(LMain$$anon$3$Def2$Element;)Ljava/lang/Object

Suggested:

trait Def {
  type Element >: Null
  trait Motor {
    type Element = Def.this.Element
  }
}

trait Def2 extends Def {
  type Element >: Null <: Element2 
  trait Element2
  trait Motor extends super.Motor {
    def foo(parent: Element): Any
    foo(null)
  }
}

trait Def3 extends Def2 {
  type Element >: Null <: Element3
  trait Element3 extends super.Element2
  new super.Motor {
    def foo(e:Element): Any = null
  }
}

new Def3 {}

[scabug]

@soc said:
An example which doesn't fail with a bang, but behaves in a way which seems to violate a lot of reasonable expectations:

  class Foo {
    class Bar {
      def foo = 1
    }
  }
 
  class SubFoo extends Foo {
    class Bar {
      def foo = 42
    }
  }

// Let's create some instances:
  val foo = new Foo
  val fooBar = new foo.Bar
  fooBar.foo                                      //> res0: Int = 1
  // ok

  val subFoo = new SubFoo
  val subFooBar = new subFoo.Bar
  subFooBar.foo                                   //> res1: Int = 42
  // ok

  val superFoo: Foo = subFoo
  val superFooBar = new superFoo.Bar
  superFooBar.foo                                 //> res2: Int = 1
  // NOT OK!

The last result is scary, because the syntax looks like things are dynamically bound, but the method is called on the static type instead.

Mailing list: https://groups.google.com/d/topic/scala-language/vQYwywr0LL4/discussion