Error Message Overhaul

[nikomatsakis]

PR #32756 began a gradual overhaul of our error message formatting. We would very much like feedback on error messages you think could use improvement, as well of course as any bugs or other problems with the new error formatting code. Please leave comments!

What follows is a list of known issues we plan to address. Likely many of these will be moved into distinct GitHub issues at some point.

Improvements to the overall error reporting mechanism:

• New unit testing mechanism that can test colors and precise appearance: Add UI testing to compiler test suite #33000
• Improve the treatment of tabs.
• Subdiagnostics like note should not be colored green but rather just appear bold
• Subdiagnostics like note should not use the --> indicator but rather >>>, and the underline should be -- and not ^^
  • basically, they do not have a primary span
• Mandatory labels on primary spans?
• Change from >>>> for secondary file names to something like ::: maybe?
• When snippet labels are too long, potentially move them to a footnote of some kind

Specific error messages that need improvement:

• Identify when you have the same span for multiple borrows in a loop and give a better message.
• We special case closure captures due to unique loans, but we could give similar treatment to any loan coming through a capture.
• Decide whether to thread the closure header span through the builder API convenience methods.

[ticki]

For anyone who want to play around with ideas related to the error formatting, you can use this.

[nikomatsakis]

cc @jonathandturner

[ticki]

Could you add the following?

• Customization of error formatting.
• Unicode switch.
• Syntax highlighting.

[sophiajt]

@ticki

Customization of error formatting.

We'd talked some about maybe a "customization of error colors". What do you mean by error formatting?

Unicode switch.

Because we want errors to look and feel similar across platforms, the idea here is to pick a way to display the error that's friendly to even non-unicode environments (like default Windows). We can definitely revisit this one if modern Windows improvements, like Bash on Windows for example, open up the door to using more Unicode.

Syntax highlighting.

Oh right. Yeah, that could look good, depending on how we do it. Would be fun to experiment.

[GuillaumeGomez]

Syntax highlighting.

I worked on it a while ago for rustc --explain. I came to the conclusion that the "best" way to do it would be through rustdoc. It just needs to add an "ascii" (don't know if it's the correct translation) output format. But for that, we need to rework rustdoc source code in order to easily add new output formats.

Improve the treatment of tabs.

I'm not sure to understand the issue here. Aren't they translated as whitespaces?

[sophiajt]

@GuillaumeGomez the tabs issue is around treating the amount of space we print the tab the same as the amount of space we need to move under the source code to start underlining. The old code had some logic in there to line them up and we just need to port it over.

[GuillaumeGomez]

Ok, so it's a port issue. Thanks for the explanation @jonathandturner!

[mhintz]

One thing that nags me a lot is the amount of space between distinct error messages in the printed console output. Often, because of whitespace in individual error messages, there is more visual whitespace within messages than between distinct ones. This makes it difficult, when scanning printed console output, to visually distinguish different messages, which makes fast visual parsing of the compiler output tricky.

When coupled with the fact that rustc often generates several error messages at once, some of which are follow-ons from one original message appearing at the top of the output, I often find myself scrolling upwards through a column of hard-to-scan text looking for a hard-to-spot relevant message.

A more clearly formatted beginning of the compiler output and clearer delineation between individual error messages would help a lot.

Thanks!

[sophiajt]

@mhintz Do you have an example of the spacing issue you're talking about? Also, is this an issue with the previous error message style or the new message style?

[ticki]

We'd talked some about maybe a "customization of error colors". What do you mean by error formatting?

Well, making it possible to define the escapes introducing the various labels.

Oh right. Yeah, that could look good, depending on how we do it. Would be fun to experiment.

I thought about using a loosly coloured scheme, to avoid confusion with the labels otherwhere.

[ketsuban]

Enum variants are associated items, which has some potentially surprising consequences if you attempt to access them through a type alias (including Self in trait implementations). Whether that's actually desired behaviour or not is #26264, but in #31168 I observed that the error is strikingly unhelpful.

A better error, I think, would be something like error: enum variants cannot be accessed through an alias, perhaps with a note suggesting the appropriate code change since we know the compiler can look up the name of the enum in question.

[ticki]

@ketsuban Wrong thread?

[ketsuban]

No?

We would very much like feedback on error messages you think could use improvement

My issue was about an error message which isn't very clear, so I posted it here to garner attention since this is an issue for bringing attention to unhelpful error messages.

[mhintz]

@jonathandturner Just scrolled through the history over at #32756 and it looks like that PR takes care of my objection about spacing, by reformatting and separating nightly's current output. I also hadn't known about the Dybuk formatter, which looks pretty good (maybe even better than the PR).

I assumed it wasn't on the radar, since it hasn't been merged into nightly yet, and I saw the rustlang Twitter account post about it. Glad it's being worked on!

[nikomatsakis]

• Customization of error formatting.
• Unicode switch.

I am sort of undecided about whether we want these. Customization is
a lot of area to stabilize -- we have to select a means of
customization etc, spec it out, support it, etc -- that I would prefer
to avoid, and it seems like a kind of niche request.

• Syntax highlighting.

But this would be nice.