Repository navigation
Improve E0599 for missing trait bounds (where clauses) #61661
Copy link
Copy link
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-suggestion-diagnosticsArea: Suggestions generated by the compiler applied by `cargo fix`Area: Suggestions generated by the compiler applied by `cargo fix`D-confusingDiagnostics: Confusing error or lint that should be reworked.Diagnostics: Confusing error or lint that should be reworked.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
For the following example:
struct Foo<T> {
t: T,
}
struct Inner {
i: u8,
}
trait Bar {
fn bar(&self);
}
impl<T> Bar for Foo<T> where T: Clone {
fn bar(&self) {
println!("x");
}
}
fn main() {
let foo = Foo { t: Inner { i: b'i' } };
foo.bar();
}The error message is:
error[E0599]: no method named `bar` found for type `Foo<Inner>` in the current scope
--> src/main.rs:21:9
|
1 | struct Foo<T> {
| ------------- method `bar` not found for this
...
21 | foo.bar();
| ^^^
|
= note: the method `bar` exists but the following trait bounds were not satisfied:
`Foo<Inner> : Bar`
= help: items from traits can only be used if the trait is implemented and in scope
= note: the following trait defines an item `bar`, perhaps you need to implement it:
candidate #1: `Bar`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0599`.
error: Could not compile `playground`.
To learn more, run the command again with --verbose.
Foo<T> does actually implement Bar, and this makes the suggestions from the compiler misleading in this case: there is already an implementation for Foo<T> : Bar, and Bar is already in scope. It would be much more helpful if the compiler could suggest the trait bounds necessary to satisfy the requirement.
This seems very similar to what @estebank suggested in #9082 (comment).
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-suggestion-diagnosticsArea: Suggestions generated by the compiler applied by `cargo fix`Area: Suggestions generated by the compiler applied by `cargo fix`D-confusingDiagnostics: Confusing error or lint that should be reworked.Diagnostics: Confusing error or lint that should be reworked.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
[-]E0599[/-][+]Improve E0599 for missing trait bounds (where clauses)[/+]estebank commentedon Feb 18, 2020
Would the following be enough of an improvement?
djc commentedon Feb 18, 2020
This is a great improvement! In this context, the latter three lines are somewhat confusing:
Since they actually don't apply for this case.
Also, it might help to elaborate the lines before that, maybe an explicit mention of
<Foo<Inner> as Bar>::bar()can be thrown in?estebank commentedon Feb 18, 2020
What do you think of the following output?
I'll look into removing the last few lines as I agree that they are somewhat misleading here and obscure the solution, but we have to make sure we don't actually hide information useful for other cases with different underlying problems.
djc commentedon Feb 18, 2020
Yeah, this would be even better. I still think it would be nice to specifically call out
Barsomewhere/somehow as the provider ofbar()and the implementer specifying the trait bound (though it doesn't need the full location treatment).estebank commentedon Feb 18, 2020
What about this?
djc commentedon Feb 18, 2020
I find the four separate span blocks a bit distracting. I would opt for something like this:
On the other hand, a span block pointing to the
impl Bar for Foo<Inner>might be useful.estebank commentedon Feb 19, 2020
The current output in the PR looks like this
I'm a bit hesitant about removing spans at this point. It might be true that changing it to the following could be a good idea, but I'm not sure:
djc commentedon Feb 20, 2020
Let's see if we can get some wisdom from the crowd.
Rollup merge of rust-lang#69255 - estebank:e0599-details, r=varkor
Rollup merge of rust-lang#69255 - estebank:e0599-details, r=varkor
Auto merge of #69255 - estebank:e0599-details, r=varkor