Add support for `annotate-snippets`'s `no-graphics` output format by Muscraft · Pull Request #165708 · rust-lang/rust

Muscraft · 2026-11-09T17:57:47Z

Tracking Issue: #165164
MCP: rust-lang/compiler-team#1045

This PR adds the initial support for annotate-snippets's no-graphics output format. The no-graphics output format doesn't show source snippets or use any graphical decorations and is primarily designed for Text-To-Speech and Braille displays. The goal at this time is to get no-graphics in front of users so we can iterate on and improve the output.

🤖 LLM involvement: I used an LLM to review the commits before submitting

r? @estebank

rustbot · 2026-11-09T17:57:54Z

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

rustbot · 2026-11-09T20:05:11Z

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

estebank

I'm leaning towards r+, but am slightly concerned by this new flag option being insta-stable. Could we add a check for -Zunstable-options being present before allowing the output? It could even still allow changing the rendering (even on stable), as long as an error is always emitted complaining that the feature is unstable. That way people can already start using it, while giving no stability guarantees because having the flag always enabled would cause it to never permit a compile to succeed.

View changes since this review

estebank · 2026-11-09T20:31:46Z

@@ -33,6 +33,7 @@ use crate::{
 /// Describes the way the content of the `rendered` field of the json output is generated
 #[derive(Clone, Copy, Debug, PartialEq, Eq)]
 pub struct HumanReadableErrorType {


Non-blocker. We should be moving towards an enum, I think.

I agree that we should move to an enum, and I tried to do so, but I ran into issues discerning what should be variants vs. options e.g., is short its own rendering format (variant), or is it an option on graphics/no-graphics?

I think that (at least eventually) we likely want to fully enumerate all of the cases (so short would be its own thing). The only one that is orthogonal is color, IMO. To be clear, I don't mind not doing that in this PR!

estebank · 2026-11-09T20:37:25Z

+//! Check that compile errors are formatted in the "no-graphics" style
+//! when `--error-format=human-no-graphics` is used.
+
+//@ compile-flags: --error-format=human-no-graphics


Is there no gate for -Znightly-features for --error-format=human-no-graphics, or for that matter the previously existing --error-format=human-unicode? I thought we hadn't stabilized that last one yet (but I can see on stable rustc that it works).

The only reason I am concerned about it is that I might want to have a round of discussion on what the flag name should be long term. I am personally biased towards this new mode being called --error-format=text-only or --error-format=no-graphics.

Is there no gate for -Znightly-features for --error-format=human-no-graphics, or for that matter the previously existing --error-format=human-unicode?

-Zunstable-options isn't required in UI tests since RUSTC_BOOTSTRAP=1 is set for all UI tests. The docs I linked to say that act-as-stable can be used in UI tests to verify stable-only behavior; I can add a test that uses it if you want.

I thought we hadn't stabilized that last one yet (but I can see on stable rustc that it works).

Maybe I did something wrong, but using --error-format=human-unicode on +stable gives me an error, but not on nightly:

❯ echo 'fn main(){let x;}' | rustc +stable - --error-format=human-unicode error: `--error-format=human-unicode` is unstable

❯ echo 'fn main(){let x;}' | rustc +nightly - --error-format=human-unicode error[E0282]: type annotations needed ╭▸ <anon>:1:15 │ 1 │ fn main(){let x;} │ ━ ╰╴ help: consider giving `x` an explicit type ╭╴ 1 │ fn main(){let x: /* Type */;} ╰╴ ++++++++++++ error: aborting due to 1 previous error

The only reason I am concerned about it is that I might want to have a round of discussion on what the flag name should be long term. I am personally biased towards this new mode being called --error-format=text-only or --error-format=no-graphics.

I personally prefer --error-format=no-graphics and would be happy to switch to it if it seems like the right thing to do. I only went with --error-format=human-no-graphics to match the existing naming convention(s).

estebank · 2026-11-09T20:44:24Z

Can we add two more svg tests showing the interaction of color and no-color with the new diagnostic render?

View changes since the review

I can add an SVG test for color, but no-color always uses .stderr, as far as I can tell. The only way I could find to get no-color to use an SVG was to also enable -Zterminal-urls=yes.

I added a test that shows color (svg), no-color (stderr), and terminal-urls (SVG, with color). Let me know if they are what you were looking for

rustbot · 2026-11-10T01:31:38Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

estebank · 2026-11-10T03:40:16Z

@bors r+

rust-bors · 2026-11-10T03:40:19Z

📌 Commit c34bdf9 has been approved by estebank

It is now in the queue for this repository.

@estebank

…tebank Add support for `annotate-snippets`'s `no-graphics` output format Tracking Issue: rust-lang#165164 MCP: rust-lang/compiler-team#1045 This PR adds the initial support for `annotate-snippets`'s [`no-graphics` output format](https://docs.rs/annotate-snippets/latest/annotate_snippets/struct.Renderer.html#method.no_graphics). The `no-graphics` output format doesn't show source snippets or use any graphical decorations and is primarily designed for Text-To-Speech and Braille displays. The goal at this time is to get `no-graphics` in front of users so we can iterate on and improve the output. --- 🤖 LLM involvement: I used an LLM to review the commits before submitting r? @estebank

@estebank

…tebank Add support for `annotate-snippets`'s `no-graphics` output format Tracking Issue: rust-lang#165164 MCP: rust-lang/compiler-team#1045 This PR adds the initial support for `annotate-snippets`'s [`no-graphics` output format](https://docs.rs/annotate-snippets/latest/annotate_snippets/struct.Renderer.html#method.no_graphics). The `no-graphics` output format doesn't show source snippets or use any graphical decorations and is primarily designed for Text-To-Speech and Braille displays. The goal at this time is to get `no-graphics` in front of users so we can iterate on and improve the output. --- 🤖 LLM involvement: I used an LLM to review the commits before submitting r? @estebank

JonathanBrouwer · 2026-11-10T10:25:58Z

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #165742 (comment)

Probably this PR?
@bors try jobs=test-x86_64-gnu-aux

rust-bors · 2026-11-10T10:26:07Z

This pull request was unapproved.

This PR was contained in a rollup (#165742), which was unapproved.

View changes since this unapproval

Add support for `annotate-snippets`'s `no-graphics` output format try-job: test-x86_64-gnu-aux

rust-bors · 2026-11-10T11:27:02Z

💔 Test for 5220576 failed: CI. Failed job:

try - test-x86_64-gnu-aux (web logs, enhanced plaintext logs)

rust-log-analyzer · 2026-11-10T11:28:37Z

The job test-x86_64-gnu-aux failed! Check out the build log: (web) (plain enhanced) (plain)

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

rustbot assigned estebank Nov 9, 2026

This comment has been minimized.

Sign in to view

Muscraft force-pushed the support-no-graphics branch from bd12853 to 791e562 Compare November 9, 2026 20:05

This comment has been minimized.

Sign in to view

estebank approved these changes Nov 9, 2026

View reviewed changes

estebank reviewed Nov 9, 2026

View reviewed changes

Muscraft added 2 commits November 9, 2026 18:31

chore: Update annotate-snippets to 0.12.17

0ba7052

feat: Add support for annotate-snippets's no-graphics output format

c34bdf9

Muscraft force-pushed the support-no-graphics branch from 791e562 to c34bdf9 Compare November 10, 2026 01:31

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 10, 2026

jhpratt mentioned this pull request Nov 10, 2026

Rollup of 11 pull requests #165735

Closed

JonathanBrouwer mentioned this pull request Nov 10, 2026

Rollup of 14 pull requests #165742

Closed

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 10, 2026

rust-bors Bot pushed a commit that referenced this pull request Nov 10, 2026

Auto merge of #165708 - Muscraft:support-no-graphics, r=<try>

5220576

Add support for `annotate-snippets`'s `no-graphics` output format try-job: test-x86_64-gnu-aux

This comment has been minimized.

Sign in to view

Conversation

Muscraft commented Nov 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Nov 9, 2026

Uh oh!

This comment has been minimized.

rustbot commented Nov 9, 2026

Uh oh!

This comment has been minimized.

estebank left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

estebank Nov 9, 2026

Choose a reason for hiding this comment

Uh oh!

Muscraft Nov 9, 2026

Choose a reason for hiding this comment

Uh oh!

estebank Nov 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

estebank Nov 9, 2026

Choose a reason for hiding this comment

Uh oh!

Muscraft Nov 9, 2026

Choose a reason for hiding this comment

Uh oh!

estebank Nov 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Muscraft Nov 9, 2026

Choose a reason for hiding this comment

Uh oh!

Muscraft Nov 10, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Nov 10, 2026

Uh oh!

estebank commented Nov 10, 2026

Uh oh!

rust-bors Bot commented Nov 10, 2026

Uh oh!

JonathanBrouwer commented Nov 10, 2026

Uh oh!

rust-bors Bot commented Nov 10, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Nov 10, 2026

Uh oh!

rust-log-analyzer commented Nov 10, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Muscraft commented Nov 9, 2026 •

edited

Loading

estebank left a comment •

edited by rustbot

Loading

estebank Nov 9, 2026 •

edited

Loading

estebank Nov 9, 2026 •

edited by rustbot

Loading