| Age | Commit message (Collapse) | Author | Lines |
|---|
|
A small PR to fix a small CS typo in `iter/traits/collect.rs`.
|
|
The errors are either:
- The meta-variable used in the right-hand side is not bound (or defined) in the
left-hand side.
- The meta-variable used in the right-hand side does not repeat with the same
kleene operator as its binder in the left-hand side. Either it does not repeat
enough, or it uses a different operator somewhere.
This change should have no semantic impact.
|
|
Add custom nth_back to Skip
Implementation of nth_back for Skip.
Part of #54054
|
|
implement nth_back for Range(Inclusive)
This is part of #54054.
|
|
We already use this for `unzip`, but `partition` is not much different.
|
|
|
|
|
|
|
|
|
|
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?
|
|
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.
|
|
|
|
Updated the Iterator docs with information about overriding methods.
# Description
Updated the Iterator docs with information about overriding methods.
closes #60223
|
|
|
|
|
|
DoubleEndedIterators."
This reverts commit 3e86cf36b5114f201868bf459934fe346a76a2d4.
|
|
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.
|
|
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.
|
|
|
|
|
|
DoubleEndedIterators.
r?Manishearth
|
|
libcore: deny `elided_lifetimes_in_paths`
r? @varkor
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
This was incorrectly copypasta'd from RepeatWith.
|
|
|
|
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.
|
|
|
|
Co-Authored-By: jtdowney <jdowney@gmail.com>
|
|
|
|
in stdlib docs
|
|
|
|
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.
|
|
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
|
|
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.
|
|
|
|
|
|
|
|
|
|
This is similar to the existing implementation for `Result`. It will
take each item into the accumulator unless a `None` is returned.
|
|
|
|
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.
|
|
FCP: https://github.com/rust-lang/rust/issues/55977#issuecomment-463964234
|
|
FCP: https://github.com/rust-lang/rust/issues/58045#issuecomment-464674773
|
|
|
