Implement Iterator::last for vec::IntoIter

[thaliaarchi]

Avoid iterating everything when we have random access to the last element.

[rustbot]

r? @workingjubilee

rustbot has assigned @workingjubilee.
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

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[thaliaarchi]

I'm unsatisfied that this suppresses the Clippy diagnostic for vec::IntoIter, as I think it is still good advice. It would be somewhat imprecise for manual last implementations, though, in general.

[samueltardieu]

I'm unsatisfied that this suppresses the Clippy diagnostic for vec::IntoIter, as I think it is still good advice. It would be somewhat imprecise for manual last implementations, though, in general.

This removes the whole purpose of the test which is to check whether this would modify the drop order of the collection's elements. Could you maybe replace the let v = v.into_iter(); by let v = &mut v.into_iter() as &mut dyn DoubleEndedIterator<Item = S>;? This should make the lint trigger, and the drop order be checked.

[thaliaarchi]

I think making a custom DoubleEndedIterator just for the test would be more clear. Really, I just blessed the tests to get CI to pass for the sake of discussion.

Do you think it's fine that this case is no longer linted for vec::IntoIter<T>? On one hand, the forced drop is usually less desirable, but may be exactly what someone wants. Maybe the lint could be selected reenabled for this type and others similar? I could go either way.

[thaliaarchi]

I'm confused why you edited my comment. Perhaps you were grabbing the Markdown contents for a reply and edited it instead? I've reverted the edit and reproduce your comment below:

@samueltardieu commented 2025-04-14T14:02:22Z:

Do you think it's fine that this case is no longer linted for vec::IntoIter<T>? On one hand, the forced drop is usually less desirable, but may be exactly what someone wants. Maybe the lint could be selected reenabled for this type and others similar? I could go either way.

Independently from the Clippy lint, I wonder if your last() implementation conforms to the methods semantics, as described in the documentation of Iterator::last():

Consumes the iterator, returning the last element.

This method will evaluate the iterator until it returns None. While doing so, it keeps track of the current element. After None is returned, last() will then return the last element it saw.

For me, it implies that elements are dropped in order. So I'd say that if your change is accepted (and the documentation for Iterator::last() is updated), then it is fine for Clippy not to lint about Vec::IntoIter<_>::last(), as it would have nothing useful to suggest and to warn about.

[thaliaarchi]

I've now made a little wrapper iterator for the test to still exercise that same case, since it wasn't really intending to test the implementation details of vec::IntoIter. And I agree now that vec::IntoIter shouldn't trigger the lint anymore after this change.

[samueltardieu]

I'm confused why you edited my comment. Perhaps you were grabbing the Markdown contents for a reply and edited it instead?

Ooops, this is was not only unintentional but also unnoticed. Thanks for fixing this.