Skip to content

add --message-format short option #42653

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
vitiral opened this issue Jun 14, 2017 · 4 comments
Closed

add --message-format short option #42653

vitiral opened this issue Jun 14, 2017 · 4 comments
Assignees
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.

Comments

@vitiral
Copy link
Contributor

vitiral commented Jun 14, 2017

I copied this from rust-lang/cargo#4165 at @alexcrichton's request

--message-format currently has the following options:

--message-format FMT         Error format: human, json [default: human]

I would like an additional option to be added: short. Other possible names:

  • brief
  • oneline

I've been programming in rust for the better part of a year now. The compiler has been my friend and mentor through this time, and a big part of that has been the fantastic human readable error messages. Thank you so much for them!

However, I have gotten much more familiar with the language and my common mistakes. Therefore I rarely need the error messages to be so long (sometimes they are longer than 10-15 lines!). Normally I just need the compiler to give the me the file, line/col number and name of the error and I can spot it myself very quickly.

For an experienced programmer, the option of a shorter format would make finding errors much more ergonomic.

The following pipe does roughly what I want, although it would be nice if it was all on one line and the path:line:col was at the beginning

# cargo test |& rg "(error\[\w+\])|(^\s+--> \w+/\w+)" -N --color never
error[E0061]: this function takes 2 parameters but 3 parameters were supplied
   --> src/user/tests.rs:186:37
error[E0061]: this function takes 2 parameters but 3 parameters were supplied
   --> src/export.rs:133:51
error[E0061]: this function takes 2 parameters but 3 parameters were supplied
   --> src/export.rs:139:37
error[E0063]: missing field `revision` in initializer of `export::ArtifactData`
   --> src/export.rs:149:20

Thanks!

@Mark-Simulacrum Mark-Simulacrum added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. labels Jun 23, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 27, 2017
@GuillaumeGomez
Copy link
Member

I'll do it in the next days or so.

@GuillaumeGomez GuillaumeGomez self-assigned this Sep 5, 2017
@GuillaumeGomez
Copy link
Member

@dataf3l
Copy link

dataf3l commented Feb 1, 2018

I think this is very important.

@GuillaumeGomez
Copy link
Member

?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants