-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
"is not an iterator" diagnostic through blanket implementation, when the type is actually an iterator but is missing a marker #127511
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
progval
added
A-diagnostics
Area: Messages for errors, warnings, and lints
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Jul 9, 2024
Similar to #124802? |
Here is a slightly smaller reproduction that only uses trait Missing {}
trait HasMethod {
fn foo(self);
}
impl<T: Iterator + Missing> HasMethod for T {
fn foo(self) {}
}
fn get_iter() -> impl Iterator {
// any Iterator impl will do
core::iter::once(())
}
fn main() {
get_iter().foo();
}
|
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Nov 9, 2024
Rollup merge of rust-lang#132760 - dianne:iter-into-iter, r=lcnr Don't suggest `.into_iter()` on iterators This makes the the suggestion to call `.into_iter()` only consider unsatisfied `Iterator` bounds for the receiver type itself. That way, it ignores predicates generated by trying to auto-ref the receiver (the result of which usually won't implement `Iterator`). Fixes rust-lang#127511 Unfortunately, the error in that case is still confusing: it labels `Iterator` as an unsatisfied bound because `&impl Iterator: Iterator` can't be satisfied, despite that not being required or helpful. I'd like to handle that in a separate PR. ~~I'm hoping fixing rust-lang#124802 will fix it too.~~ It doesn't look connected to that issue. Still, I think it'd be clearest to visually distinguish unsatisfied predicates from different attempts at `pick_method`; I'll make a PR for that soon.
mati865
pushed a commit
to mati865/rust
that referenced
this issue
Nov 12, 2024
Don't suggest `.into_iter()` on iterators This makes the the suggestion to call `.into_iter()` only consider unsatisfied `Iterator` bounds for the receiver type itself. That way, it ignores predicates generated by trying to auto-ref the receiver (the result of which usually won't implement `Iterator`). Fixes rust-lang#127511 Unfortunately, the error in that case is still confusing: it labels `Iterator` as an unsatisfied bound because `&impl Iterator: Iterator` can't be satisfied, despite that not being required or helpful. I'd like to handle that in a separate PR. ~~I'm hoping fixing rust-lang#124802 will fix it too.~~ It doesn't look connected to that issue. Still, I think it'd be clearest to visually distinguish unsatisfied predicates from different attempts at `pick_method`; I'll make a PR for that soon.
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
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Code
(inspired by rayon's
ParallelBridge
)playground
Current output
Desired output
The same error there is when removing the
.map()
Rationale and extra context
The error indicated the type does not implement
Iterator
, even though it does andSend
is the one that is missing.Other cases
No response
Rust Version
Anything else?
No response
The text was updated successfully, but these errors were encountered: