Skip to content

"implement this trait" suggestions should only list traits for which that is actually legal #21420

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
huonw opened this issue Jan 20, 2015 · 1 comment · Fixed by #21675
Closed
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-trait-system Area: Trait system

Comments

@huonw
Copy link
Member

huonw commented Jan 20, 2015

E.g.

fn main() {
    1us.is_empty();
}
<anon>:2:9: 2:19 error: type `usize` does not implement any method in scope named `is_empty`
<anon>:2     1us.is_empty();
                 ^~~~~~~~~~
<anon>:2:19: 2:19 help: methods from traits can only be called if the trait is implemented and in scope; the following traits define a method `is_empty`, perhaps you need to implement one of them:
<anon>:2:19: 2:19 help: candidate #1: `core::slice::SliceExt`
<anon>:2:19: 2:19 help: candidate #2: `core::slice::SliceExt`
<anon>:2:19: 2:19 help: candidate #3: `core::str::StrExt`
<anon>:2:19: 2:19 help: candidate #4: `core::str::StrExt`
<anon>:2:19: 2:19 help: candidate #5: `collections::slice::SliceExt`
<anon>:2:19: 2:19 help: candidate #6: `collections::slice::SliceExt`
<anon>:2:19: 2:19 help: candidate #7: `collections::slice::SliceExt`
<anon>:2:19: 2:19 help: candidate #8: `collections::str::StrExt`
<anon>:2:19: 2:19 help: candidate #9: `collections::str::StrExt`
<anon>:2:19: 2:19 help: candidate #10: `collections::str::StrExt`

(The repetition is #21405.)

However, all of these are useless: because one cannot implement them for usize anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external.

cc @nikomatsakis

@huonw huonw added A-diagnostics Area: Messages for errors, warnings, and lints A-trait-system Area: Trait system labels Jan 20, 2015
@nikomatsakis
Copy link
Contributor

Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for usize if another type parameter were local, though not with the current orphan rules. Nonetheless, it might be good to just screen them out anyway, as it is unlikely to be what you plan to do.

huonw added a commit to huonw/rust that referenced this issue Jan 27, 2015
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.

The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).

Closes rust-lang#21420.
huonw added a commit to huonw/rust that referenced this issue Feb 3, 2015
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.

The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).

Closes rust-lang#21420.
bors added a commit that referenced this issue Feb 3, 2015
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.

The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).

Closes #21420.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-trait-system Area: Trait system
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants