Add support for re-introduced warnings in scala 3.3.0

[amumurst]

This PR prepares the plugin for the official scala 3.3.0 release (it is tagged, just not released quite yet https://github.com/lampepfl/dotty/releases/tag/3.3.0). It adds back all the warnings for unused and discarded values that is re-added in this release.

[amumurst]

Note that this adds the specific unused:X flags and not the unused:all. I have no strong opinion on which is better for the plugin. Adding all would mean that if another is added in 3.3.1, users of the plugin would have it automatically added when upgrading the scala version in their project.

[KamilPostrozny]

@amumurst personally I would go with unused:all for reasons you have mentioned. Note that for now all scala versions that support any unused option also support the rest of them. So for now it doesn't make sense - at least to me - to separate them.

[Daenyth]

If we use all, how easy is it for plugin users to disable one specific lint? Say you want to disable "unused:import" for local dev for example

[froth]

This looks great, I would love to use this on 3.3.0.

Is there a plan to get this released in the near future?

[armanbilge]

We've enabled these same flags in the sbt-typelevel 0.5.0 RCs and they seem to be working well.

If a regular maintainer neither objects nor steps up I will try and get this out later this week. Sorry for the delay folks 😅

[armanbilge]

sbt-typelevel was making this mistake as well. It seems this is not the sort of thing a plugin should be doing. But that will have to be fixed in another PR / breaking release.

Without the project author explicitly opting into it. I think -source is dangerous and should not be enabled without thinking through all the consequences (and ideally it should only be used temporarily during a migration)

• Can/should I use both `-Xsource:3` and `-source:3.0-migration` in a cross-compiled codebase? scala/scala3#17591 (reply in thread)

[DavidGregory084]

Don't worry - this isn't actually enabled by default, it's just enabled in the test suite to make sure that users can manipulate options for each mode separately.

[DavidGregory084]

(see https://github.com/typelevel/sbt-tpolecat/pull/147/files#diff-25d6f7f6dbab5ef8591d0bce4e831ab4f799818e2d946938635f0f87c0a489afR25)

[armanbilge]

I can merge this PR, but publishing appears to be broken 😕 if the credentials are borked which is what I suspect, I don't think I can personally fix that.

One path forward would be to start publishing under org.typelevel since we have org-wide credentials. That may require re-working the build and CI a bit: either to make our credential setup work with the existing sbt-ci-release, or switching to sbt-typelevel(-ci-release). Unfortunately I don't have time to look into this: I think we'll need someone new to step up as a regular maintainer.

[DavidGregory084]

Apologies all, I'm really struggling to make time for sbt-tpolecat - life and work are conspiring against me atm. This PR looks absolutely great though, and I think we should merge it!

However, I'm not sure I can fix publishing either as I don't have access to repository level secrets in this repo anymore:

I think @armanbilge is right that this means publishing under org.typelevel, or alternatively, we can find a way to get the previous creds handed over to one of the org admins until the repo is in the right place to publish under org.typelevel?

On the plus side, there is an artifact migration ready to go in Scala Steward if we decide to go with the former route.

[armanbilge]

@typelevel/steering would one of you be able to give @DavidGregory084 admin access to this repo so they can install updated secrets? Thanks!

[samspills]

@DavidGregory084 I've given you admin access in the repo settings!

[DavidGregory084]

Thanks @samspills @armanbilge!

Publishing creds should be fixed up now: although I no longer use LastPass, I changed my Sonatype password as a precaution after the LastPass breach.

[DavidGregory084]

Thanks @amumurst!