Batch of improvements to errors for new error format #33619
Conversation
|
r? @jroesch (rust_highfive has picked a reviewer for you, use r? to override) |
| span, | ||
| E0411, | ||
| "use of `Self` outside of an impl or trait"); | ||
| err = err.span_label(span, &format!("Used outside of impl or trait")); |
There was a problem hiding this comment.
Nit: this should probably not start w/ a capital letter
|
r=me with nit fixed |
| more than once at a time", | ||
| nl, new_loan_msg) | ||
| .span_label( | ||
| let mut err =struct_span_err!(self.bccx, new_loan.span, E0499, |
|
@bors r=nikomatsakis |
|
📌 Commit 65cb5f7 has been approved by |
|
⌛ Testing commit 65cb5f7 with merge 5ebe418... |
…ikomatsakis Batch of improvements to errors for new error format This is a batch of improvements to existing errors to help get the most out of the new error format. * Added labels to primary spans (^^^) for a set of errors that didn't currently have them * Highlight the source blue under the secondary notes for better readability * Move some of the "Note:" into secondary spans+labels * Fix span_label to take &mut instead, which makes it work the same as other methods in that set
| self.cmt_to_string(&err.cmt)), | ||
| format!("mut {}", snippet)); | ||
| db.span_label(span, | ||
| &format!("use `mut {}` here to make mutable", snippet)); |
There was a problem hiding this comment.
This replaced span_suggestion with span_label, which is undesirable. See #33691.
There was a problem hiding this comment.
We should chat about lint implications. For the actual error, moving it to a label text appears to improve readability "at a glance" of the errors. That said, we may want to distinguish them in some way that lints and autocorrection type tools can find and use them.
There was a problem hiding this comment.
I think span_suggestion should be used so that machines can read them, but it should be rendered like label for humans.
Resolve inconsistency in error messages between "parameter" and "variable". The inconsistency was introduced in 104fe1c (rust-lang#33619), when a label saying `type variable` was added to an error with a message talking about `type parameters`. Given that `parameter` is far more prevalent when referring to generics in the context of Rust, IMO it should be that in both the message and the label. r? @nikomatsakis or @estebank
This is a batch of improvements to existing errors to help get the most out of the new error format.