`iter_without_into_iter` suggests doubly incorrect `IntoIter` type

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

Start with the iter_without_into_iter lint and reproduce the supplied nested-module example. Check the generated IntoIter type path and lifetime handling, then add coverage for the reported cases; done means the suggestion is valid or the lint does not trigger when the iterator type cannot be named safely.