Uh oh!
There was an error while loading. Please reload this page.
Resolve inconsistency in error messages between "parameter" and "variable". - #60037
Conversation
| | | ||
| 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.
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...
Centril
commented
Apr 17, 2019
Niko is too busy with other things... ;) r? @estebank |
estebank
commented
Apr 17, 2019
@bors r+ rollup r=estebank |
bors
commented
Apr 17, 2019
📌 Commit 5f70559 has been approved by |
bors
commented
Apr 17, 2019
💡 This pull request was already approved, no need to approve it again.
|
bors
commented
Apr 17, 2019
📌 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