Should we highlight spans in diagnostics?


#1

In PR #45776 I added support to highlight the code that corresponds to the underline span for any given diagnostic in order to side step issue #42112.

I would like to receive as much feedback as possible on wether we should move forward with merging this change or not. Please feel free to go to the PR and leave a +1 or -1 reaction to it in order to gauge the mood of the community, as well as leaving comments both here, the internals thread and in the PR.


#2

Could you get us a before/after picture? You linke the “after” in the PR, but a direct comparison would certainly help to be sure.


#3

Here they are (updated the PR too):

vs


#4

The new version looks good but kind of redundant. Do we really need to both highlight and underline the text?

I personally find all this ASCII-graphics formatting too noisy and hard to understand at first glance. This representation really feels like it doesn’t belong to a terminal but should be displayed over the code in an IDE. Is rustc able to output errors in a fully parsable form (e.g. JSON)? If so, an IDE or another tool can reformat it how the user likes, and the default formatting doesn’t matter too much.


#5

The use of bold definitely makes it easier to locate the source of the error. However, as @Riateche rightfully points out, it feels somewhat redundant and heavy-handed. Another thing which I would point out, looking at @colin_kiegel’s recent poll on the new format of pretty_assertions, is that you’ll definitely want to test this on a terminal with a bright background color, because bold text tends to stand out less on these.

I think the reason why bold feels like an improvement is likely that neither of the existing highlighting methods, colors and underlines, is very effective at putting the focus on the relevant span of text. That’s because they are visually “too far away” from the text. It gets especially bad in the “functions generic over types must be mangled” warning, where the blue highlight is equally close to the top text and the bottom text, although after looking for a while, one will figure out which is which from context since rustc only uses underlines.

So instead of adding a third highlighting method, perhaps one of the existing two methods should be brought closer to the text that it is highlighting. With this in mind, I like your suggestion in the Github issue to propagate the color of the underline to the highlighted text:


#6

I actually agree with this. Here’s an anecdotal example of why: I once saw an error similar to this:

    &Foo(blah) => {
     ---------
       help: try using &Foo(blah) here

It was quite easy to miss the fact that the & is not highlighted because of how far the underline was from the code. I think using color (not just bold) would make this a lot more obvious.


#7

I’d say it’s an improvement, but I’d prefer the version @HadrienG linked.

I also realized I need to check my terminal colors :smiley:


#8

I have seen a lot of new (and not-so-new) Rust programmers fail to notice the underlines, and thus misinterpret an error message as referring to a completely different part of the line. I think highlighting will be a significant help here.


#9

Also another thing I just realized – if the lines get wrapped by narrow terminal windows, then the underline gets desync’ed from the code, so having some extra formatting is useful as a fallback.


#10

This was part of the original motivation for this proposal :slight_smile:


#11

I’m intrigued to see that the weight of this thread, at least, seems to be in favor of using more colors. In the past, people have complained about the :christmas_tree: effect of too many colors, but I’m not hearing that on this thread at least.


#12

Speaking personally, I pretty much agree with @ekuber’s statement on the PR. Color is more correct from the point of view of ergonomics and graphic design (as it unambiguously links the highlighted text to the associated underline without introducing a third text highlighting method), while bold looks better.

My view is that aesthetics is something that people ultimately adjust to given enough time, whereas usability is a more fundamental concern, which is why I think colored text is the best long-term option.