Optimize core::Zip::next_back()

[Dan54]

Fix #147704 by replacing next_back() calls in a loop with one call to nth_back().

This also modifies the safety conditions for the (unstable) TrustedRandomAccessNoCoerce trait by allowing calls to self.nth_back(n) and self.advance_back_by(n) after a call to self.__iterator_get_unchecked() provided they don't move the tail too far.

A grep found that the TrustedRandomAccessNoCoerce trait is implemented by the following structs:

• alloc::collections::vec_deque::{Iter<T>, IterMut<T>}
• alloc::vec::IntoIter<T>
• core::array::IntoIter<T, N>
• core::char::{CaseMappingIter, ToLowercase, ToUppercase}
• core::iter::{Cloned<I>, Copied<I>, Enumerate<I>, Fused<I>, Map<I, F>, Skip<I>, Zip<A, B>}
• core::ops::Range<_>
• core::range::IterRange<_>
• core::slice::{Chunks<T>, ChunksExact<T>, ChunksExactMut<T>, ChunksMut<T>, Iter<T>, IterMut<T>, RChunks<T>, RChunksExact<T>, RChunksExactMut<T>, RChunksMut<T>, Windows<T>}
• core::str::Bytes

I believe this is sound, as the implementations of advance_back_by() for the above do essentially the same thing as repeated next_back() calls, but better optimized.

If there is an issue, a partial fix could be implemented by using the new version as the default and specializing TrustedRandomAccessNoCoerce to use the current implementation.

[rustbot]

r? @joboet

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

[Dan54]

Just realised that if a.len() < b.len() then a.next_back() is called before equalizing the lengths. I'm writing a quick fix.

[hkBst]

While this is true, I'm not sure what it's doing here.

[Dan54]

Point 3 of TrustedRandomAccess's safety requirements says (paraphrased) that you can't use next_back() to move the tail to an element that has already been returned by __iterator_get_unchecked(). This extends that requirement to calls to nth_back() and advance_back_by().

[hkBst]

This tests for the ordering of calls to the constituent iterators of a Zip, but I don't think that ordering is specified, nor do I think it should be...

[Dan54]

I didn't want to break anything, but if the call order is unspecified then we can get cleaner code here, and faster code for nth() and nth_back(), so I've removed the test.

[joboet]

I think this is fine, but
r? @the8472
because of the interaction with the TrustedRandomAccessNoCoerce specialisation.