summary refs log tree commit diff
path: root/src/libcore/iter
AgeCommit message (Collapse)AuthorLines
2017-09-25Backport libs stabilizations to 1.21 betaDavid Tolnay-1/+1
This includes the following stabilizations: - tcpstream_connect_timeout https://github.com/rust-lang/rust/pull/44563 - iterator_for_each https://github.com/rust-lang/rust/pull/44567 - ord_max_min https://github.com/rust-lang/rust/pull/44593 - compiler_fences https://github.com/rust-lang/rust/pull/44595 - needs_drop https://github.com/rust-lang/rust/pull/44639 - vec_splice https://github.com/rust-lang/rust/pull/44640
2017-09-24stabilized iterator_for_each (closes #42986)Michal Budzynski-5/+1
updated clippy and rls as it uses the iterator_for_each
2017-08-18Minor Iterator::filter_map description rewording.Corey Farwell-1/+1
Fixes https://github.com/rust-lang/rust/issues/39294.
2017-08-15use field init shorthand EVERYWHEREZack M. Davis-6/+6
Like #43008 (f668999), but _much more aggressive_.
2017-08-11Fix some typosBastien Orivel-2/+2
2017-08-09Auto merge of #43595 - oyvindln:master, r=aturonbors-3/+10
Add an overflow check in the Iter::next() impl for Range<_> to help with vectorization. This helps with vectorization in some cases, such as (0..u16::MAX).collect::<Vec<u16>>(), as LLVM is able to change the loop condition to use equality instead of less than and should help with #43124. (See also my [last comment](https://github.com/rust-lang/rust/issues/43124#issuecomment-319098625) there.) This PR makes collect on ranges of u16, i16, i8, and u8 **significantly** faster (at least on x86-64 and i686), and pretty close, though not quite equivalent to a [manual unsafe implementation](https://is.gd/nkoecB). 32 ( and 64-bit values on x86-64) bit values were already vectorized without this change, and they still are. This PR doesn't seem to help with 64-bit values on i686, as they still don't vectorize well compared to doing a manual loop. I'm a bit unsure if this was the best way of implementing this, I tried to do it with as little changes as possible and avoided changing the step trait and the behavior in RangeFrom (I'll leave that for others like #43127 to discuss wider changes to the trait). I tried simply changing the comparison to `self.start != self.end` though that made the compiler segfault when compiling stage0, so I went with this method instead for now. As for `next_back()`, reverse ranges seem to optimise properly already.
2017-08-06Preface 'cares' with 'only'Ryan Leckey-1/+1
2017-08-01Add an overflow check in the Iter::next() impl for Range<_>oyvindln-3/+10
This helps with vectorization in some cases, such as (0..u16::MAX).collect::<Vec<u16>>(), as LLVM is able to change the loop condition to use equality instead of less than
2017-07-29Rollup merge of #43409 - tshepang:concise, r=steveklabnikMark Simulacrum-25/+8
doc: make into_iter example more concise Also, remove dupe example
2017-07-24doc: make into_iter example more conciseTshepang Lekhonkhobe-25/+8
2017-07-23Auto merge of #43416 - tshepang:extra-layer, r=alexcrichtonbors-6/+5
doc: provide an actual equivalent to filter_map
2017-07-22doc: provide an actual equivalent to filter_mapTshepang Lekhonkhobe-6/+5
2017-07-16Auto merge of #43237 - ↵bors-1/+1
zackmdavis:missing_sum_and_product_for_128_bit_integers, r=nagisa add u128/i128 to sum/product implementors Resolves #43235.
2017-07-14add u128/i128 to sum/product implementorsZack M. Davis-1/+1
Resolves #43235.
2017-07-13Forward more Iterator methods for iter::RevSimon Sapin-0/+8
`position` could not be implemented because calling `rposition` on the inner iterator would require more trait bounds.
2017-07-08Implement O(1)-time Iterator::nth for Range*Simon Sapin-5/+84
2017-07-08Factorize some macros in iter/range.rsSimon Sapin-57/+28
2017-07-08Remove Step::steps_between, rename steps_between_by_one to steps_betweenSimon Sapin-51/+10
2017-07-08Remove unused Step methodsSimon Sapin-34/+0
2017-07-08Remove unused Add bounds in iterator for ranges impls.Simon Sapin-23/+8
2017-07-01Delete deprecated & unstable range-specific `step_by`Scott McMurray-219/+0
Replacement: 41439 Deprecation: 42310 for 1.19 Fixes 41477
2017-06-30Track `iterator_for_each` in #42986Josh Stone-1/+1
2017-06-30Auto merge of #42782 - cuviper:iterator_for_each, r=alexcrichtonbors-0/+47
Add `Iterator::for_each` This works like a `for` loop in functional style, applying a closure to every item in the `Iterator`. It doesn't allow `break`/`continue` like a `for` loop, nor any other control flow outside the closure, but it may be a more legible style for tying up the end of a long iterator chain. This was tried before in #14911, but nobody made the case for using it with longer iterators. There was also `Iterator::advance` at that time which was more capable than `for_each`, but that no longer exists. The `itertools` crate has `Itertools::foreach` with the same behavior, but thankfully the names won't collide. The `rayon` crate also has a `ParallelIterator::for_each` where simple `for` loops aren't possible. > I really wish we had `for_each` on seq iterators. Having to use a > dummy operation is annoying. - [@nikomatsakis][1] [1]: https://github.com/nikomatsakis/rayon/pull/367#issuecomment-308455185
2017-06-27Use a little more compelling example of `for_each`Josh Stone-6/+7
2017-06-23Removed as many "```ignore" as possible.kennytm-1/+1
Replaced by adding extra imports, adding hidden code (`# ...`), modifying examples to be runnable (sorry Homura), specifying non-Rust code, and converting to should_panic, no_run, or compile_fail. Remaining "```ignore"s received an explanation why they are being ignored.
2017-06-22Auto merge of #42634 - Zoxc:for-desugar2, r=nikomatsakisbors-2/+4
Change the for-loop desugar so the `break` does not affect type inference. Fixes #42618 Rewrite the `for` loop desugaring to avoid contaminating the inference results. Under the older desugaring, `for x in vec![] { .. }` would erroneously type-check, even though the type of `vec![]` is unconstrained. (written by @nikomatsakis)
2017-06-21Use `fold` to implement `Iterator::for_each`Josh Stone-4/+4
The benefit of using internal iteration is shown in new benchmarks: test iter::bench_for_each_chain_fold ... bench: 635,110 ns/iter (+/- 5,135) test iter::bench_for_each_chain_loop ... bench: 2,249,983 ns/iter (+/- 42,001) test iter::bench_for_each_chain_ref_fold ... bench: 2,248,061 ns/iter (+/- 51,940)
2017-06-20Add `Iterator::for_each`Josh Stone-0/+46
This works like a `for` loop in functional style, applying a closure to every item in the `Iterator`. It doesn't allow `break`/`continue` like a `for` loop, nor any other control flow outside the closure, but it may be a more legible style for tying up the end of a long iterator chain. This was tried before in #14911, but nobody made the case for using it with longer iterators. There was also `Iterator::advance` at that time which was more capable than `for_each`, but that no longer exists. The `itertools` crate has `Itertools::foreach` with the same behavior, but thankfully the names won't collide. The `rayon` crate also has a `ParallelIterator::for_each` where simple `for` loops aren't possible. > I really wish we had `for_each` on seq iterators. Having to use a > dummy operation is annoying. - [@nikomatsakis][1] [1]: https://github.com/nikomatsakis/rayon/pull/367#issuecomment-308455185
2017-06-13Change the for-loop desugar so the `break` does not affect type inference. ↵John Kåre Alsaker-2/+4
Fixes #42618
2017-06-12Add dedicated docstrings to Sum/Product impl of ResultGeorg Brandl-1/+21
(and fix a minor grammar typo below)
2017-06-07Update docs to say iterator instead of rangeMatt Brubeck-1/+1
2017-06-04Auto merge of #42265 - Zoxc:for-sugar, r=eddybbors-3/+4
Change for-loop desugar to not borrow the iterator during the loop This is enables the use of suspend points inside for-loops in movable generators. This is illegal in the current desugaring as `iter` is borrowed across the body.
2017-06-01Change for-loop desugar to not borrow the iterator during the loopJohn Kåre Alsaker-3/+4
2017-05-31Deprecate iter::range::StepByScott McMurray-0/+15
Only exposed as DeprecatedStepBy (as of PR 41439)
2017-05-31Deprecate Range*::step_byScott McMurray-0/+6
Changed all the tests except test_range_step to use Iterator::step_by.
2017-05-31Rollup merge of #42329 - rap2hpoutre:patch-6, r=steveklabnikMark Simulacrum-2/+2
fix links to "module-level documentation" see https://github.com/rust-lang/rust/issues/42267
2017-05-31fix links to "module-level documentation"Raphaël Huchet-2/+2
2017-05-30RangeFrom should have an infinite size_hintScott McMurray-1/+7
This makes the size_hint from things like `take` more precise.
2017-05-28Auto merge of #42167 - scottmcm:iter-stepby-sizehint, r=alexcrichtonbors-1/+20
Override size_hint and propagate ExactSizeIterator for iter::StepBy Generally useful, but also a prerequisite for moving a bunch of unit tests off `Range*::step_by`. A small non-breaking subset of https://github.com/rust-lang/rust/pull/42110 (which I closed). Includes two small documentation changes @ivandardi requested on that PR. r? @alexcrichton
2017-05-26Auto merge of #42245 - frewsxcv:rollup, r=frewsxcvbors-5/+5
Rollup of 7 pull requests - Successful merges: #42169, #42215, #42216, #42224, #42230, #42236, #42241 - Failed merges:
2017-05-26Rollup merge of #42169 - scottmcm:new-step-trait-issue, r=alexcrichtonCorey Farwell-5/+5
Give step_trait a distinct tracking issue from step_by iterator_step_by has decoupled their futures, so the tracking issue should split. Old issue: https://github.com/rust-lang/rust/issues/27741 New issue: https://github.com/rust-lang/rust/issues/42168 r? @alexcrichton (another follow-up to closed PR https://github.com/rust-lang/rust/pull/42110#issuecomment-303176049)
2017-05-26Auto merge of #42014 - tbu-:pr_scan_not_fused, r=alexcrichtonbors-4/+0
Remove `FusedIterator` implementation of `iter::Scan` Fixes #41964. This is a breaking change.
2017-05-24Rollup merge of #42134 - scottmcm:rangeinclusive-struct, r=aturonMark Simulacrum-119/+55
Make RangeInclusive just a two-field struct Not being an enum improves ergonomics and consistency, especially since NonEmpty variant wasn't prevented from being empty. It can still be iterable without an extra "done" bit by making the range have !(start <= end), which is even possible without changing the Step trait. Implements merged https://github.com/rust-lang/rfcs/pull/1980; tracking issue https://github.com/rust-lang/rust/issues/28237. This is definitely a breaking change to anything consuming `RangeInclusive` directly (not as an Iterator) or constructing it without using the sugar. Is there some change that would make sense before this so compilation failures could be compatibly fixed ahead of time? r? @aturon (as FCP proposer on the RFC)
2017-05-23Give step_trait a distinct tracking issue from step_byScott McMurray-5/+5
iterator_step_by has decoupled their futures, so the tracking issue should split.
2017-05-23Update description of iter::StepByScott McMurray-1/+1
2017-05-23Override size_hint and propagate ExactSizeIterator for iter::StepByScott McMurray-0/+19
Generally useful, but also a prerequisite for moving a bunch of unit tests off Range::step_by.
2017-05-21Return a correct size_hint for degenerate inclusive rangesScott McMurray-0/+4
Fixes https://github.com/rust-lang/rust/issues/42135 Found while fixing run-pass/range_inclusive test failure.
2017-05-21Make RangeInclusive just a two-field structScott McMurray-120/+52
Not being an enum improves ergonomics, especially since NonEmpty could be Empty. It can still be iterable without an extra "done" bit by making the range have !(start <= end), which is even possible without changing the Step trait. Implements RFC 1980
2017-05-20Auto merge of #42111 - ollie27:stab, r=Mark-Simulacrumbors-1/+1
Correct some stability versions These were found by running tidy on stable versions of rust and finding features stabilised with the wrong version numbers.
2017-05-20Correct some stability versionsOliver Middleton-1/+1
These were found by running tidy on stable versions of rust and finding features stabilised with the wrong version numbers.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-12 05:34:05 +0000