Scala 3.8.3 release thread

Announcements
1

Scala 3.8.3-RC1 is now available for public tests!

Please give the new release candidate a try and let us know if anything regresses before the final release.

Release highlights

  • -print-lines setting deprecated for removal - the setting was used to print line numbers in the error messages. This feature was rarely used and become a burden to maintain. Since Scala 3.8.3 it’s usage is ignored and would emit warning when used. It would be removed in the future versions

  • New local coverage toggles #24486: you can now exclude selected code regions from coverage instrumentation with:

    • // $COVERAGE-OFF$
    • // $COVERAGE-ON$
object CoverageExample:

  def importantLogic(x: Int): Int =
    if x > 0 then x * 2 else 0

  // This region will be ignored by coverage instrumentation
  // $COVERAGE-OFF$
  def noisyLogging(input: String): Unit =
    println(s"[debug] raw input = $input")
    println(s"[debug] timestamp = ${System.currentTimeMillis()}")
  // $COVERAGE-ON$

  def run(x: Int): Int =
    noisyLogging(s"x=$x")
    importantLogic(x)
  • Fixes in JVM backend, parser, REPL, reporting/diagnostics, pattern matching, and presentation compiler.
  • Multiple improvements/fixes in experimental Capture Checking (renames, diagnostics, leak warnings, global capabilities handling, etc.)

Stable release

The stable release of Scala 3.8.3 is planned no earlier then March 24. We recommend to try out the new RC version during these period and report any found problems in this thread or in dedicated issue on Scala 3 issues tracker. Bugs reported early during the RC period have a higher chance to be fixed and backported to the stable release!

Scala 3.8.3 would be followed by at least 1 more 3.8.x patch release before establishing a Scala 3.9 LTS series.

7 Likes
2

Nice! Found a bug this morning that happens to be present in 3.8.3-RC1.

1 Like
3

Finally! Thanks

1 Like
4

Second RC version is now available for testing!

  • Scala CLI upgrade
  • Addition of experimental.safe mode - extension of experimental Capture Checking limiting access to potentially unsafe operations
  • Fixes to binary compatibility regression
  • and multiple bugfixes
4 Likes
5

Scala 3.8.3-RC3 is out!

This version backports the Scala 2 Bytecode optimizer into the Scala 3 compiler. We recommended to give it a try, but be aware that the settings to configure it might differ. This change does not enable optimizer in the Scala 3 artifacts yet - optimization of standard library artifacts is delayed until Scala 3.9.

4 Likes
6

It would be. nice to have some numbers.

7

3.8.4 will be released.
Potential 3.8.5 is still under discussion, it might or might not be required.
3.8.6 is currently not considered in the planning, but we reserve right to delay 3.9 LTS if it would be required

2 Likes
8

This sounds interesting, but I am not sure about implications. Will the optimizer make my Scala app faster / shorter … ? Is it enabled by default? I remember in Scala 2 the conditions for using the optimizer made is so hard to use I never attempted it.

The PR mentioned in the changelist seems to be concerned mostly about implementation. not in how this should be used.

9

Most of the constraints present in the Scala 2 are present in the Scala 3 optimizer - that’s the same approach, might subtle nuances.

In the Porting the Scala 2 optimizer to Scala 3 | The Scala Programming Language blogpost a performance gain 10-30% was observed, it depends on the application.

Optimizer is never enabled by default, it was always opt-in.
I don’t think the initial setup is hard it’s mostly a few scalac options:

  • -opt to enable optimizer and all optimizations (in Scala 2 it was -opt:local / -opt:l
  • -opt-inline - to list which code can be inlined (in most cases it should be your own packages - this can affect binary compatibility)
  • alternatively it possible to enable selective optimizations, see PR
2 Likes
10

Having the optimizer land is amazing news! It’s like hearing your team suddenly acquired a new star and you expect to make the playoffs this year.

I hope and expect it will be as easy to use as in Scala 2.

As I recall, it was usual to enable “local” optimizations, which could tidy up bytecode and make it nicer to look up.

On a chilly spring night, however, one would inline:<source> for inlining from current sources, and which would enable a warming zephyr from the computer fan.

For a true sirocco, inline:** would bring in everything and at times was more like a haboob.

I always inlined from the old scala.util.chaining, and I’m curious to see whether people will preferentially inline, now that inline is guaranteed in source, which is nice but introduces visual noise.

1 Like
11

Will the optimizer be able to simplify for loops over an Iterator into a simple while loop (or nested loops if necessary)?

If all you use in a for loop are iterators (without monads), the rewrite rule is trivially mechanical. And you can rewrite Range simply to Range.iterator and get that optimized too. Or stdlib collections as well, and arrays, …

Introduce a @simpleLoop annotation to assert that (akin to @tailrec) and we suddenly have a very simple escape hatch for performance critical code. JVM is also able to determine the Iterator does not escape via escape analysis, and suddenly you have zero-heap-allocation loops in a high-level Scala code.

3 Likes
12

What do you think about this proposal?

13

It might be worth to experiment with that. I might be best to start with formalizing that in the scala/scala3 · Discussions · GitHub which is the closest future request tracker. I’m not sure how hard it would be to actually enforce that rule in the compiler

14

Scala 3.8.3 is out!

The Scala 3.8.4-RC1 would be released later this week

11 Likes