about summary refs log tree commit diff
path: root/src/libcore/iter
AgeCommit message (Collapse)AuthorLines
2019-05-30Stabilize iter_nth_back featureLzu Tao-4/+1
2019-05-29Add custom nth_back for SkipAndrea Corradi-0/+14
2019-05-29Rollup merge of #60542 - timvermeulen:step_sub_usize, r=scottmcmMazdak Farrokhzad-0/+35
Add Step::sub_usize Required for #54054. I'm aware that the `Step` trait needs a rework, but this still seems like a reasonable addition? This currently doesn't compile because Chalk contains a type that implement this trait, and this is a breaking change. How can that be fixed?
2019-05-29Rollup merge of #58975 - jtdowney:iter_arith_traits_option, r=dtolnayMazdak Farrokhzad-0/+110
Implement `iter::Sum` and `iter::Product` for `Option` This is similar to the existing implementation for `Result`. It will take each item into the accumulator unless a `None` is returned. I based a lot of this on #38580. From that discussion it didn't seem like this addition would be too controversial or difficult. One thing I still don't understand is picking the values for the `stable` attribute. This is my first non-documentation PR for rust so I am open to any feedback on improvements.
2019-05-28Bump Sum and Product for Option<T> to 1.37David Tolnay-2/+2
2019-05-28Rollup merge of #61237 - DevQps:expand-iterator-docs, r=Mark-SimulacrumMazdak Farrokhzad-0/+6
Updated the Iterator docs with information about overriding methods. # Description Updated the Iterator docs with information about overriding methods. closes #60223
2019-05-27Updated the Iterator docs with information about overriding methods.Christian-0/+6
2019-05-25Add Step::sub_usizeTim Vermeulen-0/+35
2019-05-22Revert "Add implementations of last in terms of next_back on a bunch of ↵Steven Fackler-5/+0
DoubleEndedIterators." This reverts commit 3e86cf36b5114f201868bf459934fe346a76a2d4.
2019-05-17Use iter() for iterating arrays by sliceJosh Stone-16/+16
These `into_iter()` calls will change from iterating references to values if we ever get `IntoIterator` for arrays, which may break the code using that iterator. Calling `iter()` is future proof.
2019-05-14Rollup merge of #60130 - khuey:efficient_last, r=sfacklerMazdak Farrokhzad-0/+5
Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators Provided a `DoubleEndedIterator` has finite length, `Iterator::last` is equivalent to `DoubleEndedIterator::next_back`. But searching forwards through the iterator when it's unnecessary is obviously not good for performance. I ran into this on one of the collection iterators. I tried adding appropriate overloads for a bunch of the iterator adapters like filter, map, etc, but I ran into a lot of type inference failures after doing so. The other interesting case is what to do with `Repeat`. Do we consider it part of the contract that `Iterator::last` will loop forever on it? The docs do say that the iterator will be evaluated until it returns None. This is also relevant for the adapters, it's trivially easy to observe whether a `Map` adapter invoked its closure a zillion times or just once for the last element.
2019-05-03Add custom nth_back for ChainAndrea Corradi-0/+23
2019-04-27Stabilize Iterator::copied in 1.36.0.Mazdak Farrokhzad-10/+9
2019-04-22Remove double trailing newlinesvarkor-2/+0
2019-04-19Add implementations of last in terms of next_back on a bunch of ↵Kyle Huey-0/+5
DoubleEndedIterators. r?Manishearth
2019-04-19Rollup merge of #60098 - Centril:libcore-deny-more, r=varkorMazdak Farrokhzad-13/+12
libcore: deny `elided_lifetimes_in_paths` r? @varkor
2019-04-19Rollup merge of #60023 - koalatux:nth-back, r=scottmcmMazdak Farrokhzad-0/+26
implement specialized nth_back() for Bytes, Fuse and Enumerate Hi, After my first PR has been successfully merged, here is my second pull request :-) Also this PR contains some specializations for the problem discussed in #54054.
2019-04-19libcore: deny more...Mazdak Farrokhzad-13/+12
2019-04-18libcore => 2018Taiki Endo-26/+30
2019-04-16implement nth_back for EnumerateAdrian Friedli-0/+10
2019-04-16implement nth_back for FuseAdrian Friedli-0/+16
2019-04-02Rollup merge of #59444 - cuviper:steps_between, r=scottmcmMazdak Farrokhzad-51/+10
Implement useful steps_between for all integers We can use `usize::try_from` to convert steps from any size of integer. This enables a meaningful `size_hint()` for larger ranges, rather than always just `(0, None)`. Now they return the true `(len, Some(len))` when it fits, otherwise `(usize::MAX, None)` for overflow.
2019-04-02Rollup merge of #59262 - timvermeulen:iterator_cmp_dedup, r=scottmcmMazdak Farrokhzad-98/+14
Remove duplicated code from Iterator::{ne, lt, le, gt, ge} This PR delegates `Iterator::ne` to `Iterator::eq` and `Iterator::{lt, le, gt, ge}` to `Iterator::partial_cmp`. Oddly enough, this change actually simplifies the generated assembly [in some cases](https://rust.godbolt.org/z/riBtNe), although I don't understand assembly well enough to see if the longer assembly is doing something clever. I also added two extremely simple benchmarks: ``` // before test iter::bench_lt ... bench: 98,404 ns/iter (+/- 21,008) test iter::bench_partial_cmp ... bench: 62,437 ns/iter (+/- 5,009) // after test iter::bench_lt ... bench: 61,757 ns/iter (+/- 8,770) test iter::bench_partial_cmp ... bench: 62,151 ns/iter (+/- 13,753) ``` I have no idea why the current `lt`/`le`/`gt`/`ge` implementations don't seem to be compiled optimally, but simply having them call `partial_cmp` seems to be an improvement. See #44729 for a previous discussion.
2019-03-29Fix OnceWith docstring.Geoffry Song-2/+2
This was incorrectly copypasta'd from RepeatWith.
2019-03-26impl TrustedLen for 128-bit ranges tooJosh Stone-2/+2
2019-03-26Implement useful steps_between for all integersJosh Stone-49/+8
We can use `usize::try_from` to convert steps from any size of integer. This enables a meaningful `size_hint()` for larger ranges, rather than always just `(0, None)`. Now they return the true `(len, Some(len))` when it fits, otherwise `(usize::MAX, None)` for overflow.
2019-03-20Add improved doc example for Sum<Option<T>>John Downey-8/+5
2019-03-19Update stable attribute to be since 1.35.0Mazdak Farrokhzad-2/+2
Co-Authored-By: jtdowney <jdowney@gmail.com>
2019-03-18Simplify Iterator::{lt, gt}Tim Vermeulen-8/+2
2019-03-18Replaced self-reflective explicit types with clearer `Self` or `Self::…` ↵Vincent Esche-3/+3
in stdlib docs
2019-03-17Forward Iterator::{ne, lt, le, gt, ge} to Iterator::{eq, partial_cmp}Tim Vermeulen-96/+18
2019-03-16Rollup merge of #59185 - lukaslueg:patch-2, r=cramertjkennytm-4/+2
No old chestnuts in iter::repeat docs The current language may be amusing, yet is just imprecise and most especially difficult to understand for someone who speaks English as a foreign language.
2019-03-16Rollup merge of #59082 - alexreg:cosmetic-2-doc-comments, r=Centrilkennytm-2/+2
A few improvements to comments in user-facing crates Not too many this time, and all concern comments (almost all doc comments) in user-facing crates (libstd, libcore, liballoc). r? @steveklabnik
2019-03-14Update sources.rslukaslueg-4/+2
The current language may be amusing, yet is just imprecise and most especially difficult to understand for someone who speaks English as a foreign language.
2019-03-12Forward `max` and `min` to `max_by` and `min_by` respectivelyTim Vermeulen-4/+2
2019-03-12Fix commentTim Vermeulen-1/+1
2019-03-12Remove the projection part of select_fold1Tim Vermeulen-56/+21
2019-03-11Improvements to comments in libstd, libcore, liballoc.Alexander Regueiro-2/+2
2019-03-06Implement `iter::Sum` and `iter::Product` for `Option`John Downey-0/+113
This is similar to the existing implementation for `Result`. It will take each item into the accumulator unless a `None` is returned.
2019-02-25Have all methods of Filter and FilterMap use internal iterationTim Vermeulen-30/+7
2019-02-23Rollup merge of #58122 - matthieu-m:range_incl_perf, r=dtolnayMazdak Farrokhzad-3/+58
RangeInclusive internal iteration performance improvement. Specialize `Iterator::try_fold` and `DoubleEndedIterator::try_rfold` to improve code generation in all internal iteration scenarios. This changes brings the performance of internal iteration with `RangeInclusive` on par with the performance of iteration with `Range`: - Single conditional jump in hot loop, - Unrolling and vectorization, - And even Closed Form substitution. Unfortunately, it only applies to internal iteration. Despite various attempts at stream-lining the implementation of `next` and `next_back`, LLVM has stubbornly refused to optimize external iteration appropriately, leaving me with a choice between: - The current implementation, for which Closed Form substitution is performed, but which uses 2 conditional jumps in the hot loop when optimization fail. - An implementation using a `is_done` boolean, which uses 1 conditional jump in the hot loop when optimization fail, allowing unrolling and vectorization, but for which Closed Form substitution fails. In the absence of any conclusive evidence as to which usecase matters most, and with no assurance that the lack of Closed Form substitution is not indicative of other optimizations being foiled, there is no way to pick one implementation over the other, and thus I defer to the statu quo as far as `next` and `next_back` are concerned.
2019-02-19Stabilize iter::from_fnSimon Sapin-6/+5
FCP: https://github.com/rust-lang/rust/issues/55977#issuecomment-463964234
2019-02-19Stabilize iter::successorsSimon Sapin-7/+8
FCP: https://github.com/rust-lang/rust/issues/58045#issuecomment-464674773
2019-02-10libs: doc commentsAlexander Regueiro-8/+8
2019-02-10tests: doc commentsAlexander Regueiro-5/+5
2019-02-09Fix exhaustion of inclusive range try_fold and try_rfoldMatthieu M-2/+12
2019-02-06Fix broken grammar in iter::from_fn() docsSebastian Dröge-4/+2
2019-02-04Remove weasel word in docs for iter's take_while()lukaslueg-2/+1
The phrase "... or some similar thing." is very vague and contributes nothing to understanding the example. Simply removed.
2019-02-03RangeInclusive internal iteration performance improvement.Matthieu M-3/+48
Specialize Iterator::try_fold and DoubleEndedIterator::try_rfold to improve code generation in all internal iteration scenarios. This changes brings the performance of internal iteration with RangeInclusive on par with the performance of iteration with Range: - Single conditional jump in hot loop, - Unrolling and vectorization, - And even Closed Form substitution. Unfortunately, it only applies to internal iteration. Despite various attempts at stream-lining the implementation of next and next_back, LLVM has stubbornly refused to optimize external iteration appropriately, leaving me with a choice between: - The current implementation, for which Closed Form substitution is performed, but which uses 2 conditional jumps in the hot loop when optimization fail. - An implementation using a "is_done" boolean, which uses 1 conditional jump in the hot loop when optimization fail, allowing unrolling and vectorization, but for which Closed Form substitution fails. In the absence of any conclusive evidence as to which usecase matters most, and with no assurance that the lack of Closed Form substitution is not indicative of other optimizations being foiled, there is no way to pick one implementation over the other, and thus I defer to the statu quo as far as next and next_back are concerned.
2019-02-03Auto merge of #57922 - davidtwco:issue-57410, r=petrochenkovbors-0/+3
Update visibility of intermediate use items. Fixes #57410 and fixes #53925 and fixes #47816. Currently, the target of a use statement will be updated with the visibility of the use statement itself (if the use statement was visible). This PR ensures that if the path to the target item is via another use statement then that intermediate use statement will also have the visibility updated like the target. This silences incorrect `unreachable_pub` lints with inactionable suggestions.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 11:18:29 +0000