Update scala-library, scala-reflect to 2.13.12

[scalameta-bot]

About this PR

📦 Updates

• org.scala-lang:scala-library
• org.scala-lang:scala-reflect

from 2.13.11 to 2.13.12

📜 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.scala-lang" } ]

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

dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-lang" }
}]

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

[kitbellew]

can't merge it, since we load older versions dynamically and some of them will throw NoSuchElementException when accessing the last token of a now-empty Tokens slice (which has generally been fixed in more recent versions). cc @tgodzik.

[tgodzik]

since we load older versions dynamically

But older versions would use the new Scala version, not the old one?

[kitbellew]

older versions would indeed use the new scala version. the problem is, older versions had the same problem as the one mentioned in scalameta/scalameta#3235, and while the problem was fixed later, due to dynamic loading, if we switch scalafmt to this new scala version, and someone uses it to load an older version dynamically, it will fail.

although, i guess, if they are using an old version of the formatter in their .scalafmt.conf, why would they upgrade the executable version?

[tgodzik]

although, i guess, if they are using an old version of the formatter in their .scalafmt.conf, why would they upgrade the executable version?

I have seen it the other way, but not really the case where the executable would be newer. I guess if someone installs it globally then this might happen for an older project. I wonder if there would be a way to use older version of scala. We do use a custom classloader if I remember?