MCP: Flag to disable extended error info.

[Lokathor]

Proposal

A command line flag to suppress the "help" and/or "note" info in error messages. This would be distinct from "message-format=short" because the full main portion of the error would still print normally. Ideally this could be done for select error id codes the same as warnings can be picked individually, or with an "all" entry to disable all extra info on all errors.

// exact flag name to bikeshed

rustc -Zterse-errors=E0277,E0599

rustc -Zterse-errors=all

---

Motivation: Rustc will often provide too much help and note information. For example, if there's a trait missing from an argument to a function you get an error like this:

D:\dev\dmgrs>cargo run
   Compiling dmgrs v0.1.0 (D:\dev\dmgrs)
error[E0277]: the trait bound `Lexeme: chumsky::Parser<Lexeme, _>` is not satisfied
   --> src\parser.rs:143:22
    |
143 |         .then_ignore(Lexeme::Punct('!'))
    |          ----------- ^^^^^^^^^^^^^^^^^^ the trait `chumsky::Parser<Lexeme, _>` is not implemented for `Lexeme`
    |          |
    |          required by a bound introduced by this call
    |
    = help: the following other types implement trait `chumsky::Parser<I, O>`:
              <&'a T as chumsky::Parser<I, O>>
              <Arc<T> as chumsky::Parser<I, O>>
              <Box<T> as chumsky::Parser<I, O>>
              <BoxedParser<'a, I, O, E> as chumsky::Parser<I, O>>
              <Choice<(A_, B_, C_, D_, E_, F_, G_, H_, I_, J_, K_, L_, M_, N_, O_, P_, Q_, S_, T_, U_, V_, W_, X_, Y_, Z_), E> as chumsky::Parser<I, O>>
              <Choice<(B_, C_, D_, E_, F_, G_, H_, I_, J_, K_, L_, M_, N_, O_, P_, Q_, S_, T_, U_, V_, W_, X_, Y_, Z_), E> as chumsky::Parser<I, O>>
              <Choice<(C_, D_, E_, F_, G_, H_, I_, J_, K_, L_, M_, N_, O_, P_, Q_, S_, T_, U_, V_, W_, X_, Y_, Z_), E> as chumsky::Parser<I, O>>
              <Choice<(D_, E_, F_, G_, H_, I_, J_, K_, L_, M_, N_, O_, P_, Q_, S_, T_, U_, V_, W_, X_, Y_, Z_), E> as chumsky::Parser<I, 
O>>
            and 60 others
note: required by a bound in `then_ignore`
   --> C:\Users\Daniel\.cargo\git\checkouts\chumsky-651fb76526ac39e3\a0a67e4\src\lib.rs:790:12
    |
790 |         P: Parser<I, U, Error = Self::Error>,
    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `then_ignore`

That's 26 lines, and note that many of the lines are quite long so they might get wrapped to fit the terminal's width. It's so much information that the actual problem has probably scrolled up and out of the user's terminal.

For intermediate and advanced rust programmers, it's often enough to simply be told what kind of error happened, and where, and then it's obvious enough what went wrong. With all the help and note text suppressed we get a much shorter message that still conveys the problem to the programmer just fine:

D:\dev\dmgrs>cargo run
   Compiling dmgrs v0.1.0 (D:\dev\dmgrs)
error[E0277]: the trait bound `Lexeme: chumsky::Parser<Lexeme, _>` is not satisfied
   --> src\parser.rs:143:22
    |
143 |         .then_ignore(Lexeme::Punct('!'))
    |          ----------- ^^^^^^^^^^^^^^^^^^ the trait `chumsky::Parser<Lexeme, _>` is not implemented for `Lexeme`
    |          |
    |          required by a bound introduced by this call

This is not to say that the help and notes are never useful! However, they're oriented towards people who are newer to rust in general, or newer to a particular detail of rust (such as adding needing +'static bounds sometimes). Once you're familiar with a concept you'll still get errors, you'll just know what to do about them on your own, and you don't need the extra words filling up the terminal output.

Mentors or Reviewers

@estebank said this was a good enough idea for a proposal

Process

The main points of the Major Change Process are as follows:

• [x] File an issue describing the proposal.
• [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[oli-obk]

@rustbot second

[oli-obk]

@rustbot cancel (see zulip thread)

[apiraino]

@oli-obk if I correctly read your intent, I will rollback the label and put the MCP back to its initial state

@rustbot label -final-comment-period

[oli-obk]

Closing as there are alternatives (improving the existing errors) that we should explore first