-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Unicode block-drawing compiler output support #126597
base: master
Are you sure you want to change the base?
Conversation
0fb5d30
to
3b7a44f
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
This comment was marked as resolved.
This comment was marked as resolved.
Some changes occurred in tests/ui/check-cfg cc @Urgau |
r? compiler |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
57ff435
to
6fe519d
Compare
This change (IMO) improves the diagnostic output by changing the characters that codespan uses when outputting diagnostics. Inspired by rust-lang/rust#126597.
@estebank do we know what the situation is, about Unicode support (on terminals) for all the platforms that rustc supports? Can you say more about the reasoning behind this change? Why do we want to do this? thanks |
It's spotty at best. I've tested a few different terminals in different platforms and it is honestly quite a terrible status-quo. Mac terminals seem to all support this output correctly. Windows terminals it's hit or miss. Linux is almost always terrible (unless you have a good combination of terminal + fonts, Konsole for example looks ok). The idea for the output is to be configurable in
There are a couple of things behind this:
If this lands before we move to annotate-snippets, we'd change the setting for this to actually affect annotate-snippets, so anyone that starts opting-into unicode output will be "enrolled" in the testing of annotate-snippets when we do that move. |
f3d1fce
to
bcd2412
Compare
This comment has been minimized.
This comment has been minimized.
bcd2412
to
bd8daa3
Compare
This comment has been minimized.
This comment has been minimized.
bd8daa3
to
885d979
Compare
This comment has been minimized.
This comment has been minimized.
885d979
to
c64e042
Compare
☔ The latest upstream changes (presumably #122792) made this pull request unmergeable. Please resolve the merge conflicts. |
c64e042
to
171688f
Compare
☔ The latest upstream changes (presumably #130778) made this pull request unmergeable. Please resolve the merge conflicts. |
171688f
to
f8f56b6
Compare
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me after rebase. sorry for the abysmal delay. I have some small nits but they shouldn't really block this PR. esp. since annotate-snippet
will likely remedy them
if margin.was_cut_left() { | ||
// We have stripped some code/whitespace from the beginning, make it clear. | ||
buffer.puts(line_offset, code_offset, "...", Style::LineNumber); | ||
buffer.puts(line_offset, code_offset, placeholder, Style::LineNumber); | ||
} | ||
if margin.was_cut_right(line_len) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not super important: You could slightly tweak the comment & code inside Margin::was_cut_right
? The comment is outdated (refers to "code above" and "..."
) and hard-codes the offset (it's 6
right now; it that 2 * width(padding)
?).
I think was_cut_right
is still correct because "...".len() == 3 == "…".len()
but otoh I'm not sure if it the usizes
represent byte offsets for indexing or for displaying ("len vs width"). So might be worth double checking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that below, you use placeholder.chars().map(|ch| char_width(ch)).sum()
to robustly calculate the padding
of the placeholder
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
… however given the plan to push annotate-snippets
forward and eventually use it in the compiler over emitter.rs
, I'm sure if these issues matter ^^'.
if margin.was_cut_left() { | ||
// We have stripped some code/whitespace from the beginning, make it clear. | ||
buffer.puts(line_offset, code_offset, "...", Style::LineNumber); | ||
buffer.puts(line_offset, code_offset, placeholder, Style::LineNumber); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't spent too much thought on this but I wonder if things would break (offsets, alignments) if OutputTheme::Ascii.margin().len() != OutputTheme::Unicode.margin().len()
(which coincidentally isn't the case for ...
and …
so things just work out). Anyway, see comment chain directly below.
if let AnnotationType::MultilineLine(_) = annotation.annotation_type { | ||
buffer.putc( | ||
p, | ||
(code_offset + annotation.start_col.display).saturating_sub(left), | ||
underline.multiline_vertical, | ||
underline.style, | ||
); | ||
} else { | ||
buffer.putc( | ||
p, | ||
(code_offset + annotation.start_col.display).saturating_sub(left), | ||
underline.vertical_text_line, | ||
underline.style, | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if let AnnotationType::MultilineLine(_) = annotation.annotation_type { | |
buffer.putc( | |
p, | |
(code_offset + annotation.start_col.display).saturating_sub(left), | |
underline.multiline_vertical, | |
underline.style, | |
); | |
} else { | |
buffer.putc( | |
p, | |
(code_offset + annotation.start_col.display).saturating_sub(left), | |
underline.vertical_text_line, | |
underline.style, | |
); | |
} | |
buffer.putc( | |
p, | |
(code_offset + annotation.start_col.display).saturating_sub(left), | |
match annotation.annotation_style { | |
AnnotationType::MultilineLine(_) => underline.multiline_vertical, | |
_ => underline.vertical_text_line, | |
}, | |
underline.style, | |
); |
if let AnnotationType::MultilineStart(_) = annotation.annotation_type { | ||
buffer.putc( | ||
p, | ||
line_offset + pos, | ||
(code_offset + annotation.start_col.display).saturating_sub(left), | ||
'|', | ||
style, | ||
underline.bottom_right, | ||
underline.style, | ||
); | ||
} | ||
if let AnnotationType::MultilineEnd(_) = annotation.annotation_type | ||
&& annotation.has_label() | ||
{ | ||
buffer.putc( | ||
line_offset + pos, | ||
(code_offset + annotation.start_col.display).saturating_sub(left), | ||
underline.multiline_bottom_right_with_text, | ||
underline.style, | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similarly
@@ -1102,7 +1155,11 @@ impl HumanEmitter { | |||
let style = | |||
if annotation.is_primary { Style::LabelPrimary } else { Style::LabelSecondary }; | |||
let (pos, col) = if pos == 0 { | |||
(pos + 1, (annotation.end_col.display + 1).saturating_sub(left)) | |||
if annotation.end_col.display == 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you maybe leave a comment why this is necessary?
@@ -2082,7 +2249,7 @@ impl HumanEmitter { | |||
buffer.putc( | |||
row_num, | |||
(padding as isize + p) as usize, | |||
if part.is_addition(sm) { '+' } else { '~' }, | |||
if part.is_addition(sm) { '+' } else { self.diff() }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side note: For annotate-snippet
, it would be nice if symbols like +
that currently don't vary by OutputTheme
get moved to the "palette".
f8f56b6
to
2af9d09
Compare
This comment was marked as resolved.
This comment was marked as resolved.
Add nightly-only theming support to rustc output using Unicode box drawing characters instead of ASCII-art to draw the terminal UI: After: ``` error: foo ╭▸ test.rs:3:3 │ 3 │ X0 Y0 Z0 │ ┌───╿──│──┘ │ ┌│───│──┘ │ ┏││━━━┙ │ ┃││ 4 │ ┃││ X1 Y1 Z1 5 │ ┃││ X2 Y2 Z2 │ ┃│└────╿──│──┘ `Z` label │ ┃└─────│──┤ │ ┗━━━━━━┥ `Y` is a good letter too │ `X` is a good letter ╰╴ note: bar ╭▸ test.rs:4:3 │ 4 │ ┏ X1 Y1 Z1 5 │ ┃ X2 Y2 Z2 6 │ ┃ X3 Y3 Z3 │ ┗━━━━━━━━━━┛ ├ note: bar ╰ note: baz note: qux ╭▸ test.rs:4:3 │ 4 │ X1 Y1 Z1 ╰╴ ━━━━━━━━ ``` Before: ``` error: foo --> test.rs:3:3 | 3 | X0 Y0 Z0 | ___^__-__- | |___|__| | ||___| | ||| 4 | ||| X1 Y1 Z1 5 | ||| X2 Y2 Z2 | |||____^__-__- `Z` label | ||_____|__| | |______| `Y` is a good letter too | `X` is a good letter | note: bar --> test.rs:4:3 | 4 | / X1 Y1 Z1 5 | | X2 Y2 Z2 6 | | X3 Y3 Z3 | |__________^ = note: bar = note: baz note: qux --> test.rs:4:3 | 4 | X1 Y1 Z1 | ^^^^^^^^ ```
2af9d09
to
eb55252
Compare
Add nightly-only theming support to rustc output using Unicode box
drawing characters instead of ASCII-art to draw the terminal UI.
In order to enable, the flags
-Zunstable-options=yes --error-format=human-unicode
must be passed in.After:
Before:
After:
Before: