Suppress Compiler Warnings (kernel)

[satorg]

This is an ongoing effort for suppressing compiler warnings that keep plaguing the project.

Suppresses the warnings in kernel* modules for all Scala versions.

[johnynek]

Thanks for the cleanup!

[satorg]

Seems there can be some issues with @nowarn("cat=unused-params") while upgrading to Scala 3.1.x versions (see discussion in http4s/http4s#6300 (review))

Perhaps, it may make sense to make use of val _ = someUnusedParam pattern in this PR as well...

[armanbilge]

The other option is we continue to keep fatal warnings disabled on Scala 3 😕

[satorg]

I don't think it's going to help... Scala 3.0 silently ignores unused parameters along with any kind of @nowarn annotation. Whereas Scala 3.1 will be failing on @nowarn("cat=unused-params") anyway regardless of the fatal warnings option.

[satorg]

Added more thoughts on how to overcome the compatibility issue: http4s/http4s#6300 (comment)

I'm considering to take that approach, but sincerely open to discussion :)

[satorg]

Hi @armanbilge. I realized that warnings for Scala 2.12 for unused .. well, everything .. were suppressed entirely in sbt-typelevel:

      val warnings212 = Seq("-Xlint:-unused,_")

So.. I wonder – was it made intentionally and can we assume now that the warnings regarding unused stuff will never show up for Scala 2.12?

[armanbilge]

Oh, interesting 😅 sbt-typelevel inherited those settings from sbt-spiewak which derived them from sbt-tpolecat. So probably intentional. In any case, it's what all the builds are using now, and many were using before too, so it probably works just fine.

[satorg]

That's fine... Just curious though – is it just because 2.12 is sunsetting and no one likes messing around with it? Or is it something more special...

[armanbilge]

Here's the original commit. djspiewak/sbt-spiewak@95a45d0

[satorg]

Oh that's interesting... It was introduced even before Scala 2.13.0 was released. Seems like Daniel just didn't like that sort of warnings at all 😄

[armanbilge]

@satorg I'm sorry, I haven't forgotten about this PR.

The truth is I've been hesitating, because I'm weighing what I think are fairly straightforward changes here with the fact it requires putting Cats on an sbt-typelevel milestone. There are some non-trivial changes coming to sbt-typelevel and I'd rather not have to worry about accidentally breaking the Cats build (the fact that Cats Effect is stuck on the milestone is stress enough!).

• upgrade to laika 0.19
• rework to use scalac-options
• replacing the sonatype client

In theory we could backport your scalac warning fixes to sbt-tl 0.4.x. However if you're eager to work on that what I'd actually love help with is integrating with the scalac-options library for 0.5.x.

[satorg]

@armanbilge yeah, no worries. I also feel a bit hesitant about pushing this work out. Because before continuing it would be better to stabilize the build system itself.

However if you're eager to work on that what I'd actually love help with is integrating with the scalac-options library for 0.5.x.

Ah ok, I think I can help with that. Thanks.

[satorg]

Converted to "Draft" to put on hold until work on scalac compiler options is stabilized.

[som-snytt]

I arrived via good first issues [sic]. I know about options on Scala 2 and somewhat on Scala 3, and I generally endorse using -Xlint, also it's not "fatal warnings" but -Werror which I pronounce "worry". I'm interested in learning how cats can be supported by the options cross-compilation, but maybe you're already working out a solution.

[armanbilge]

@satorg @som-snytt if there are folks motivated to work on this, I'm thinking we should just update Cats to the sbt-typelevel milestone to unblock this work.

In #4187 (comment) I was worried about too many changes happening in sbt-typelevel, but besides the Laika upgrade the other objectives have been dormant, and I don't think that they are going to land in 0.5 after all. That's okay 🙁

[satorg]

@armanbilge @som-snytt if I remember correctly, there are quite a few warnings that are handled differently in different Scala versions (i.e. 2.12, 2.13, 3). And that is what we tried to address with scalac-compat. I think, it could come handy for Cats too. Are we fine with bringing it in there?

[armanbilge]

Yes, scalac-compat has been wonderful! We are using it in Cats Effect now as well.

[satorg]

scala/scala3#20536 (for reference)

[satorg]

Superseded by #4614.