Resolve inconsistency in error messages between "parameter" and "variable". #60037
Conversation
rust-highfive
added
the
S-waiting-on-review
| @@ -23,7 +23,7 @@ error[E0401]: can't use generic parameters from outer function | |||
| --> $DIR/resolve-type-param-in-item-in-trait.rs:23:28 | |||
| | | |||
| LL | trait TraitC<A> { | |||
| | - type variable from outer function | |||
| | - type parameter from outer function | |||
There was a problem hiding this comment.
The diagnostic makes no sense here as there's no outer function, just an outer trait.
There was a problem hiding this comment.
I believe there's already a ticket for this case.
There was a problem hiding this comment.
@estebank can you cc it perhaps?
There was a problem hiding this comment.
Thanks; I skimmed those issues and they all seem a bit different. I think the fix for this one is to customize the diagnostic based on what the parent def_id refers to... e.g. say "function" if it is one, and "trait" if it is one...
|
Niko is too busy with other things... ;) r? @estebank |
|
@bors r+ rollup r=estebank |
|
📌 Commit 5f70559 has been approved by |
bors
added
S-waiting-on-bors
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit 5f70559 has been approved by |
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
Rollup of 4 pull requests Successful merges: - #59908 (Re-export core::str::{EscapeDebug, EscapeDefault, EscapeUnicode} in std) - #59984 (Remove collection-specific `with_capacity` documentation from `std::collections`) - #60036 (Remove nrc from toolstate pings) - #60037 (Resolve inconsistency in error messages between "parameter" and "variable".) Failed merges: r? @ghost
The inconsistency was introduced in 104fe1c (#33619), when a label saying
type variablewas added to an error with a message talking abouttype parameters.Given that
parameteris 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