Difference in compiler behavior 3.1.2 vs 3.1.3 - implicit resolution / type mismatch
See original GitHub issueCompiler version
3.1.2 / 3.1.3
Minimized code
This one’s in production code and difficult to provide a minimized example for, so apologies ahead of time…
This issue arises in the context of implicit resolution to find (I’m presuming) the applicable ToEntityMarshaller for the JsArray type.
For the implicit marshaller support I copied into my baseline the PlayJsonSupport trait from here: https://github.com/hseeberger/akka-http-json/blob/master/akka-http-play-json/src/main/scala/de/heikoseeberger/akkahttpplayjson/PlayJsonSupport.scala since it’s only one file and the library is not yet available in general for Scala 3.
// In an Akka-Http route using the following library versions:
// val playJsonVersion = "2.10.0-RC6"
// val akkaHttpVersion = "10.2.9"
// val akkaVersion = "2.6.19"
// All Akka dependencies are cross-compiled w/ `for3Use2_13`
// ...
def generateJsArray: JsArray = { /* ... */ }
//...
// some path routing logic in the Akka-Http server DSL then:
get {
complete[JsArray](StatusCodes.OK, generateJsArray)
}
UPDATE: Here’s a repo with a self-contained example. Change the scalaVersion
in build.sbt
to reproduce the issue: https://github.com/ALPSMAC/sample-scala3-compiler-bug/tree/main
Output
Under Scala 3.1.2 this compiles as expected. Under Scala 3.1.3 I get a Type Mismatch Error:
[error] -- [E057] Type Mismatch Error: /home/apolack/work/projects/(elided)/src/main/scala/(elided)/ProductionRESTAPI.scala:268:23
[error] 268 | )
[error] | ^
[error] |Type argument Any does not conform to upper bound play.api.libs.json.JsValue
[error] |---------------------------------------------------------------------------
[error] | Explanation (enabled by `-explain`)
[error] |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[error] | I tried to show that
[error] | Any
[error] | conforms to
[error] | play.api.libs.json.JsValue
[error] | but the comparison trace ended with `false`:
[error] |
[error] | ==> Any <: play.api.libs.json.JsValue
[error] | ==> Any <: play.api.libs.json.JsValue
[error] | ==> Any <: play.api.libs.json.JsValue
[error] | <== Any <: play.api.libs.json.JsValue = false
[error] | <== Any <: play.api.libs.json.JsValue = false
[error] | <== Any <: play.api.libs.json.JsValue = false
[error] |
[error] | The tests were made under the empty constraint
[error] ---------------------------------------------------------------------------
[error] Explanation
[error] ===========
[error] I tried to show that
[error] Any
[error] conforms to
[error] play.api.libs.json.JsValue
[error] but the comparison trace ended with `false`:
[error]
[error] ==> Any <: play.api.libs.json.JsValue
[error] ==> Any <: play.api.libs.json.JsValue
[error] ==> Any <: play.api.libs.json.JsValue
[error] <== Any <: play.api.libs.json.JsValue = false
[error] <== Any <: play.api.libs.json.JsValue = false
[error] <== Any <: play.api.libs.json.JsValue = false
[error]
[error] The tests were made under the empty constraint
[error] one error found
Thinking perhaps passing the JsArray
as a type argument explicitly to complete
would help I tried that… but either way (with or without the explicit type argument) I still get the same compiler error under 3.1.3, but not under 3.1.2.
Expectation
The code should compile under Scala 3.1.3… or if not, at least consistently not compile under both 3.1.2 and 3.1.3. I wouldn’t expect a minor compiler revision to break backwards compatibility in this way.
Thanks
Thanks for all of the great work on Scala 3. I’m looking forward to the ecosystem further evolving and stabilizing.
Issue Analytics
- State:
- Created a year ago
- Comments:8 (3 by maintainers)
Top GitHub Comments
Pushed a repo that replicates the behavior: https://github.com/ALPSMAC/sample-scala3-compiler-bug/tree/main
If you change the scalaVersion in build.sbt from 3.1.2 to 3.1.3 or 3.2.0-RC3 you can cause the compilation error.
Thanks!
I had a little bit of time just now to play with this… and I haven’t been able to reproduce it in a simpler scenario yet. I do know what does not produce the difference in behavior. Namely this example, complex at it is, does seem to type check and compile correctly:
When I have some more time later I’ll try to circle back around and see if I can’t narrow the scope more… but I’m posting my findings thus-far on the off chance that knowing what is working helps those more qualified than myself in the guts of the Scala compiler narrow the cause.