about summary refs log tree commit diff
path: root/library/core/tests/iter.rs
AgeCommit message (Collapse)AuthorLines
2021-01-21library/core/test/iter.rs split attempt 2Daniel Conley-3681/+0
2021-01-19Stop `fold` at first None when iterator yieldMara Bos-0/+12
2021-01-19Fix intersperse_foldLzu Tao-0/+29
2021-01-16Rollup merge of #80670 - the8472:fix-zip-trusted-random-access-composition, ↵Mara Bos-0/+21
r=m-ou-se TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips I found this while working on improvements for TRA. After partially consuming a Zip adapter and then wrapping it into another Zip where the adapters use their `TrustedRandomAccess` specializations leads to the outer adapter returning elements which should have already been consumed. If the optimizer gets tripped up by the addition this might affect performance for chained `zip()` iterators even when the inner one is not partially advanced but it would require more extensive fixes to `TrustedRandomAccess` to communicate those offsets earlier. Included test fails on nightly, [playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=24fa1edf8a104ff31f5a24830593b01f)
2021-01-04TrustedRandomAaccess spec composes incorrectly for nested iter::ZipsThe8472-0/+21
After partially consuming a Zip adapter and then wrapping it into another Zip where the adapters use their TrustedRandomAccess specializations leads to the outer adapter returning elements which should have already been consumed.
2020-12-31Add Iterator::intersperse_withLukas Lueg-0/+30
2020-12-30Add Iterator::intersperseJonas Schievink-0/+82
2020-11-30Make ui test that are run-pass and do not test the compiler itself library testsChristiaan Dirkx-0/+12
2020-11-23Add Peekable::peek_mutLukas Lueg-0/+11
2020-10-06Test with non-fused iteratorsTim Vermeulen-4/+41
2020-10-05Add testsTim Vermeulen-0/+66
2020-10-01Rollup merge of #76909 - timvermeulen:advance_by, r=AmanieuDylan DPC-0/+60
Add Iterator::advance_by and DoubleEndedIterator::advance_back_by This PR adds the iterator method ```rust fn advance_by(&mut self, n: usize) -> Result<(), usize> ``` that advances the iterator by `n` elements, returning `Ok(())` if this succeeds or `Err(len)` if the length of the iterator was less than `n`. Currently `Iterator::nth` is the method to override for efficiently advancing an iterator by multiple elements at once. `advance_by` is superior for this purpose because - it's simpler to implement: instead of advancing the iterator and producing the next element you only need to advance the iterator - it composes better: iterators like `Chain` and `FlatMap` can implement `advance_by` in terms of `advance_by` on their inner iterators, but they cannot implement `nth` in terms of `nth` on their inner iterators (see #60395) - the default implementation of `nth` can trivially be implemented in terms of `advance_by` and `next`, which this PR also does This PR also adds `DoubleEndedIterator::advance_back_by` for all the same reasons. I'll make a tracking issue if it's decided this is worth merging. Also let me know if anything can be improved, this went through several iterations so there might very well still be room for improvement (especially in the doc comments). I've written overrides of these methods for most iterators that already override `nth`/`nth_back`, but those still need tests so I'll add them in a later PR. cc @cuviper @scottmcm @Amanieu
2020-09-21fmtAlexis Bourget-5/+7
2020-09-21move 'test zip ...' testsAlexis Bourget-0/+95
2020-09-20Add advance_by and advance_back_byTim Vermeulen-0/+60
2020-09-19Use `T::BITS` instead of `size_of::<T> * 8`.Mara Bos-1/+1
2020-08-19Use min_specialization in libcoreMatthew Jasper-0/+97
2020-07-27mv std libs to library/mark-0/+3127