New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lub as calculated by TypeKinds is incorrect #3872
Comments
Imported From: https://issues.scala-lang.org/browse/SI-3872?orig=1 |
@paulp said: scala> abstract class Tom
defined class Tom
scala> case object Bob extends Tom
defined module Bob
scala> case object Harry extends Tom
defined module Harry
scala> List(Bob, Harry)
res0: List[Product with Tom] = List(Bob, Harry) |
@paulp said:
Funny, it's been doing the lub that way since scala 0.minus-infinity and we come in two days apart in the late 3000s. Yes, it's a duplicate. I know you were dying to close it. Go ahead, it is rightfully yours. I'll just go over here and oh, I don't know, FIX THE LUB! |
@dragos said: def moo(x: Tom) {}
def moo2(x: Product) {}
moo(if (c) new Bob else new Harry)
moo2(if (c) new Bob else new Harry) I agree the lub should list classes first, but it won't solve the icode checker issue. The best way would be to simply make the icode checker less precise, and use the JVM notion of subtyping (which basically considers any interface type to be |
@paulp said:
This matches my understanding. So to summarize, there are two changes here: compound types list the class first (the classES first I suppose, since it general it offers no complaint about types like classA with classB) and then changing TypeKinds so the lub of an interface and any legal type is REFERENCE(AnyRef). If that sounds about right I am available to make these modifications. |
@magarciaEPFL said: Background, quoting from http://gallium.inria.fr/~xleroy/publi/bytecode-verification-JAR.pdf --- start quote --- See also http://comments.gmane.org/gmane.comp.java.vm.languages/2293 |
@magarciaEPFL said: Instead As an aside, the following excerpt from
|
Here is another one. The icode checker would crash finding an unexpected type on the stack, and I eventually pinpointed that it is calculating strange lubs. Here is a line from SymbolLoaders:
Both NoType and ErrorType have Type as a superclass, so one would expect the type of that expression to be Type. However when calculating the lub, what it actually calculates is Product.
The implementation is merely:
Before erasure the lub shows up as Product with Type. If I read the spec correctly it's allowed to not order this with the class first; but if that is indeed allowed, there must be some interface which utilizes intersectionDominator in erasure so the right type pops out, because I can't see when "Product" is ever what you'd want.
A seemingly simpler and more direct answer is to organize compound types with the class first all the time. Maybe there's a reason not to do that.
The text was updated successfully, but these errors were encountered: