Consider side effects when rewriting iterator behaviors

[profetia]

Closes #9191
Closes #14444
Closes #8055

Adds a new helper to partly check for side effects by recursively checking if the iterator type contains closures with mutable captures.

changelog: [double_ended_iterator_last] fix FP when iter has side effects
changelog: [needless_collect] fix lint not consider side effects

[rustbot]

r? @Jarcho

rustbot has assigned @Jarcho.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Jarcho]

I don't see why this needs to be limited to checking only closure captures. Any iterator that contains a mutable reference has the same issue.

I think any iterator type containing one of the following would need to not lint:

• A mutable reference/pointer
• A reference/pointer to a non-Freeze type
• A PhantomData type containing any of the previous.

[profetia]

Updated. Now these will also be covered.

[profetia]

This CI failure does not seem to be my problem. Any ideas?

[samueltardieu]

This CI failure does not seem to be my problem. Any ideas?

I've restarted it to see if it's intermittent (we'll have to fix it anyway) or not. For reference, here is the failing version.

Edit: this does not look like it is intermittent.

[profetia]

Thanks to #14514, the CI is working now.

[profetia]

r? clippy

[Manishearth]

r? @samueltardieu

[rustbot]

samueltardieu is on vacation.

Please choose another assignee.

[Jarcho]

Looks like I didn't actually post a review last time I looked at this. Sorry about the wait.

[Manishearth]

r? Jarcho

sending it back, then 😄

[Jarcho]

For the util name something like has_non_owning_mutable_access would be a more precise as to what it's checking for.

[profetia]

I pushed a refactored version. The uitest passed but the compiler panicked in dogfood, can you maybe give me some help?

[Jarcho]

You'll need to keep track of what types have been seen as you recurse. Right now walking a type which recurses via PhantomData will overflow the stack. e.g.:

struct Foo<T> {
    inner: T,
    marker: core::marker::PhantomData<Self>,
}
impl<T: Iterator> Iterator for Foo<T> {
    type Item = T::Item;
    fn next(&mut self) -> Option<Self::Item> {
        self.inner.next()
    }
}

fn main() {
    Foo {
        inner: [].iter(),
        marker: core::marker::PhantomData,
    }.collect::<Vec<&i32>>().len();
}

[Jarcho]

Just one last extension to handle any known projections and this should be good.

[Jarcho]

Thank you.