Skip to content
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

Changes to compile with Scala 2.13.0-M4 #411

Closed
wants to merge 10 commits into from
Closed

Conversation

lrytz
Copy link
Contributor

@lrytz lrytz commented May 15, 2018

No description provided.

@lrytz
Copy link
Contributor Author

lrytz commented May 15, 2018

sbt ++2.13.0-M4 jvm/test passes.

This doesn't cross-compile with 2.11/2.12 and 2.13 though. If you want to keep cross-compiling a single branch, we can use version-dependent source directories. We can minimize the amount of code in those directories.

@lrytz
Copy link
Contributor Author

lrytz commented May 19, 2018

Yay, this is green now! @ashawley raises concerns about binary compatibility over at scala/scala-xml#222. Have to check in detail and see if we can keep doing 1.14.x, or need to move to 1.15.

lrytz added 6 commits May 23, 2018 15:00
This is a no-op for 2.13, as Traversable is a (deprecated) alias for
Iterable. For 2.10-2.12, this ensures that the signatures don't change
due to cross-building with 2.13.
@lrytz
Copy link
Contributor Author

lrytz commented May 23, 2018

I went through all the changes again with focus on binary and source compatibility. It looks to me like we can continue to release 0.14.x builds for 2.10-2.12 after merging this PR, they should be backwards compatible.

I think this PR is ready now. Review by @rickynils :-)

@lrytz lrytz changed the title [WIP] Changes to compile with Scala 2.13.0-M4 Changes to compile with Scala 2.13.0-M4 May 24, 2018
Copy link

@raboof raboof left a comment

Choose a reason for hiding this comment

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

(not qualified to review most of the changes, but had a quick look and a couple of things popped out)

@@ -46,3 +49,5 @@ matrix:
exclude:
- scala: 2.10.7
env: PLATFORM=js SBT_PARALLEL=true WORKERS=1 DEPLOY=true SCALAJS_VERSION=1.0.0-M3
- scala: 2.13.0-M4
env: PLATFORM=js SBT_PARALLEL=true WORKERS=1 DEPLOY=true SCALAJS_VERSION=1.0.0-M3
Copy link

Choose a reason for hiding this comment

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

This exclude doesn't make sense like this anymore since the change from scala 2.13.0-M3 to 2.13.0-M4, right?

Copy link
Contributor Author

@lrytz lrytz May 25, 2018

Choose a reason for hiding this comment

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

Not sure I understand.. This exclude skips building with Scala.js 1.0.0-M3 on Scala 2.13.0-M4, because there's no such Scala.js release yet.

Copy link

Choose a reason for hiding this comment

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

A got it 👍

@@ -78,7 +91,11 @@ lazy val sharedSettings = MimaSettings.settings ++ scalaVersionSettings ++ Seq(
// don't use fatal warnings in tests
scalacOptions in Test ~= (_ filterNot (_ == "-Xfatal-warnings")),

mimaPreviousArtifacts := Set("org.scalacheck" %% "scalacheck" % "1.14.0"),
mimaPreviousArtifacts := {
// TODO: re-enable MiMa for 2.13.0-M4 once there is a release out
Copy link

Choose a reason for hiding this comment

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

Maybe add a ticket to keep track of this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a comment #410 (comment)

@@ -765,8 +766,8 @@ object Prop {
/*
* Returns the first failed result in Left or success in Right.
*/
def getFirstFailure(xs: Stream[T]): Either[(T,Result),(T,Result)] = {
assert(!xs.isEmpty, "Stream cannot be empty")
def getFirstFailure(xs: LazyList[T]): Either[(T,Result),(T,Result)] = {
Copy link

Choose a reason for hiding this comment

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

Is this binary compatible?

Copy link
Contributor Author

@lrytz lrytz May 25, 2018

Choose a reason for hiding this comment

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

Copy link

Choose a reason for hiding this comment

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

👍


sealed abstract class Shrink[T] extends Serializable {
def shrink(x: T): Stream[T]
def shrink(x: T): LazyList[T]
Copy link
Contributor

Choose a reason for hiding this comment

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

So the signature for Shrink changes here, so existing 1.14.0 tests (or libraries) that defined shrinkers would no longer compile.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Here's an example shrinker:

object CustomShrink {
  implicit val dumbIntShrinker: Shrink[Int] = Shrink {
    case _ => Stream.empty
  }
}

Publishing this branch as 1.14.0-543b405, the example compiles on 2.10, 2.11, and 2.12, but for 2.13.0-M4:

[error] src/main/scala/CustomShrink.scala:5:22: polymorphic expression cannot be instantiated to expected type;
[error]  found   : [A]scala.collection.immutable.Stream[A]
[error]  required: LazyList[Int]
[error]     case _ => Stream.empty

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for pointing this out.

Do poeple actually write shrinkers "ahead of time", at the same time when writing Arbitrary instances, and put them into the code base?

We could make the LazyList aliases public on 2.10-2.12, then poeople could use these. But I think this gets even more confusing. Already having the LazyList alias in the signatures on 2.10-2.12 is a bit problematic.

We could keep using Stream, but that would lead to deprecation warnings on 2.13.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, writing one's own Shrink is documented.

Copy link
Contributor

@ashawley ashawley May 31, 2018

Choose a reason for hiding this comment

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

Aren't warnings being emitted for Traversable?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are a number of uses of Traversable in the API, but I think they should not lead to deprecation warnings for the users. In 2.13, Traversable is a (deprecated) alias to Iterable.

So let's say scalacheck defines a method

scala> def foo: Traversable[Int] = List(1,2,3)
                ^
       warning: type Traversable in package scala is deprecated (since 2.13.0): Use Iterable instead of Traversable
foo: Traversable[Int]

When compiling scalacheck on 2.13, this will give a deprecation warning. But for users it won't:

scala> foo
res0: Traversable[Int] = List(1, 2, 3)

scala> foo.map(_ + 1)
res1: Iterable[Int] = List(2, 3, 4)

scala> foo: Iterable[Int]
res2: Iterable[Int] = List(1, 2, 3)

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, ok. I see the distinction. Thanks for explaining.

For now, preserve Stream in Shrink, and then migrate to LazyList in 1.15.0?

@lrytz
Copy link
Contributor Author

lrytz commented Jun 6, 2018

Pushed a change by @ashawley to go back to using Stream when defining Shrinkers. We can move to LazyList in a scalacheck 1.15

With `n == 0` the test effectively calls `Gen.frequency()`, which
throws `IllegalArgumentException: no items with positive weights`.
@ashawley
Copy link
Contributor

ashawley commented Jun 7, 2018

I'd say this is good to publish for 2.13.0-M4.

Since there are long-term implications with 2.13 that require further consideration going forward (like, "What should go in 1.15.0?"), maybe hold off on the merge?

@rickynils
Copy link
Contributor

@ashawley I'v rebased and merged this to the 1.14.0_sonatype branch and published the build. I'm not sure I see why we should hold off the merge to master, though?

@ashawley
Copy link
Contributor

This PR currently represents the conservative set of changes for making a 1.14.0 release for 2.13. Publishing was important for getting a ScalaCheck release out for the 2.13.0-M4 milestone . That's all that's been really reviewed, though.

What wasn't probably reviewed, was the first half of these commits of this PR containing the original re-implementation of ScalaCheck's use of collections for 2.13. Those modifications have compatibility breaking changes, but they would seem like the better base with which to move forward on.

@lrytz
Copy link
Contributor Author

lrytz commented Jun 11, 2018

In the current form this PR doesn't have breaking changes, those parts of the earlier commits are reverted in later commits. I can squash things if that's desired.

Changes such as moving to use LazyList instead of Stream in shrinkers on 2.13 can be done in a 1.15 release.

case 10 => Seq("-Xfatal-warnings", "-Xlint")
case 11 => Seq("-Xfatal-warnings", "-Xlint", "-Ywarn-infer-any", "-Ywarn-unused-import")
case 12 => "-Xfatal-warnings" +: modern
case 13 => modern
Copy link

Choose a reason for hiding this comment

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

does it mean 2.13 enables -Xfatal-warnings by default?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No :-) this disables fatal warnings on 2.13 because there are some deprecation warnings due to cross-building (usage of Stream)

Copy link

@jozic jozic Jul 18, 2018

Choose a reason for hiding this comment

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

got it, one alternative way could be to add silencer for that particular place instead of disabling it in general, but I guess it's not a big deal, as it's enabled for the rest of versions

@mcanlas
Copy link

mcanlas commented Aug 29, 2018

Are there any blockers for this PR?

Scala 2.13.0-M5 is out now.

@ashawley
Copy link
Contributor

M5 is out, but I'm not sure it's minted, yet.

For the record, this was merged to the 1.14.0_sonatype branch in #410, but just not master, yet. Since development isn't active, this is effectively a longer-running branch/PR for 2.13.

@lrytz
Copy link
Contributor Author

lrytz commented Oct 3, 2018

It would be great to move 2.13 cross-building forward. As mentioned in a recent announcement, one goal of the postponed RC1 is to make sure we have time to get the OSS ecosystem up and running. Scalacheck is obviously very important as it's one of the roots.

I'll update this PR to M5.

@ashawley
Copy link
Contributor

ashawley commented Oct 3, 2018

Seth got ScalaCheck most of the way there for 2.13.0-M5, see #427.

@rickynils
Copy link
Contributor

I have merged 1.14.0_sonatype to master, so this PR is now effectively merged to master too. Closing this.

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.

6 participants