-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Erase constant value type #9431
Conversation
Quick lunchtime fix. This probably breaks overriding a method of literal type. (Edit: that works after all. I was wondering about the asymmetry of the fix.) |
@@ -4855,6 +4855,8 @@ trait Types | |||
false | |||
case PolyType(_, _) => | |||
false | |||
case ConstantType(_) => | |||
matchesType(tp1, tp2.underlying.widen, alwaysMatchSimple) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced this is the right fix. IIUC, matches
is used for override checking.
I really don't understand why alwaysMatchSimple
is !phase.erasedTypes
, an explanation of this would be very welcome. The result is (without your patch):
scala> typeOf[Int] matches typeOf[String]
val res3: Boolean = true
scala> exitingErasure(typeOf[Int] matches typeOf[String])
val res4: Boolean = false
The bug is that Mixin creates a mixin forwarder in X
for P.p
, it shouldn't do that. Your patch fixes that, so it does have an effect in Mixin, but I fear that it has more (potentially undesired) effects. With your patch:
scala> exitingErasure(typeOf[""] matches typeOf[String])
val res2: Boolean = false
scala> typeOf[Int] matches typeOf[String]
val res3: Boolean = true
In Mixin, there is a call to matchesType
which explicitly sets alwaysMatchSimple = true
. So maybe the bug is that through some different patch we get from Mixin to matchesType
with alwaysMatchSimple = false
?
Or maybe the bug is that the ConstantType
is not erased?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't understand why
alwaysMatchSimple
is!phase.erasedTypes
, an explanation of this would be very welcome
Maybe the idea is "let's assume things override" before erasure. RefChecks will issue errors when overridding is not correct.
Or maybe the bug is that the
ConstantType
is not erased?
scala> trait P { def p: String = "p" }
| class X extends P { override final val p = "x" }
| class Y extends P { override final val p: "x" = "x" }
scala> exitingErasure(typeOf[X].member(TermName("p")).tpe)
val res1: $r.intp.global.Type = String("x") <and> String
scala> exitingErasure(typeOf[Y].member(TermName("p")).tpe)
val res2: $r.intp.global.Type = (): String
scala> (new X).p
java.lang.ClassFormatError: Duplicate method name "p" with signature "()Ljava.lang.String;" in class file X
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at scala.reflect.internal.util.AbstractFileClassLoader.findClass(AbstractFileClassLoader.scala:77)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
... 36 elided
scala> (new Y).p
val res4: String = x
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll convert to draft and give it some thought.
I moved the scouting commits to a separate PR.
@lrytz I'll rework this. Also Jean Rondeau will be in Zürich per the website |
@som-snytt is this one you're thinking of reviving...? |
@SethTisue yes, although like all old relationships, I've forgotten what was so attractive about it. |
For my stage name, I may take "Johnny Rondo". TIL "Ryan Starr" is just a stage name. This is the "quick lunchtime fix" I must have intended two years ago. It is also the last of Lukas's semi-rhetorical questions. In the test, explicitly annotated I did not answer Lukas's other question about |
The answer is
and various osgi
|
Mixin was confused when
String("hello, world")
overridesString
.Fixes scala/bug#12301