Clarify -Z help output and note rustc flags#17150
Conversation
Updates the -Z help output per the design proposed in rust-lang#17145: clarifies these are cargo flags, reformats the channel warning to rustc diagnostic style, and adds a note pointing to rustc -Zhelp for rustc flags.
rustbot
added
A-cli
|
Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @ehuss (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
Why was this reviewer chosen?The reviewer was selected based on:
|
|
If we move forward with this, please use annotate snippets for the notes/warns, rather than attempting to imitate at. |
ehuss
added
S-waiting-on-author
Per @epage's feedback, use annotate-snippets (Level::WARNING with Level::HELP elements via print_report, and shell().note() for the rustc note) instead of manually imitating the warn:/help:/note: diagnostic style with drop_println!. Changes: - Warning + help messages now use Level::WARNING.secondary_title() with Level::HELP.message() elements via print_report (stderr) - The rustc -Zhelp note now uses shell().note() which internally uses annotate-snippets Level::NOTE (stderr) - The 'See https://...' line stays on stdout via drop_println! - Updated stdout.term.svg to remove the note (now on stderr) - Added stderr.term.svg with the expected note rendering - Updated the test to check stderr against the new SVG
Align the print_report call with the existing style used elsewhere in cli.rs (e.g. the alias shadowing warnings): secondary_title and element calls chained on the same line, without trailing commas inside element().
- Use str! with [NOTE] placeholder for stderr instead of SVG file (simpler and matches the snapbox pattern used elsewhere) - Fix compilation: print_zhelp returns () so use 'let _ =' for print_report/note calls instead of ? operator
Per @epage's feedback, use annotate-snippets (Level::WARNING with Level::HELP elements via print_report) for the warn:/help: messages instead of manually imitating the diagnostic style. The note about rustc -Zhelp stays as plain text on stdout via drop_println! since it's an informational pointer, not a diagnostic. This also restores the original stdout.term.svg and test expectations.
There was a problem hiding this comment.
style: apply rustfmt to print_zhelp
While we prefer small commits, what is more important is for the commits to be atomic, reflecting how the code should be reviewed and merged and not how it was developed.
If you decide to go for multiple commits, that could look like
- a commit for just adding "cargo"
- a commit for each re-arrangement of text, if needed
- a commit for changing direct text to annotate snippets
- any new parts of annotate snippets added
| } | ||
| drop_println!( | ||
| gctx, | ||
| "\nSee https://doc.rust-lang.org/nightly/cargo/reference/unstable.html \ |
There was a problem hiding this comment.
At least at #17145 (comment), I was suggesting moving the "See" above the use of annotate-snippets. Is there a reason it was kept here?
| "\nSee https://doc.rust-lang.org/nightly/cargo/reference/unstable.html \ | ||
| for more information about these flags." | ||
| for more information about these flags.\n\n\ | ||
| note: to see rustc unstable features, run `rustc -Zhelp`" |
There was a problem hiding this comment.
I would expect this note to either be moved to gctx.shell().note or annotate snippets
4 participants
Updates the
-Z helpoutput per the design @epage proposed in #17145.warn:/help:diagnostic stylerustc -Zhelpfor rustc unstable flagsCloses #17145