Scala 2.12.0-M2, lambdas, and MiMa

[Sébastien Doeraene]

Hi,

It seems Scala 2.12.0-M2, lambdas, and MiMa do not like each other.

We recently upgraded Scala.js to run our CI, and our MiMa backward binary compatibility tests, with 2.12.0-M2 (in addition to 2.10 and 2.11). And now I get more false positives than before on simple intra-method changes.

For example, adding a few new cases in a method in Transformers.scala and Traversers.scala:
https://github.com/sjrd/scala-js/commit/6995c0f9e737e0929a21e6b2f9480aea5931688a#diff-afa5a823ae96054a3d159c937c300264

I get the following MiMa errors:
https://gist.github.com/sjrd/7050c82578a31f29ef88#file-ir-bin-incompats-txt

It gets much worse in the same commit on the `tools` subproject, with 252 (!) spurious incompatibility errors:
https://gist.github.com/sjrd/7050c82578a31f29ef88#file-tools-bin-incompats-txt

These do not happen when checking the 2.10 and 2.11 artifacts, nor did they (I think) with 2.12.0-M1 artifacts.

These errors are obviously related to anonymous functions: adding or removing or changing the order of anonymous functions within a method now causes errors.

This is so freaking noisy that I will have to disable MiMa on 2.12.0-M2 artifacts.

(I am aware we can configure MiMa to ignore known spurious errors. We do this. But here there are just too many for me to track.)

Can we please do something about it?

Either fix the compiler so that changes in lambdas do not cause such binary changes, or fix MiMa so that anonfun-related discrepancies are not regarded as errors?

If we don't do anything, MiMa will become useless on 2.12 artifacts because it's much too noisy. And I suspect not only on our codebase.

Cheers,

Sébastien

[Adriaan Moors]

Hi Sébastien,

Thanks for raising the issue, I hadn't thought of the need to update MiMa yet.

We'll try to find some time to do that before we release 2.12.0-M3, but until then we're pretty busy with implementing even more things that will require MiMa updates (traits == interfaces + default methods) :-)

Would be great if someone else could look at this in the mean time -- we'd be more than happy to advise!

cheers

adriaan

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sébastien Doeraene]

Hi Adriaan,

Thanks for your answer. So, according to you, the "culprit" is MiMa and we can fix it? If that's the case I'll file an issue against MiMa, at least. And maybe I'll try and tackle the issue.

Cheers,

Sébastien

[Seth Tisue]

jinx! I opened https://github.com/typesafehub/migration-manager/issues/78

[Adriaan Moors]

Aha! I didn't catch your mention of the lack of stability of naming the lifted lambda body methods. Sorry.

Sounds like this is something we should fix on the compiler side, then.

[Sébastien Doeraene]

Hi,

Thanks Seth :-)

Adriaan: not necessarily. Suppose the appropriate fix in MiMa is to simply ignore anything happening to methods with $anonfun$ in their name. Then stability doesn't matter.

In the opposite direction, suppose the encoding with MethodHandles and InvokeDynamic makes it so that the $anonfun$ methods can be private at the bytecode level, then there is nothing to change in MiMa.

Sébastien

--

[Kenji Yoshida]

I just reported another issue https://github.com/typesafehub/migration-manager/issues/114