Detect when user tries to write Iterator that incorrectly borrows from Self and would need GATs

[estebank]

Code

struct Data {
    v: Vec<i32>,
}

impl Iterator for Data {
    type Item = &[i32];
    fn next(&mut self) -> Option<Self::Item> {
        let mut a = 0;
        let mut b = 0;
        Some(&self.v[a..b])
    }
}

fn main() {}

Current output

error[E0637]: `&` without an explicit lifetime name cannot be used here
 --> src/main.rs:6:17
  |
6 |     type Item = &[i32];
  |                 ^ explicit lifetime name needed here

Desired output

error[E0637]: `&` without an explicit lifetime name cannot be used here
 --> src/main.rs:6:17
  |
6 |     type Item = &[i32];
  |                 ^ explicit lifetime name needed here
note: associated type `Iterator::Item` is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type, so `Data` should be declared with a lifetime
note: you can't create an `Iterator` that borrows each `Item` from itself, as it doesn't use Generic Associated Types, but you can instead create a new type that borrows `Data` and implement `Iterator` for that type: <LINK TO EXAMPLE>

Rationale and extra context

No response

Other cases

No response

Rust Version

1.78.0

Anything else?

Taken from https://users.rust-lang.org/t/lifetime-error-from-iterator-with-its-item-as-a-reference/108863

[pacak]

I'll give it a go. So far managed to implement something that detects this condition.

[estebank]

@pacak great!

I wonder if we should make the first note something like

note: associated type `Iterator::Item` is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
   |
LL | impl Iterator for Data {
   |      --------     ---- this type doesn't have a lifetime parameter in its definition, but you could change it to have one
   |      |
   |      this trait doesn't have a lifetime parameter in its definition
LL |     type Item = &[i32];
   |          ^^^^ this associated type doesn't have a lifetime parameter in the trait definition

(that can be done by creating a MultiSpan and doing push_span_label on it, before feeding it to the span_note method)

You'd have to check whether Iterator or Data (or both) are local and then extend the label telling people "but you could change it". Furthermore, if both Iterator and Data are not local, maybe we shouldn't even emit the error and instead let the other error be the only one.

[pacak]

Check I made is basically if there's a problem with an anonymous lifetime and we are writing an impl core::iter::traits::iterator::Iterator for some datatype and we are "not in function" then report this error. trait rules ensures that Data is going to be local.

Basically works right now, remaining issues are cosmetic - need to figure out the easiest way to go from ast Ty to a textual representation, but if I reword things according to your last message - this is no longer a problem.

Will try to make a pull request tomorrow or later today.

[estebank]

I think there's an opportunity here for two separate improvements. The one you're making (explicit help for Iterator) and one for the general case (every other trait).

[pacak]

Yea, I was thinking about a generic version as well - looking up how associated datatype is defined in the trait and complaining. That's going to be later.