Value classes of Unit produces invalid bytecode #9240
Comments
|
Imported From: https://issues.scala-lang.org/browse/SI-9240?orig=1
|
|
I just ran into this one. On 2.11.x you get a |
|
In Scala 2.12, it's sufficient to write this to cause the compiler to crash: |
|
Or on 2.11 The new puzzler challenge is, what's the shortest crasher using arbitrary compiler options? |
This was referenced Jun 8, 2017
hrhino
added a commit
to hrhino/scala
that referenced
this issue
Jun 11, 2017
…ing. All sorts o' specialness going on here. Unit morphs into a BoxedUnit when it's in a field, but void when it's the return type of a method, which is expected. This means, though, that the unboxing method of a Unit-wrapping value class has the signature `()V`, not `()Lscala/runtime/BoxedUnit`, so attempting to use its value in the equals method spits out some wonderful invalid bytecode, instead. Similar sadness occurs for Nothing and Null as well. The "solution" is to not even bother to check for equality, as we've only got at most one legitimate value of each of these types. Because the code is shared with `case class`es, this also changes the bytecode we generate for them. Obviously this is an "unrelated change" as far as the bugs this is meant to fix go, but it's innocuous enough as far as I can tell. I also slipped a constructor call into the generated `ClassCastException` that gets thrown when we are asked to emit a cast for a primitive type in BCodeBodyBuilder, so we generate valid bytecode in that case. I've got no idea how `NEW; DUP; ATHROW` is possibly ever legitimate, but hey. Fixes scala/bug#9240 Fixes scala/bug#10361
hrhino
added a commit
to hrhino/scala
that referenced
this issue
Jun 13, 2017
…ing. All sorts o' specialness going on here. Unit morphs into a BoxedUnit when it's in a field, but void when it's the return type of a method, which is expected. This means, though, that the unboxing method of a Unit-wrapping value class has the signature `()V`, not `()Lscala/runtime/BoxedUnit`, so attempting to use its value in the equals method spits out some wonderful invalid bytecode, instead. Similar sadness occurs for Nothing and Null as well. The "solution" is to not even bother to check for equality, as we've only got at most one legitimate value of each of these types. Because the code is shared with `case class`es, this also changes the bytecode we generate for them. Obviously this is an "unrelated change" as far as the bugs this is meant to fix go, but it's innocuous enough as far as I can tell. I also slipped a constructor call into the generated `ClassCastException` that gets thrown when we are asked to emit a cast for a primitive type in BCodeBodyBuilder, so we generate valid bytecode in that case. I've got no idea how `NEW; DUP; ATHROW` is possibly ever legitimate, but hey. Fixes scala/bug#9240 Fixes scala/bug#10361
hrhino
added a commit
to hrhino/scala
that referenced
this issue
Jun 14, 2017
…ing. All sorts o' specialness going on here. Unit morphs into a BoxedUnit when it's in a field, but void when it's the return type of a method, which is expected. This means, though, that the unboxing method of a Unit-wrapping value class has the signature `()V`, not `()Lscala/runtime/BoxedUnit`, so attempting to use its value in the equals method spits out some wonderful invalid bytecode, instead. Similar sadness occurs for Nothing and Null as well. The "solution" is to not even bother to check for equality, as we've only got at most one legitimate value of each of these types. Because the code is shared with `case class`es, this also changes the bytecode we generate for them. Obviously this is an "unrelated change" as far as the bugs this is meant to fix go, but it's innocuous enough as far as I can tell. I also slipped a constructor call into the generated `ClassCastException` that gets thrown when we are asked to emit a cast for a primitive type in `BCodeBodyBuilder`, so we generate valid bytecode if we ever wind in that branch. Discussion on scala#5938 implies that this branch shouldn't ever be reached, so add a devWarning now that it doesn't cause an obvious error. Fixes scala/bug#9240 Fixes scala/bug#10361
This was referenced Aug 21, 2017
xuwei-k
added a commit
to xuwei-k/scalaz
that referenced
this issue
May 21, 2018
S11001001
added a commit
to digital-asset/daml
that referenced
this issue
Sep 3, 2020
12 tasks
mergify bot
pushed a commit
to digital-asset/daml
that referenced
this issue
Sep 3, 2020
* get a LoggingContext into the TriggerRunnerImpl * make some implicits more implicitly scoped and explicitly ascribed * make some private/final markings * most of JsonFormat[Identifier] is in companion * experimental LoggingContext with phantom type * ActorContext#log isn't really doing that much * more details of LoggingContextOf * make LoggingContextOf compile * add trigger message logging, yet without context * fix parent compile errors * use Config as the phantom for its own logging extensions * LocalDateTimeFormat cleanup * switch TriggerRunner to contextual logging * add trigger definition ID to logs * log trigger-submitted commands, fix trigger test compile * log trigger stopping and DAR uploads * add context to PostStop/PreRestart logs * add changelog CHANGELOG_BEGIN - [Triggers] More detailed logging of trigger actions and trigger service actions. See `issue #7205 <https://github.com/digital-asset/daml/pull/7205>`_. CHANGELOG_END * missed copyright header * switch to Unit, scala/bug#9240 fixed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Value classes appear to always expect a value to be allocated to the stack, even when their type is Unit, and the implementation does not allocate any value. This results in a
java.lang.VerifyError.This is sufficient to replicate the error:
The text was updated successfully, but these errors were encountered: