-
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
Don't suggest .into_iter()
on iterators
#132760
Conversation
if let Some(iterator_trait) = self.tcx.get_diagnostic_item(sym::Iterator) | ||
&& self | ||
.type_implements_trait(iterator_trait, [ty], self.param_env) | ||
.must_apply_modulo_regions() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should not be necessary 🤔 why is the impl Iterator: Iterator
in the unsatisfied_predicates
. I feel like there's something bigger going on which likely also affects other diagnostics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, the reason is that unsatisfied_predicates
also contains all the unsatisfied predicates from auto-ref and the deref-steps, e.g.
trait Trait {
fn method(self)
}
trait Bound {}
impl<T: Bound> Trait for T {
fn method(self) {}
}
fn main() {
0u32.method()
}
results in
error[E0599]: the method `method` exists for type `u32`, but its trait bounds were not satisfied
--> src/main.rs:11:10
|
11 | 0u32.method()
| ^^^^^^ method cannot be called on `u32` due to unsatisfied trait bounds
|
note: the following trait bounds were not satisfied:
`&mut u32: Bound`
`&u32: Bound`
`u32: Bound
as you can see in the new error message for this issue, it's talking about the following unsatisfied obligations:
`&impl Iterator: Iterator`
`&impl Iterator: Missing`
`&mut impl Iterator: Missing`
`impl Iterator: Missing`
so instead of checking whether ty
implements iterator, modify is_iterator_predicate
to only trigger if the self-type of the iterator predicate is ty
itself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice catch! I was thinking along those lines for making that error less confusing, but I totally missed that it could be applied to is_iterator_predicate
too. it's much nicer now; thank you
79c6450
to
28df68f
Compare
28df68f
to
cea82ed
Compare
@bors r+ rollup |
…kingjubilee Rollup of 5 pull requests Successful merges: - rust-lang#132755 (Do not reveal opaques in the param-env, we got lazy norm instead) - rust-lang#132757 (Get rid of `check_opaque_type_well_formed`) - rust-lang#132760 (Don't suggest `.into_iter()` on iterators) - rust-lang#132778 (update io::Error::into_inner to acknowledge io::Error::other) - rust-lang#132780 (use verbose for path separator suggestion) r? `@ghost` `@rustbot` modify labels: rollup
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.
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.
…kingjubilee Rollup of 5 pull requests Successful merges: - rust-lang#132755 (Do not reveal opaques in the param-env, we got lazy norm instead) - rust-lang#132757 (Get rid of `check_opaque_type_well_formed`) - rust-lang#132760 (Don't suggest `.into_iter()` on iterators) - rust-lang#132778 (update io::Error::into_inner to acknowledge io::Error::other) - rust-lang#132780 (use verbose for path separator suggestion) r? `@ghost` `@rustbot` modify labels: rollup
This makes the the suggestion to call
.into_iter()
only consider unsatisfiedIterator
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 implementIterator
).Fixes #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 #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 atpick_method
; I'll make a PR for that soon.