Lint `.into_iter()` if that only forwards to `.iter()`

[oli-obk]

cc @bluss

Types like [T; N] don't implement IntoIter themselves, but instead provide it through their Deref<Target=[T]> impl, which is simply a wrapper around calling .iter().

.into_iter() suggests that some ownership transfer is going on, if that is not the case .iter() should be used.

[clarfonthey]

So to clarify this, would this mean calling .into_iter() on a reference? Because that's what &[T]'s into_iter does.

[oli-obk]

Yea. Some care needs to be taken to ensure that the for loop desugaring is not linted

[bluss]

That should be simple, the for loop uses IntoIterator::into_iter(<expr>) and this lint should apply exactly to where <expr>.into_iter() does not compile if it were replaced with the former (because of method resolution difference).

[clarfonthey]

rust-lang/rust#49000 also makes it clear that this lint will also help us detect incorrect usages of into_iter() on slices, which currently forwards to iter() but would forward to a dedicated into_iter() if it were provided.

[cuviper]

There are actually two ways that array.into_iter() can resolve to slice iteration:

• using impl<'a, T> IntoIterator for &'a [T; $N], for $N in 0..=32 (possibly with autoref)
• unsize to [T], then autoref using impl<'a, T> IntoIterator for &'a [T]
  • note: this is an explicit final step in probe.rs -- arrays don't actually implement Deref!

I think we only need to lint cases that would be intercepted by IntoIterator for [T; N]. Something like array_ref.into_iter() should have no problem to continue using IntoIterator for &'a [T; N]. But it should also be fine to suggest array_ref.iter() in that case anyway.

I was investigating how I might implement such a lint in the compiler, but a library-specific lint like this is probably not a great idea to hard-code. Doing it in clippy seems safer, even though it might not get as much reach. For rustc I was thinking that src/librustc_typeck/check/method/confirm.rs might be the right place to check the method resolution. Can you suggest where I might do similar in clippy?

[oli-obk]

I think the best place would be https://github.com/rust-lang-nursery/rust-clippy/blob/c5559c1648b0810e5dff9f94935fba52e9a9e833/clippy_lints/src/methods.rs#L691 which contains all our method call lints

[tamird]

@cuviper any plans to return to this? rust-lang/rust#49000 is quite useful, and seems blocked on this.

[cuviper]

I do, yes. I managed to prototype the changes already -- I'll try to get back to clean that up and post a PR for comment soon.

[kennytm]

I'm not sure if this has been taken into account by #1565 (comment) —

If it is not too difficult to do, I suggest we also lint (&mut [1, 2, 3]).into_iter() to call [1, 2, 3].iter_mut().

Complete list

Type	(&x).into_iter() → x.iter()	(&mut x).into_iter() → x.iter_mut()
[T; n]	✓	✓
[T]	✓	✓
Option<T>	✓	✓
Result<T, E>	✓	✓
Vec<T>	✓	✓
BTreeSet<T>	✓	❌
BTreeMap<K, V>	✓	✓
VecDeque<T>	✓	✓
LinkedList<T>	✓	✓
LinkedList<T>	✓	✓
BinaryHeap<T>	✓	❌
HashMap<K, V>	✓	✓
HashSet<T>	✓	❌
PathBuf	✓	❌
Path	✓	❌
std::sync::mpsc::Receiver	✓	❌
std::os::unix::net::UnixListener	incoming()	❌

If we disregard the chance of false positive, we could even check:

1. Explicit calls of x.into_iter() where into_iter comes from the trait IntoIterator, and

2. the adjusted type of x is a reference (&T or &mut T or &&&&&T), and

3. one of:

   • the method T::iter_mut exists and the adjusted type is &mut T (or &mut &mut &mut T), or
   • the method T::iter exists,

   and

4. the return type of T::iter_mut/T::iter is equivalent to <&T as IntoIterator>::IntoIter, then

5. We emit a lint suggesting to call x.iter_mut()/x.iter() instead.

[cuviper]

Sorry I haven't found the time for this, but I just rebased my branch and pushed it as-is, in case somebody else wants to take over. I haven't gone through to see if I covered all the cases @kennytm mentioned. I'll try to be responsive about questions of what I was thinking, since I didn't get around to writing many comments either.
https://github.com/cuviper/rust-clippy/tree/array-into_iter