new lint: iter_without_into_iter

[y21]

Closes #9736

A new lint that looks for iter (and iter_mut) method implementations without the type implementing IntoIterator for &Type.
Imo this seems rather pedantic, so I went with that, but I can be convinced to change it to style like the linked issue asked for.
Writing a machine applicable suggestion seems a bit tricky and tedious, so for now this relies on the user adding remaining lifetimes.

changelog: new lint: iter_without_into_iter

[rustbot]

r? @Jarcho

(rustbot has picked a reviewer for you, use r? to override)

[bors]

☔ The latest upstream changes (presumably #11556) made this pull request unmergeable. Please resolve the merge conflicts.

[Jarcho]

Just two minor things, otherwise this looks good. Feel free to squash everything down.

[Jarcho]

Thank you. @bors r+

[bors]

📌 Commit 330ebbb has been approved by Jarcho

It is now in the queue for this repository.

[bors]

⌛ Testing commit 330ebbb with merge d38fa1a...

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: Jarcho
Pushing d38fa1a to master...

[Kixunil]

The reason I picked style is that not doing this causes for x in &container to not work. Also do I understand correctly that this doesn't do the opposite - suggest iter() when there's IntoIter for &T?

[y21]

Right, this doesn't lint the opposite, must have missed that when reading the issue 😅. Could reopen the issue then, and mention that only the lint for a missing IntoIterator impl is implemented now

[Kixunil]

Yes please, reopen.

[y21]

I can't do that since I'm not on the team and don't have perms for it. I think you as the issue creator can do it though? Or is that different when the issue is autoclosed by a PR? 🤔 I'm not sure.
If not, maybe we need a new issue for it, or someone else with permissions can do it

[y21]

Regardless, I'm going to try to implement the other version later today and submit another PR for it

[Kixunil]

@y21 I couldn't, thanks anyway!

[lopopolo]

Hey folks, the suggested fix this lint produces doesn't compile in at least 5 ways on some toy code I've tried:

• clippy::iter_without_into_iter suggestion does not compile #11692

It looks like this PR doesn't include any tests for the suggested code to ensure that it compiles.

[y21]

As I've said in the issue, it's expected that the current suggestion does not compile (it even has a comment up top), and has the unspecified applicability. It's mostly meant as a nudge in the right direction to the user, not an autofix.
So testing the suggestion doesn't really make sense since we know it won't compile in any case.

You do make some valid points in the issue and at least some trivial things should have been included in the suggestion, and I'll try to look into improving the suggestion here a bit later.

[lopopolo]

As I've said in the issue, it's expected that the current suggestion does not compile (it even has a comment up top), and has the unspecified applicability. It's mostly meant as a nudge in the right direction to the user, not an autofix.
So testing the suggestion doesn't really make sense since we know it won't compile in any case.

ahh gotcha. Thanks for clarifying @y21. I didn't read this PR thread or the code. I only left a comment here to cross-post my bug to make sure the rule author (you 😄) came across it.

FWIW, that lack of machine applicability is not made clear in the warning output. Based on my familiarity with clippy's other suggestions, I expected to be able to copy and paste:

warning: `iter` method without an `IntoIterator` impl for `&Links<T>`
  --> src/link.rs:68:5
   |
68 | /     pub fn iter(&self) -> Iter<'_, Link<T>, usize> {
69 | |         self.registry.iter()
70 | |     }
   | |_____^
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#iter_without_into_iter
note: the lint level is defined here
  --> src/lib.rs:11:9
   |
11 | #![warn(clippy::pedantic)]
   |         ^^^^^^^^^^^^^^^^
   = note: `#[warn(clippy::iter_without_into_iter)]` implied by `#[warn(clippy::pedantic)]`
help: consider implementing `IntoIterator` for `&Links<T>`
   |
33 +
34 + impl IntoIterator for &Links<T> {
35 +     type IntoIter = hashbrown::hash_map::Iter<'_, link::Link<T>, usize>;
36 +     type Iter = (&link::Link<T>, &usize);
37 +     fn into_iter() -> Self::IntoIter {
38 +         self.iter()
39 +     }
40 + }
   |