object RxTests {
case class Wat(w: String)
def getWat(str: String) = upickle.default.read[Wat](str)
val tmp: Rx[Wat] = Rx { Wat("wat") }
val tmpRx: Rx[Wat] = tmp.map { w =>
//getWat("""{"w":"wat"}""") //this works
upickle.default.read[Wat]("""{"w":"wat"}""") //compile time error
}
}
leads to
[error] /home/nick/forks/upickle/upickle/shared/src/test/scala/upickle/RxTests.scala:16: derive$macro$89 is already defined as value derive$macro$89
[error] upickle.default.read[Wat]("""{"w":"wat"}""") //compile time error
[error] ^
[error] one error found
[error] (upickleJVM/test:compileIncremental) Compilation failed
That rather awkward compiler error appears to be some kind of problematic implicit resolution that happens while the Rx macro is doing its transformation. The upickle reader macro does seem to be executing (at least) twice when it should only run once. As far as the upickle reader macro producing literally identical code twice (even though freshName is used) is confusing, but it would seem that it is generating multiple copies of the same reader.
While I haven't figured out how to solve this exact problem, there are two workarounds I am aware of. The first, as shown in the example, is to simply differ the upickle.read to some other function - this changes where the implicit reader macro is inferred and avoids the problematic reader implicit inference inside the Rx macro.
Another way to achieve a similar effect is to explicitly define the upickle reader (or writer) inside the companion object of the problematic class, ie:
object Wat {
implicit val pklR = upickle.default.macroR[Wat]
implicit val pklW = upickle.default.macroW[Wat]
}
This again changes where and when the upickle reader implicit is inferred, sidestepping the problem altogether.
Given
leads to
That rather awkward compiler error appears to be some kind of problematic implicit resolution that happens while the Rx macro is doing its transformation. The upickle reader macro does seem to be executing (at least) twice when it should only run once. As far as the upickle reader macro producing literally identical code twice (even though freshName is used) is confusing, but it would seem that it is generating multiple copies of the same reader.
While I haven't figured out how to solve this exact problem, there are two workarounds I am aware of. The first, as shown in the example, is to simply differ the upickle.read to some other function - this changes where the implicit reader macro is inferred and avoids the problematic reader implicit inference inside the Rx macro.
Another way to achieve a similar effect is to explicitly define the upickle reader (or writer) inside the companion object of the problematic class, ie:
This again changes where and when the upickle reader implicit is inferred, sidestepping the problem altogether.
ID: 136 Original Author: Voltir