feat: Right align line numbers

[Muscraft]

As part of my work on getting annotate-snipptes to be used as rustc's renderer, I realized that rustc left-aligned line numbers, while annotate-snippets right-aligned them. This PR switches rustc to right-align the line numbers, matching annotate-snippets. In practice, this change isn't very noticeable in day-to-day output, as it only shows up when a diagnostic span contains line numbers with different lengths (9->10, 99->100, 999->1000, etc.).

rustc

error[E0412]: cannot find type `F` in this scope
  --> $DIR/ui-testing-optout.rs:92:10
   |
4  | type A = B;
   | ----------- similarly named type alias `A` defined here
...
92 | type E = F;
   |          ^ help: a type alias with a similar name exists: `A`

annotate-snippets

error[E0412]: cannot find type `F` in this scope
  --> $DIR/ui-testing-optout.rs:92:10
   |
 4 | type A = B;
   | ----------- similarly named type alias `A` defined here
...
92 | type E = F;
   |          ^ help: a type alias with a similar name exists: `A`

r? @compiler-errors

[rustbot]

compiler-errors is not on the review rotation at the moment.
They may take a while to respond.

[rustbot]

This PR modifies run-make tests.

cc @jieyouxu

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

##[endgroup]
[TIMING] core::build_steps::tool::ToolBuild { build_compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu, forced_compiler: false }, target: x86_64-unknown-linux-gnu, tool: "tidy", path: "src/tools/tidy", mode: ToolBootstrap, source_type: InTree, extra_features: [], allow_features: "", cargo_args: [], artifact_kind: Binary } -- 12.752
[TIMING] core::build_steps::tool::Tidy { compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu, forced_compiler: false }, target: x86_64-unknown-linux-gnu } -- 0.000
fmt check
Diff in /checkout/compiler/rustc_errors/src/emitter.rs:2127:
                 // Account for a suggestion to completely remove a line(s) with whitespace (#94192).
                 let line_end = sm.lookup_char_pos(parts[0].span.hi()).line;
                 for line in line_start..=line_end {
-                    self.draw_line_num(&mut buffer, line, row_num -1 + line - line_start, max_line_num_len);
+                    self.draw_line_num(
+                        &mut buffer,
+                        line,
+                        row_num - 1 + line - line_start,
+                        max_line_num_len,
+                    );
                     buffer.puts(
                         row_num - 1 + line - line_start,
                         max_line_num_len + 1,
Diff in /checkout/compiler/rustc_errors/src/emitter.rs:2623:
             let last_line_index = file_lines.lines[file_lines.lines.len() - 1].line_index;
             let last_line = &file_lines.file.get_line(last_line_index).unwrap();
             if last_line != line_to_add {
-                self.draw_line_num(buffer, line_num + file_lines.lines.len() - 1, *row_num - 1, max_line_num_len);
+                self.draw_line_num(
+                    buffer,
+                    line_num + file_lines.lines.len() - 1,
+                    *row_num - 1,
+                    max_line_num_len,
+                );
                 buffer.puts(*row_num - 1, max_line_num_len + 1, "- ", Style::Removal);
                 buffer.puts(
                     *row_num - 1,
fmt: checked 6266 files
Build completed unsuccessfully in 0:00:48
  local time: Mon Jul 28 22:30:25 UTC 2025
  network time: Mon, 28 Jul 2025 22:30:25 GMT
##[error]Process completed with exit code 1.

[compiler-errors]

@bors r+ rollup

[bors]

📌 Commit aa97672 has been approved by compiler-errors

It is now in the queue for this repository.

[dhedey]

EDIT: Ah sorry I think this may have been an issue with an older version of trybuild's normalization combined with this PR, rather than this PR itself, my apologies. It looks fixed in trybuild 1.0.110. Original report below.

Original report

I've noticed (I think after this change) on beta and nightly, the indentation of the | on the line before the numbers is inconsistent if the number character width spans multiple widths.

I don't see any test cases covering this in the PR, perhaps it was overlooked?

Example on Nightly

See the third line here above the 4

error: And now we error
 --> tests/compilation_failures/control_flow/error_after_continue.rs:4:5
  |
 4 | /     preinterpret!(
 5 | |         #(let x = 0)
 6 | |         [!while! true {
 7 | |             #(x += 1)
...  |
17 | |         }]
18 | |     );
   | |_____^
   |
   = note: this error originates in the macro `preinterpret` (in Nightly builds, run with -Z macro-backtrace for more info)