What can we do to make error reporting better.

[Kordyjan]

Good error reporting is hard. Compiler ideally should not only tell the user that they have made a mistake but also why given code is not expressing what user intended it to do. Of course it not possible to always guess the intentions of the users and in many cases where it is possible it would require lots of work both from the compiler team and compiler itself during the compilation. Making every error message as expressive and self-explanatory as possible is not worth the effort, especially when there are multiple more pressing issues.

Nevertheless I think it may be beneficial to create discussion thread for sharing cases where error messages are misleading, especially for newcomers. I hope that for some of them we can discuss small improvements that can be implemented without much effort sometime later, and generally improve the situation.

• First class of errors that is not friendly to the newcomers are "raw" errors from the parser. They are usually only stating that some token were unexpected and that token is often somewhere else than the real source of the problem.
  Example: compiler is reporting that : was expected in the place of ) even though the true error was illegal inline modifier.

  • Some languages are parsing slightly more that the proper language. They have special cases for few common errors. Scala can have them for mistakes that may be commonly made by users having habits from other languages like : instead of with in givens or extends in classes, : instead of = in multiline defs, -> instead of =>, T =>> M[T] instead of [T] =>> M[T] etc.

• The other class of errors is mixing types and companion objects instances. The thing that prompted me to start this thread was error encountered by one of my colleagues earlier today. He wanted to use union types in the pattern matching. case _: A | B | C he wrote, was interpreted as case (_: A) | B | C giving him strange error message suggesting that something is wrong with type inference.

  • While we cannot detect this kind of misusing alternatives in pattern matching, we can slightly improve the error message for mismatched types by marking types that are types of companion objects more explicitly than just .type at the end.

[Kordyjan]

Tangent to the main thread: Rust has something like an error index. When the compiler outputs an error message it outputs also a link (or rustc --explain ... command) to the longer explanation of that error. Example. Some of these explanations contain examples of less obvious causes of given error which can be really helpful for newcomers. Maybe we can consider some kind of error index for scala as a part of the documentation.

[propensive]

@felixmulder worked on error messages in Dotty several years ago, and may have some comments.

[felixmulder]

Yep, we added a mode inspired by rustc --explain that did just this. Haven't checked if it is still alive :)

[felixmulder]

Looks like it still lives:

https://github.com/lampepfl/dotty/blob/8086e4b946de0c13f8bec62864f761ea87c82982/compiler/src/dotty/tools/dotc/reporting/Message.scala#L59

[propensive]

I'd briefly raise the following couple of points for consideration:

• terminology should be consistent: I still see implicit in some error messages in 3.0.0-RC2, for example.
• the compiler sometimes uses an inconsistent voice: there is at least one error messages where the compiler refers to itself as I, and other cases where it addresses the user as you. Consistent use of the passive voice would be better.

I like the idea that errors could be numbered, maybe with a prefix that's short enough to type quickly, while being unique enough that Google will produce relevant results without the user needing to add additional search terms (e.g. "scala") to find results explaining the error.

[bishabosha]

We decided to instead move reporting and discussion of error messages to individual issues - campaign coming soon, but we have begun with the new issue template for reporting problematic errors.

The other part of this discussion covered the creation of a rust-style error index, which is also discussed here