Wrong part colored in diagnostic suggestions after tabs

[m-ou-se]

trait T {
	const A: &u8;
}

(The second line starts with a tab, not with spaces!)

This results in:

It suggests to add a 'a after the &, but the green color is not applied to the 'a part, but instead to A: &, shifted a bit to the left.

cc @estebank

[m-ou-se]

The problem is only with tabs, it seems. It works fine with multi-byte, multi-codepoint, and double-width characters.

[estebank]

It works ok when it is a single line, so the problem is likely in the following code not accounting for calls to replace_tabs:

rust/compiler/rustc_errors/src/emitter.rs

Lines 1679 to 1689 in 6bed1f0

	if is_multiline {
	for SubstitutionHighlight { start, end } in parts {
	buffer.set_style_range(
	row_num,
	max_line_num_len + 3 + start,
	max_line_num_len + 3 + end,
	Style::Addition,
	true,
	);
	}
	}

error[E0106]: missing lifetime specifier
 --> f1.rs:2:11
  |
2 |     const A: &u8;
  |              ^ expected named lifetime parameter
  |
help: consider using the `'static` lifetime
  |
2 |     const A: &'static u8;
  |               +++++++
help: consider introducing a named lifetime parameter
  |
1 ~ trait T<'a> {
2 ~     const A: &'a u8;
  |

error[E0106]: missing lifetime specifier
 --> f1.rs:4:20
  |
4 | trait K { const A: &u8; }
  |                    ^ expected named lifetime parameter
  |
help: consider using the `'static` lifetime
  |
4 | trait K { const A: &'static u8; }
  |                     +++++++
help: consider introducing a named lifetime parameter
  |
4 | trait K<'a> { const A: &'a u8; }
  |        ++++            ~~~

[m-ou-se]

Oh, multi-{byte,column,codepoint} characters do not work fine in a single line:

trait T {
    const BLÅHAJ /* 👩‍❤️‍💋‍👩 */: &u8;
}

[m-ou-se]

The second line with the ^ or ++++ not aligning might be unactionable, because it depends a lot on the terminal how wide things are:

But at least the green coloring of &'stati can be fixed.

[estebank]

The underline not aligning due to wide grapheme clusters is a known issue, and somewhat of an impossible problem to solve in a way that covers all terminals, but the coloring we can definitely deal with. That being said, we might be able to have an env flag or config file to set different strategies for people to chose (emoji support/vs one byte==one col).

[m-ou-se]

That being said, we might be able to have an env flag or config file to set different strategies for people to chose (emoji support/vs one byte==one col).

Another option could be to use the \e[6n escape sequence to ask the terminal for feedback on how many columns it used after printing something. But that's probably not worth the effort. (And won't work when we're not directly writing to a terminal.)

[estebank]

That would fix quite a few things, but it would also require us to use a completely different approach to printing to the screen than what we do today (we keep a buffer that we dump all at once, so we precalculate all the col/line positions ahead of time).

[thomcc]

it depends a lot on the terminal how wide things are

Yeah, it depends on all of: the terminal, the font, the algorithm it uses for character width... In general, the most important thing is not getting it "right" (for some definition of right), it's doing the same thing that the terminal does. Which is intractable without querying it with \e[6n, as you said.

(This is a problem I've thought about a great deal...)

That said, I think the tab-specific case could be fixed by replacing tabs with spaces. This might be worth doing given how common use of tabs can be for indentation (even though in Rust they are not as common).

The downside is that the output text won't be identical to what's in the source buffer, but hey, it didn't have escape sequences in it either 😉.

[m-ou-se]

could be fixed by replacing tabs with spaces

That already happens. (That's why the char offsets in the output buffer and the source code didn't match.)

[thomcc]

Oh. I had figured it was just computing the width of the tab wrong, my bad.