Compiler error on Eff code compiled with 2.12

[benhutchison]

Scastie 1: Uses the Scala 2.12 version of Eff library under Scala 2.12. Compiles OK
https://scastie.scala-lang.org/aINnRnZOTBas6SrzWRBmfQ

Scastie 2: Uses the Scala 2.12 version of Eff library under Dotty. Doesn't compile
https://scastie.scala-lang.org/vTzj2G33SEqO1WtRBUo8oA

The sample code runReader makes use of implicits to compute the output type, and it seems that the semantics of implicit resolution varies in some way between Dotty and Scala 2.12, resulting in different behavior.

[OlivierBlanvillain]

Might be working as intended, see changed-features/implicit-resolution.md

I think there is higher chance of having someone looking into this if the issue comes with a minimized example.

[benhutchison]

On further investigation and some advice from Eric Torreborre, I don't think the problem is implicit resolution. It has actually resolved the correct implicit.

Rather, I wonder if it may be related to how Dotty resolves the equality of two types...

In the Scastie below, Ive manually invoked the correct implicit with the correct type params. It still fails, but the error message is revealing. There's a lot going on in the types, type-lambdas, aliases and the Aux pattern, but to my reading the two types do look equal (Reader is Kleisli). But the compiler doesnt agree:

Found:    org.atnos.eff.Member.Aux[[X] => cats.data.Kleisli[cats.Id, String, X], 
  org.atnos.eff.Fx1[[X] => cats.data.Kleisli[cats.Id, String, X]]
, org.atnos.eff.NoFx]
Required: org.atnos.eff.Member'[[β$0$] => cats.data.Kleisli[[A] => A, String, β$0$], 
  org.atnos.eff.Fx1[[X] => cats.data.Kleisli[cats.Id, String, X]]
]

where:    Member  is a object in package eff
          Member' is a trait in package eff

https://scastie.scala-lang.org/m05H3wCqTzqkW4wdgTB5wA

[OlivierBlanvillain]

String(g) is g.type, we need to fix that in the pretty printer...

[benhutchison]

Another experiment: Here's a related example, but with no compiled Eff binaries, and the stripped down, relevant parts of Eff moved into the Scastie example.

https://scastie.scala-lang.org/osccD4TmQEGfCnvMR63r9g

This compiles OK! Whereas when the same code is loaded from an Eff binary compiled with Scala 2.12, it gets the type error in the previous comment above.

So it seems the Dotty compiler can resolve the code when it compiles it directly with Dotty. But when it reconstructs the types from the 2.12 binary file using withDottyCompat, something is a little different and the compiler can't see the Found type == the Expected type.

[smarter]

Running the code from #6484 (comment) with -explain-types to get the compiler to tell me why it thinks these types are not equal, I see:

   |                  ==> cats.Id <:< [A] => A
   |                    ==> cats.Id <:< [A] => A recur
   |                      ==> [A] => A <:< [A] => A recur
   |                      <== [A] => A <:< [A] => A recur  = false
   |                    <== cats.Id <:< [A] => A recur  = false
   |                  <== cats.Id <:< [A] => A   = false

So something weird is definitely going on. Further debugging reveals that one of the [A] => A is an HKTypeLambda (used to represent type lambdas) and the other one is a PolyType (used to represent polymorphic methods). So we're confusing the two somehow when unpickling symbols from Scala 2, and this piece of code looks suspiciously related: https://github.com/lampepfl/dotty/blob/cdd844f3794910410482ffb2da449b86623e5248/compiler/src/dotty/tools/dotc/core/unpickleScala2/Scala2Unpickler.scala#L49

[benhutchison]

Thanks for the rapid diagnosis and fix @smarter, much appreciated!

It has certainly helped build my trust in the Dotty migration to see these sort of early stage compatibility bugs vigorously investigated & resolved.

[benhutchison]

I notice these commits went to dotty-staging, but they didnt seem to publish a binary that I could retest with... is there a way I can test the fix in my own project?
http://dotty-ci.epfl.ch/lampepfl/dotty/12728

[smarter]

dotty-staging is just the remote we use to push branches for each PR to facilitate collaboration (only one remote that everyone can push to). In this case the PR is at #6494.

is there a way I can test the fix in my own project?

We don't (yet) publish binaries for every open PR. But since #6494 has been merged it will be part of the next nightly build. So tomorrow you'll be able to test it by setting scalaVersion to the latest nightly version from https://repo1.maven.org/maven2/ch/epfl/lamp/dotty_0.15/ (or alternatively by setting scalaVersion := dottyLatestNightlyBuild.get to automatically fetch the latest one).