New lint: `iter_overeager_cloned` by pmnoxx · Pull Request #8203 · rust-lang/rus...

If the .last() is unwrap()ed or ?d, we could even suggest to .clone() that. Just a suggestion for extending the lint, this won't stop us from merging.

@llogiq That's a great suggestion.

I see: for Option<> / Result<>.
recv.cloned().unwrap()
could be
recv.unwrap().clone.

I see that cloned should be moved furthermost the chain as long as possible, not just for last.
For example here:

 vec.iter().cloned().filter(...).skip(5).take(10).last().unwrap()

That could be just written as

let val = vec.cloned().filter(...).skip(5).take(10).last().unwrap().clone()

This may even allow us to drop the clone() entirely, in some cases, when clone() is not needed.

It may be a good idea to propagate clone from before, to after

• last
• take
• skip
• next.
• unwrap
• filter // has lambda, so requires some more checks
• find.// has lambda,so requires some more checks
• map - vec.iter().cloned().map(|x|x.len()) <-- this probably doesn't need clone either.
• foreach - maybe? vec.iter().cloned().foreach_each(|x|println!{"{}", x)) <-- this doesn't need clone
• ... probably some others as well

map/for_each/try_foreach require detecting whenever lambda can accept reference instead

The question is, should each be a separate lint, or should they be combined together?

I think your example is a bit off, but otherwise full ack.

I'd be OK with multiple lints if there are useful distinctions to make. E.g. if one part of the check can have false positives, it would be a good idea to put that into a different nursery lint. Or if one part could reasonably be style and another perf. Otherwise, putting all the checks into one lint seems natural. One thing I that comes to mind is that we already have the needless_clone lint, so we could add cases where the cloned can be removed outright to that, making the rest early_iter_cloned or some such.

Again, I'm also OK if you restrict the scope of this PR and do a followup later. Have fun!