Tuesday 17 October 2023
Jamie Thompson (Scala Center)
Give your feedback to improve error reporting
TL;DR: click here to tell the Scala 3 core maintainers which error messages are unhelpful, confusing or otherwise suboptimal.
Why are we asking you
From suggesting to import missing extension methods and more, Scala 3 tries to improve the ways that warnings and errors are reported to the user. The idea being that when the user engages with reported problems, it should feel like having a conversation with a helpful tutor. By helping users to get back on track, we can make Scala easier to learn, friendlier to newcomers, and also keep experienced users more productive.
We know there is much more that can be done to continually improve the situation. As well as working to expose diagnostics programatically, we are starting a new campaign to seek out confusing, annoying or unhelpful error/warning messages.
As compiler authors, we do try to provide good messages, but it is possible for there to be shortcomings. For example, the message may correctly report a problem, but not provide enough information to actually help the user.
A good example is reported in this issue, which documents how to improve the following sub-optimal error message:
val f: (Int, Int) => Int = Integer.compare(_ + 1, _) // ^^^^^^^^^^^^^^^^^^^^^^^^^ // Wrong number of parameters, expected: 2
How you can help
To help collect problematic errors, we have made a new issue template to fill in on the Scala 3 repository.
The template helps you to write the report, by asking what was so confusing/unhelpful about the message, and then gives the option for you to suggest what would make the error more helpful, actionable, etc.
Please click here to open a new issue!
Results so far
- lampepfl/dotty#18686: Better error message when accessing private members
- lampepfl/dotty#18685: lazy val parameters and overrides
- lampepfl/dotty#18684: confusing “Not found” error when I change “def foo()” to “val foo()”
- lampepfl/dotty#18682: Can we have “did you mean…” for top-level names rather than just methods
And we already have a fix for
1. thanks to Nicolas Stucki from EPFL, see PR lampepfl/dotty#18690.