Updating to scala 2.13-M4 #2335
Conversation
|
Update: I managed to get all dependencies to 2.13-M4 (had to publishLocal sbt-scoverage but I think they'll release soon). |
|
@kailuowang Have you tried using https://github.com/scala/scala-collection-compat? |
|
@mpilquist I haven't, thanks for the pointer. |
|
I've replied at #2267 |
|
@SethTisue do you happen to have a quick example project of building 2.13 and 2.12 specific source? I've done similar thing before but it was a bit hacky, wonder if sbt 1.1 enabled some new techniques. |
if you have if you want something custom like "use these sources for 2.11 and 2.12, and these other sources for 2.13 and above", then you need something like: that kind of thing, whatever exact logic and naming you want |
|
would an infile implementation be of use, eg: if so, I think we could do something along the lines as we do in catalysts.platform but by scala version, not platform |
|
Thanks @SethTisue |
|
FWIW, for cross projects (build scalajs too), I ended up using the following settings to support scala-version-specific source directories Compile / unmanagedSourceDirectories ++= {
val bd = baseDirectory.value
(CrossVersion.partialVersion(scalaVersion.value) match {
case Some((2, y)) if y <= 12 =>
CrossType.Pure.sharedSrcDir(bd, "main").toList map (f => file(f.getPath + "-2.12-"))
case _ => Nil
})
}, |
|
I'll push what i did in catalysts soon/later. We can can compare..... |
|
I might found a change in implicit priority.
Note that the two conflicting instances implicit def catsDataMonadForOptionT[F[_]](implicit F0: Monad[F]): Monad[OptionT[F, ?]]and implicit def catsDataMonadErrorMonadForOptionT[F[_]](implicit F0: Monad[F]): MonadError[OptionT[F, ?], Unit]The return type of the second one is a subtype of the first one. |
…string representation
|
In the 2.13.0-M3 build, implicit resolutions was a big factor in the build, eg see https://travis-ci.org/typelevel/cats/jobs/355615303 So might be worth raising an issue, even if no longer an issue here? |
|
Alot of the build changes are extremely similar to the ones I've done in sbt-catalysts, but not pushed yet. I wonder if now might be a convenient time to hook cats up with sbt-catalysts? Not a full migration, just things like scalac-options, helper methods etc.if you push what you have. I can have a look. Your call |
|
Another issue is that the |
Sounds a good idea. Let me finish up this update to get a full sense of what can be shared, then I'll push something to sbt-catalysts. I think for now it's not a bad idea to just copy paste between projects. |
|
A new implicit resolution change that might be a blocker for us.
Unlike the previous ambiguous error, there is no redundancy in it. implicit def catsDataSemigroupForOptionT[F[_], A](implicit F0: Semigroup[F[Option[A]]]): Semigroup[OptionT[F, A]]and implicit def catsDataMonoidForOptionT[F[_], A](implicit F0: Monoid[F[Option[A]]]): Monoid[OptionT[F, A]] Since they are defined in different classes in the inheritance hierarchy, they should NOT have caused conflicts. It doesn't appear that this is happening to all implicit definitions organized through class inheritance, but I am seeing multiple of such errors for multiple data structures, e.g. |
|
so the problem is probably the wrong order of instances in our priority hierarchy.
I'll start addressing these tomorrow. |
|
Found a problem with the ParallelInstance for IorT |
|
By adding a dummy type refinement to the instance in the subclass you should be able to make it more specific, e.g.: class Foo[A, B]
class FooLow1 {
implicit def one[T]: Foo[T, T] = ???
}
object Foo extends FooLow1 {
implicit def two[T, S]: Foo[T, S] { type Dummy } = ???
def test[X] = {
implicitly[Foo[X, X]] // Picks "two"
}
}If I understand your specific case exactly this would be: implicit def catsDataParallelForIorTWithParallelEffect[M[_], F[_], E]
(implicit P: Parallel[M, F], E: Semigroup[E]): Parallel[IorT[M, E, ?], IorT[F, E, ?]] { type Dummy } = new Parallel[IorT[M, E, ?], IorT[F, E, ?]]
{
type Dummy
// Rest as before
// ...
} |
|
the discussion on this has been spread out around different venues... the latest seems to be that @smarter's suggestion (also made at https://gitter.im/scala/contributors?at=5b5a437f3396495b333e6102) seems promising, @kailuowang will try it |
|
@smarter that worked. Thanks! |
|
Extra type parameter with equality constraint might work if we define our own higher-kinded type equality: sealed trait HkEq[F[_], G[_]] {
def apply[A](fa: F[A]): G[A]
}
object HkEq {
implicit def refl[F[_]]: HkEq[F, F] = new HkEq[F, F] {
def apply[A](fa: F[A]): F[A] = fa
}
}But of course that would change the type signature. |
|
update, we still have a bunch of back-breaking deprecations. I am going to simply ignore them for now, i.e. disable --deprecation and --fatal-warning on 2.13. |
|
Update: all modules are updated to 2.13. The only thing blocking us from releasing cats on 2.13-M4 is scoverage. Given the complexity of scoverage update (they are considering re-write coverage report file format from xml to something else) I suggest that we just disable coverage on 2.13 for now |
|
👍 |
| mimaBinaryIssueFilters ++= { | ||
| import com.typesafe.tools.mima.core._ | ||
| import com.typesafe.tools.mima.core.ProblemFilters._ | ||
| //Only sealed abstract classes that provide implicit instances to companion objects are allowed here, since they don't affect usage outside of the file. |
There was a problem hiding this comment.
This would be a good option to add to mima: ignore changes when the or trait is sealed.
There was a problem hiding this comment.
I created a placeholder issue at the mima repo, but it needs fleshing out to become actionable. lightbend-labs/mima#237
Codecov Report
@@ Coverage Diff @@
## 1.2.x #2335 +/- ##
==========================================
- Coverage 95.09% 95.01% -0.09%
==========================================
Files 345 349 +4
Lines 5991 5993 +2
Branches 219 225 +6
==========================================
- Hits 5697 5694 -3
- Misses 294 299 +5
Continue to review full report at Codecov.
|
|
Update: it's by and large working. Personally, I think it's ready for a release of 1.2 on 2.13-M4
Please vote on this comment if you are for (👍 ) or against (👎 ) releasing 1.2.0 on 2.13 in the current status. |
|
|
|
You've added issues for the flaky bits, no doubt consumer projects will find their own itches with M4, but only when this is released. So my vote goes to ship it ASAP 👍 |
Will fix #2267
The progress so far is probably less 10%.Done:
All dependencies are updated (except sbt-scoverage which is locally publish on my machine)
Identified work remaining:
sbt-scoverage 2.13-M4 release, blocking issuetemporarily disable scoverage on 2.13eitherupdate export-hook to 2.13-M4or remove it from alleycats.find a way to cross-compile deprecated collection APItemporary remove the deprecation warning for 2.13Update: it's by and large working. Personally, I think it's ready for a release of 1.2 on 2.13-M4
I created an issue for the steps I temporarily skipped in build on 2.13-M4 #2347 namely, the following are disabled on 2.13 build
scala.collections. I think the tooling/documentation on supporting cross compiling against collection API could get a bit better.