Skip to content

bump some versions (Scala, MiMa) #275

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Dec 13, 2019
Merged

bump some versions (Scala, MiMa) #275

merged 4 commits into from
Dec 13, 2019

Conversation

SethTisue
Copy link
Member

No description provided.

@SethTisue
Copy link
Member Author

https://travis-ci.org/scala/scala-collection-compat/jobs/623030067

[error] Test BinaryCompaTest.compat failed: java.lang.NoSuchMethodError: 'scala.collection.mutable.HashSet com.typesafe.tools.mima.core.Settings.allSettings()', took 0.213 sec
593

@SethTisue
Copy link
Member Author

SethTisue commented Dec 10, 2019

now it fails with

[error] Test BinaryCompaTest.compat failed: expected:<List()> but was:<List(IncompatibleSignatureProblem(def id: (Lscala.collection.Iterable;Lscala.collection.generic.CanBuildFrom;)Lscala.collection.Iterable;,def id: (Lscala.collection.Iterable;Lscala.collection.generic.CanBuildFrom;)Lscala.collection.Iterable;), IncompatibleSignatureProblem(def id: (Lscala.collection.Iterable;Lscala.collection.generic.CanBuildFrom;)Lscala.collection.Iterable;,def id: (Lscala.collection.Iterable;Lscala.collection.generic.CanBuildFrom;)Lscala.collection.Iterable;))>

it is past my bedtime, I will resume tomorrow

@SethTisue SethTisue changed the title bump Scala versions everywhere (2.12.0, 2.13.1) bump Scala versions everywhere (2.12.10, 2.13.1) Dec 11, 2019
@SethTisue SethTisue changed the title bump Scala versions everywhere (2.12.10, 2.13.1) bump some versions (Scala, MiMa) Dec 11, 2019
@SethTisue
Copy link
Member Author

well, this has been confusing.

if we go from Scala 2.12.8 to 2.12.10, [error] Test BinaryCompaTest.compat failed: java.lang.NoSuchMethodError: com.typesafe.tools.mima.core.Settings.allSettings()Lscala/collection/mutable/HashSet;, took 0.169 sec

that error can be made to go away with:

-    libraryDependencies += "com.typesafe" %% "mima-reporter" % "0.3.0" % Test,
+    libraryDependencies += "com.typesafe" %% "mima-core" % "0.6.1" % Test,

and being on the latest MiMa is in any case desirable.

but if we do that we get

[error] Test BinaryCompaTest.compat failed: expected:<List()> but was:<List(IncompatibleSignatureProblem(def id: (Lscala.collection.Iterable;Lscala.collection.generic.CanBuildFrom;)Lscala.collection.Iterable;,def id: (Lscala.collection.Iterable;Lscala.collection.generic.CanBuildFrom;)Lscala.collection.Iterable;), IncompatibleSignatureProblem(def id: (Lscala.collection.Iterable;Lscala.collection.generic.CanBuildFrom;)Lscala.collection.Iterable;,def id: (Lscala.collection.Iterable;Lscala.collection.generic.CanBuildFrom;)Lscala.collection.Iterable;))>, took 0.237 sec

this is the check introduced by @smarter in #115

over in README.md at https://github.com/lightbend/mima , @dwijnand writes:

The IncompatibleSignature check compares the Signature, which includes the full signature including generic parameters. This can catch real incompatibilities, but also sometimes triggers for a change in generics that would not in fact cause problems at run time. To opt-out of this check you can filter them...

@dwijnand @julienrf do y'all have an opinion on whether this particular IncompatibleSignatureProblem is spurious or real?

@julienrf
Copy link
Contributor

It seems spurious to me.

@dwijnand
Copy link
Member

I added change so we can get more info, which yielded:

[error] Test BinaryCompaTest.compat failed: The following 2 problems were reported but not expected:
[error]   - static method id(scala.collection.Iterable,scala.collection.generic.CanBuildFrom)scala.collection.Iterable in class org.example.Lib has a different signature in new version, where it is <A:Ljava/lang/Object;C::Lscala/collection/Iterable<Ljava/lang/Object;>;>(TC;Lscala/collection/generic/CanBuildFrom<Lscala/runtime/Nothing$;TA;TC;>;)TC; rather than <A:Ljava/lang/Object;C::Lscala/collection/Iterable<Ljava/lang/Object;>;>(TC;Lscala/collection/generic/CanBuildFrom<TC;TA;TC;>;)TC;
[error]   - method id(scala.collection.Iterable,scala.collection.generic.CanBuildFrom)scala.collection.Iterable in object org.example.Lib has a different signature in new version, where it is <A:Ljava/lang/Object;C::Lscala/collection/Iterable<Ljava/lang/Object;>;>(TC;Lscala/collection/generic/CanBuildFrom<Lscala/runtime/Nothing$;TA;TC;>;)TC; rather than <A:Ljava/lang/Object;C::Lscala/collection/Iterable<Ljava/lang/Object;>;>(TC;Lscala/collection/generic/CanBuildFrom<TC;TA;TC;>;)TC;

broken down:

signature change in static and non-static method "id" of class "Lib":
old: <A:Ljava/lang/Object;C::Lscala/collection/Iterable<Ljava/lang/Object;>;>(TC;Lscala/collection/generic/CanBuildFrom<TC;TA;TC;>;)TC;
new: <A:Ljava/lang/Object;C::Lscala/collection/Iterable<Ljava/lang/Object;>;>(TC;Lscala/collection/generic/CanBuildFrom<Lscala/runtime/Nothing$;TA;TC;>;)TC; 

In summary: the first type parameter of the CanBuildFrom went from a specific TC to Nothing.

That type parameter is -From: "the type of the underlying collection that requests a builder to be created". So, the library went from accepting CBF that takes TCs to a CBF that accepts Nothing. My assumption is that it never needed to build "from" TC because it only uses the def apply(): Builder[Elem, To] method, not the def apply(from: From): Builder[Elem, To] of CBF.

So I too believe the signature change can be ignored.

@SethTisue SethTisue self-assigned this Dec 12, 2019
@SethTisue
Copy link
Member Author

SethTisue commented Dec 12, 2019

okay, thanks, I'll take care of it, but after the 2.1.3 release

@SethTisue SethTisue merged commit c80cfe4 into scala:master Dec 13, 2019
@SethTisue SethTisue deleted the version-bumps branch December 13, 2019 21:24
val unexpectedDescriptions =
allProblems.iterator
.map(_.description("new"))
.map{x => println(x); x}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably should drop this.

.toList
val msg =
unexpectedDescriptions.mkString(
s"The following ${allProblems.size} problems were reported but not expected:\n - ", "\n - ", "\n")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unexpectedDescriptions.size

.map(_.description("new"))
.map{x => println(x); x}
.filterNot(_ == "static method id(scala.collection.Iterable,scala.collection.generic.CanBuildFrom)scala.collection.Iterable in class org.example.Lib has a different signature in new version, where it is <A:Ljava/lang/Object;C::Lscala/collection/Iterable<Ljava/lang/Object;>;>(TC;Lscala/collection/generic/CanBuildFrom<Lscala/runtime/Nothing$;TA;TC;>;)TC; rather than <A:Ljava/lang/Object;C::Lscala/collection/Iterable<Ljava/lang/Object;>;>(TC;Lscala/collection/generic/CanBuildFrom<TC;TA;TC;>;)TC;")
.filterNot(_ == "method id(scala.collection.Iterable,scala.collection.generic.CanBuildFrom)scala.collection.Iterable in object org.example.Lib has a different signature in new version, where it is <A:Ljava/lang/Object;C::Lscala/collection/Iterable<Ljava/lang/Object;>;>(TC;Lscala/collection/generic/CanBuildFrom<Lscala/runtime/Nothing$;TA;TC;>;)TC; rather than <A:Ljava/lang/Object;C::Lscala/collection/Iterable<Ljava/lang/Object;>;>(TC;Lscala/collection/generic/CanBuildFrom<TC;TA;TC;>;)TC;")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SethTisue
Copy link
Member Author

#284 adopts Dale's suggestions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants