Skip to content

Fix compatibility of Java with value classes #532

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

Merged
merged 2 commits into from
May 4, 2015

Conversation

smarter
Copy link
Member

@smarter smarter commented May 4, 2015

Review by @odersky.

@smarter smarter force-pushed the fix/vc-java-compat branch from ec9cfce to 656c248 Compare May 4, 2015 14:30
@DarkDimius
Copy link
Contributor

@smarter can you add a testcase?
I know that we do not have run tests tested yet, but this should not stop us from creating them.

@DarkDimius
Copy link
Contributor

Otherwise LGTM

This avoids getting a runtime error when calling a Java-defined method
whose signature contains value classes. It happened because we erased
the value classes in this signature even though it comes from a
classfile.

Amusingly, this problem also exists in scalac:
<https://issues.scala-lang.org/browse/SI-9298>
@smarter smarter force-pushed the fix/vc-java-compat branch from 656c248 to e8f3224 Compare May 4, 2015 15:20
@smarter
Copy link
Member Author

smarter commented May 4, 2015

Test added.

DarkDimius added a commit that referenced this pull request May 4, 2015
Fix compatibility of Java with value classes
@DarkDimius DarkDimius merged commit 61ddff4 into scala:master May 4, 2015
@retronym
Copy link
Member

retronym commented May 5, 2015

Probably worth a look at scala/scala@44b9cf0 which introduced nuanced erasure to Scala based on whether the symbol was Java/Scala, or constructor/non-constructor.

@DarkDimius
Copy link
Contributor

@retronym we already have different erasure for java-defined symbol, with different glb.
Why do you need to erase constructors differently?

@retronym
Copy link
Member

retronym commented May 5, 2015

I was echoing a comment in that commit. Looking back a bit further, I think it refers to the special case that the result type of a value class constructor should not erase to the underlying: scala/scala@e171d6d

I guess you have that covered already.

@retronym
Copy link
Member

retronym commented May 5, 2015

scala> case class C(val i: Int) extends AnyVal
defined class C

scala> :power

scala> val constructor = symbolOf[C].primaryConstructor
constructor: $r.intp.global.Symbol = constructor C

scala> erasure.specialErasure(constructor)(constructor.info)
res5: $r.intp.global.erasure.global.Type = (i: Int)C

scala> erasure.specialErasure(NoSymbol)(constructor.info)
res6: $r.intp.global.erasure.global.Type = (i: Int)ErasedValueType(class C, Int)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants