isVolatile incorrect for intersection types

[samuelgruetter]

@namin and me had a look at the isVolatile method in Types/TypeOps.

If we try the following example:

object Test{
 trait A{
 type X = String
 }
 trait B{
 type X = Int
 }
 lazy val o: A & B = ???

 def xToString(x: o.X): String = x

 def intToString(i: Int): String = xToString(i)
}

It's accepted by dotty, which means that we can cast Int to String...

I added debug output for the results of isVolatile, and it prints

isVolatile(AndType(TypeRef(ThisType(module class Test$),A),TypeRef(ThisType(module class Test$),B)))=false

But as we understood isVolatile, it should return true for all types which are possibly uninhabited.

The and-case in needsChecking looks bad:

case AndType(l, r) =>
 needsChecking(l, true) || needsChecking(r, true)

because we cannot just look seperately at l and r, but we should check if there are conflicting members in l and r.

In Scala, this is not a problem, because we only have with, which is asymmetric, so the members of r override those of l and in our example, o.X is only Int.

From a theoretical point of view, we are bothered by the fact that !isVolatile is not preserved by weakening, i.e.

A <: B and !isVolatile(B) does not imply !isVolatile(A)

so we doubt if a !isVolatile judgment would be useful in a typesafety proof (needs more thinking...).

Additionally, if we replace the implementation of needsChecking (which seems to be just an optimization) by this

def needsChecking(tp: Type, isPart: Boolean): Boolean = true

we get a java.util.NoSuchElementException: head of empty list, so it's not just an optimization...

[samuelgruetter]

I just checked with the changes from #47 , but this problem remains (which is not surprising because #47 does not change isVolatile...)

[odersky]

Reopening to keep the test case around for the time we have refchecks written.

[samuelgruetter]

@smarter In this example, if we remove lazy, the program will crash when evaluating ???, so if we can cast Int to String afterwards, no one cares. However, if o is lazy (but never forced), we can cast Int to String, which is a typesafety breach.

[smarter]

@odersky : does this still need to be kept open?

[odersky]

Yes, the error is not detected. I'll put a test in pending/neg.

[namin]

Note that instead of an unimplemented lazy val, we could also have a null val.
We can also interchange with and &.

@RossTate and I found a similar issue that also affects scalac:
https://issues.scala-lang.org/browse/SI-9633