Signature checks fail using value classes & upgrading to 2.12.9+ or 2.13.1+

If you publish this code with Scala 2.12.8:

class Foo(val value: String) extends AnyVal

case class Bar(foo: Foo)

And then change the Scala version to 2.12.9 (or 10) and run sbt mimaReportBinaryIssues, you’ll get these errors:

[error]  * method unapply(Bar)scala.Option in object Bar has a different signature in current version, where it is (LBar;)Lscala/Option<LFoo;>; rather than (LBar;)Lscala/Option<Ljava/lang/String;>;
[error]    filter with: ProblemFilters.exclude[IncompatibleSignatureProblem]("Bar.unapply")
[error]  * static method unapply(Bar)scala.Option in class Bar has a different signature in current version, where it is (LBar;)Lscala/Option<LFoo;>; rather than (LBar;)Lscala/Option<Ljava/lang/String;>;
[error]    filter with: ProblemFilters.exclude[IncompatibleSignatureProblem]("Bar.unapply")
[error]  * static method andThen(scala.Function1)scala.Function1 in class Bar has a different signature in current version, where it is <A:Ljava/lang/Object;>(Lscala/Function1<LBar;TA;>;)Lscala/Function1<LFoo;TA;>; rather than <A:Ljava/lang/Object;>(Lscala/Function1<LBar;TA;>;)Lscala/Function1<Ljava/lang/String;TA;>;
[error]    filter with: ProblemFilters.exclude[IncompatibleSignatureProblem]("Bar.andThen")
[error]  * static method compose(scala.Function1)scala.Function1 in class Bar has a different signature in current version, where it is <A:Ljava/lang/Object;>(Lscala/Function1<TA;LFoo;>;)Lscala/Function1<TA;LBar;>; rather than <A:Ljava/lang/Object;>(Lscala/Function1<TA;Ljava/lang/String;>;)Lscala/Function1<TA;LBar;>;
[error]    filter with: ProblemFilters.exclude[IncompatibleSignatureProblem]("Bar.compose")
[error] java.lang.RuntimeException: unapply_test: Binary compatibility check failed!

The issue seems to be the value class in the synthetic method signatures.

[dwijnand]

The fix was in the compiler (https://github.com/scala/scala/pull/8127). My understanding is that scalap shows you what’s in ScalaSignature rather than the (erased) method descriptor or the (Java) (generic) signature, the latter of which is what Harrison fixed ~and MiMa analyses~ (edit: MiMa analyses the descriptor - thanks Arnout).

[raboof]

@diesalbla no, I think it can be broken down as follows:

• 5.1.0 was compiled with scala <2.12.9, which produced a (wrong) Eq<String> signature for a method that actually compared CipherText objects
• Anyone who would have called that method and, based on that generic as seen by javac (scalac is separate), expected to be usable with Strings, would have encountered errors (because it in fact works with CipherText objects
• 5.2.0 is compiled with scala >=2.12.9, which produces a (correct) Eq<CipherText> signature
• MiMa reports that if there was anyone who relied on the Eq<String> signature before, they would be in trouble now because it changed to Eq<CipherText>.
• But there is no-one that relied on that signature, because it was wrong and wouldn’t have worked in the first place