Update scalameta to 4.8.8

[scala-center-steward]

About this PR

📦 Updates org.scalameta:scalameta from 4.8.4 to 4.8.8

📜 GitHub Release Notes - Version Diff

Usage

✅ Please merge!

I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.

If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.

Configure Scala Steward for your repository with a .scala-steward.conf file.

Have a fantastic day writing Scala!

⚙ Adjust future updates

Add this to your .scala-steward.conf file to ignore future updates of this dependency:

updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalameta" } ]

Or, add this to slow down future updates of this dependency:

dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scalameta", artifactId = "scalameta" }
}]

^{labels: library-update, early-semver-patch, semver-spec-patch, version-scheme:semver-spec, commit-count:1}

[bjaglin]

I want to implement in sbt-scalafix what was suggested to be done upstream in sbt in #1825 before merging this as a patch release.

We could try to improve the error message in sbt when scalac-semanticdb is not found since it's currently not actionable at all:

[error] (update) sbt.librarymanagement.ResolveException: Error downloading org.scalameta:semanticdb-scalac_2.13.11:4.5.13
[error]   Not found
[error]   Not found
[error]   not found: /home/brice/.ivy2/local/org.scalameta/semanticdb-scalac_2.13.11/4.5.13/ivys/ivy.xml
[error]   not found: https://repo1.maven.org/maven2/org/scalameta/semanticdb-scalac_2.13.11/4.5.13/semanticdb-scalac_2.13.11-4.5.13.pom
[error] Total time: 1 s, completed Jul 19, 2023, 3:49:41 PM

I was thinking of recovering that exception by redefining update to add error handling (like described in https://www.scala-sbt.org/1.x/docs/Tasks.html#Handling+Failure).

[scala-center-steward]

Superseded by #1852.

[tgodzik]

What do you think about the approach in scalameta/metals#5671 ? We generate the map of supported versions from sbt and it's 30 lines of code. Doesn't seem to take up a lot of time to run also

[bjaglin]

Thanks for the link and sorry for the late follow-up! It does look very similar to what we already have on-demand in sbt-scalafix via scalafixEnable scalacenter/sbt-scalafix#292.

I'd rather stick to the status quo (i.e. running the semanticdb-scalac version lookup only via a specific command) for the following reasons:

• doing IOs at sbt boot (settings initialization) is a source of non-deterministic behavior (sbt-scalafix is used on dev workstations and CI, so subject to proxies, etc)
• scalacenter/sbt-scalafix@4ced96a does a decent job at explaining users what's going on if they try to run with an unpublished semanticdb-scalac version (and I believe we could try to push this upstream to improve sbt's SemanticdbPlugin if we do anything on that topic)
• we no longer have this problem with Scala 3 as the semanticdb output is part of the compiler
• the frequency of 2.x releases is low and the announcement/process on Scala Contributors is very good, so it's not a big deal to synchronize sbt-scalafix releases (which can detect/fix changes in the compiler like in 2.13.12)