`iter_without_into_iter` suggests doubly incorrect `IntoIter` type

[samueltardieu]

Summary

When suggesting an implementation of IntoIterator, iter_without_into_iter suggests using a type for IntoIter which has two problems:

• If the type has been defined in the current crate, the path given is from the top-level of the create, without prefixing it with crate::, making it invalid if we happen to be in a module.
• If the type contains lifetimes, they will be copied verbatim even if they make no sense at the place of the suggestion. I think that in this case the lint should not trigger.

Reproducer

I tried this code:

#![warn(clippy::iter_without_into_iter)]
#![allow(unused)]

pub mod inner {
    pub struct S;
    impl S {
        pub fn iter(&self) -> I {
            todo!()
        }
    }

    pub struct I<'a> {
        field: &'a ()
    }
    impl Iterator for I<'_> {
        type Item = ();
        fn next(&mut self) -> Option<Self::Item> {
            todo!()
        }
    }
}

fn main() {}

The suggestion is:

help: consider implementing `IntoIterator` for `&S`
  |
6 ~     
7 + impl IntoIterator for &S {
8 +     type Item = ();
9 +     type IntoIter = inner::I<'_>;
10+     fn into_iter(self) -> Self::IntoIter {
11+         self.iter()
12+     }
13+ }

inner::I<'_> is invalid, because of the lifetime, and because it should be either I or crate::inner::I.

Version

rustc 1.86.0-nightly (8361aef0d 2025-01-14)
binary: rustc
commit-hash: 8361aef0d7c29b1501a316a208ed84cd8a2ae5da
commit-date: 2025-01-14
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.6

Additional Labels

@rustbot label +I-suggestion-causes-error

[y21]

For what it's worth, the literal suggestion not being valid is a bit of an expected/known issue and the suggestion is explicitly marked as such:

rust-clippy/clippy_lints/src/iter_without_into_iter.rs

Lines 179 to 181 in 2280b8a

	// Just like iter_without_into_iter, this suggestion is on a best effort basis
	// and requires potentially adding lifetimes or moving them around.
	Applicability::Unspecified,

So the current suggestion is more like a hint. I suppose we can always improve the suggestion a little bit, but I feel like getting a proper machine applicable suggestion, or even one that compiles (if that's the goal) here feels like it's not really feasible because there's just way too many subtle cases to consider, or would probably end up complicating the code a ton.

If the type contains lifetimes, they will be copied verbatim even if they make no sense at the place of the suggestion. I think that in this case the lint should not trigger.

Why shouldn't it lint in that case? It does require some slight adjustments and adding a lifetime to the impl but it still feels like the idea of the lint (getting library authors to provide a convenient/idiomatic iterator API) is still applicable in those cases.

[samueltardieu]

Ok, I see what you mean, even though I feel like Clippy is trying to tell me what to do when it gives an example. I would have preferred to have it maybe tell "something along the lines of:" to make it clear that it was not sure about the result. But I can live with this.