Skip to content

Commit ee52f05

Browse files
committed
Continue annotate-snippets goal from 2024H2
1 parent d08f239 commit ee52f05

File tree

1 file changed

+89
-0
lines changed

1 file changed

+89
-0
lines changed

src/2025h1/annotate-snippets.md

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
# Use annotate-snippets for rustc diagnostic output
2+
3+
| Metadata | |
4+
| --- | --- |
5+
| Owner(s) | @estebank, @Muscraft |
6+
| Teams | [compiler] |
7+
| Status | Accepted |
8+
| Tracking issue | [rust-lang/rust-project-goals#123] |
9+
10+
11+
## Summary
12+
13+
Switch to annotate-snippets for rendering rustc's output, with no loss of functionality or visual regressions.
14+
15+
## Motivation
16+
17+
Cargo has been [adding its own linting system][cargo-lints], where it has been using annotate-snippets to try and match Rust's output. This has led to duplicate code between the two, increasing the overall maintenance load. Having one renderer that produces Rust-like diagnostics will make it so there is a consistent style between Rust and Cargo, as well as any other tools with similar requirements like miri, and should lower the overall maintenance burden by rallying behind a single unified solution.
18+
19+
### The status quo
20+
21+
Currently rustc has its own Emitter that encodes the theming properties of compiler diagnostics. It has handle all of the intricancies of terminal support (optional color, terminal width querying and adapting of output), layout (span and label rendering logic), and the presentation of different levels of information. Any tool that wants to approximate rustc's output for their own purposes, needs to use a third-party tool that diverges from rustc's output, like annotate-snippets or miette. Any improvements or bugfixes contributed to those libraries are not propagated back to rustc. Because the emitter is part of the rustc codebase, the barrier to entry for new contributors is artificially kept high than it otherwise would be.
22+
23+
annotate-snippets is already part of the rustc codebase, but it is disabled by default, doesn't have extensive testing and there's no way of enabling this output through cargo, which limits how many users can actually make use of it.
24+
25+
### The next 6 months
26+
27+
- annotate-snippets rendered output reaches full partity (modulo reasonable non-significant divergences) with rustc's output
28+
- rustc is fully using annotate-snippets for their output.
29+
30+
### The "shiny future" we are working towards
31+
32+
The outputs of rustc and cargo are fully using annotate-snippets, with no regressions to the rendered output. annotate-snippets grows its feature set, like support for more advanced rendering formats or displaying diagnostics with more than ASCII-art, independently of the compiler development cycle.
33+
34+
## Design axioms
35+
36+
*This section is optional, but including [design axioms][da] can help you signal how you intend to balance constraints and tradeoffs (e.g., "prefer ease of use over performance" or vice versa). Teams should review the axioms and make sure they agree. [Read more about design axioms][da].*
37+
38+
39+
- **Match rustc's output**: The output of annotate-snipepts should match rustc, modulo reasonable non-significant divergences
40+
- **Works for Cargo (and other tools)**: annotate-snippets is meant to be used by any project that would like "Rust-style" output, so it should be designed to work with any project, not just rustc.
41+
42+
43+
[da]: https://rust-lang.github.io/rust-project-goals/about/design_axioms.html
44+
45+
## Ownership and team asks
46+
47+
**Owner:** @estebank, @Muscraft
48+
49+
*Identify a specific person or small group of people if possible, else the group that will provide the owner*
50+
51+
This section defines the specific work items that are planned and who is expected to do them. It should also include what will be needed from Rust teams.
52+
53+
* Subgoal:
54+
* Describe the work to be done and use `` to mark "subitems".
55+
* Owner(s) or team(s):
56+
* List the owner for this item (who will do the work) or ![Help wanted][] if an owner is needed.
57+
* If the item is a "team ask" (i.e., approve an RFC), put ![Team][] and the team name(s).
58+
* Status:
59+
* List ![Help wanted][] if there is an owner but they need support, for example funding.
60+
* Other needs (e.g., complete, in FCP, etc) are also fine.
61+
62+
*Adjust the table below; some common examples are shown below.*
63+
64+
| Subgoal | Owner(s) or team(s) | Notes |
65+
| ----------------------------------------------- | ------------------------------ | ------------------------------ |
66+
| Reach output parity of rustc/annotate-snippets | | |
67+
| ↳ Port a subset of rustc's UI tests | @Muscraft | |
68+
| ↳ Make list of current unnaddressed divergences | @Muscraft | |
69+
| ↳ address divergences | @Muscraft | |
70+
| Initial use of annotate-snippets | | |
71+
| ↳ update annotate-snippets to latest version | | |
72+
| ↳ teach cargo to pass annotate-snippets flag | @estebank | |
73+
| ↳ add ui test mode comparing new output | | |
74+
| ↳ switch default nightly rustc output | | |
75+
| Production use of annotate-snippets | | |
76+
| ↳ switch default rustc output | | |
77+
| ↳ release notes | | |
78+
| ↳ switch ui tests to only check new output | | |
79+
| ↳ dedicated reviewer | ![Team][] [compiler] | @estebank will be the reviewer |
80+
| Standard reviews | ![Team][] [compiler] | |
81+
| Top-level Rust blog post inviting feedback |
82+
83+
## Frequently asked questions
84+
85+
### What do I do with this space?
86+
87+
*This is a good place to elaborate on your reasoning above -- for example, why did you put the design axioms in the order that you did? It's also a good place to put the answers to any questions that come up during discussion. The expectation is that this FAQ section will grow as the goal is discussed and eventually should contain a complete summary of the points raised along the way.*
88+
89+
[cargo-lints]: https://github.com/rust-lang/cargo/issues/12235

0 commit comments

Comments
 (0)