Improve `ptr_rotate` performance, tests, and benches
The corresponding issue is #61784. I am not actually sure if miri can handle the test, but I can change the commit if necessary.
bump rand in libcore/liballoc test suites
This pulls in the fix for https://github.com/rust-random/rand/issues/779, which trips Miri when running these test suites.
`SmallRng` (formerly used by libcore) is no longer built by default, it needs a feature gate. I opted to switch to `StdRng` instead. Or should I enable the feature gate?
Use internal iteration in the Sum and Product impls of Result and Option
This PR adds internal iteration to the `ResultShunt` iterator type underlying the `Sum` and `Product` impls of `Result`. I had to change `ResultShunt` to hold a mutable reference to an error instead, similar to `itertools::ProcessResults`, in order to be able to pass the `ResultShunt` itself by value (which is necessary for internal iteration).
`ResultShunt::process` can unfortunately no longer be an associated function because that would make it generic over the lifetime of the error reference, which wouldn't work, so I turned it into the free function `process_results`.
I removed the `OptionShunt` type and forwarded the `Sum` and `Product` impls of `Option` to their respective impls of `Result` instead, to avoid having to repeat the internal iteration logic.
fix UB in a test
We used to compare two mutable references that were supposed to point to the same thing. That's no good.
Compare them as raw pointers instead.
Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take}
Now that `DoubleEndedIterator::nth_back` has landed, `StepBy` and `Take` can have an efficient `DoubleEndedIterator` implementation. I don't know if there was any particular reason for `Peekable` not having a `DoubleEndedIterator` implementation, but it's quite trivial and I don't see any drawbacks to having it.
I'm not very happy about the implementation of `Peekable::try_rfold`, but I didn't see another way to only take the value out of `self.peeked` in case `self.iter.try_rfold` didn't exit early.
I only added `Peekable::rfold` (in addition to `try_rfold`) because its `Iterator` implementation has both `fold` and `try_fold` (and for similar reasons I added `Take::try_rfold` but not `Take::rfold`). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override `try_fold` but not `fold` and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler `fold` implementation than their `try_fold` implementation.
The tests that I added may not be sufficient because they're all just existing tests where `next`/`nth`/`fold`/`try_fold` are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?
squash of all commits for nth_back on ChunksMut
wip nth_back for chunks_mut
working chunksmut
fixed nth_back for chunksmut
Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
r? @timvermeulen
r? @scottmcm
Introduce `as_deref` to Option
This is re-submission for #59628.
Renames `deref()` to `as_deref()` and adds `deref_mut()` impls and tests.
CC #50264
r? @Kimundi
(I picked you as you're the previous reviewer.)
Add key and value methods to DebugMap
Implementation PR for an active (not approved) RFC: https://github.com/rust-lang/rfcs/pull/2696.
Add two new methods to `std::fmt::DebugMap` for writing the key and value part of a map entry separately:
```rust
impl<'a, 'b: 'a> DebugMap<'a, 'b> {
pub fn key(&mut self, key: &dyn Debug) -> &mut Self;
pub fn value(&mut self, value: &dyn Debug) -> &mut Self;
}
```
I want to do this so that I can write a `serde::Serializer` that forwards to our format builders, so that any `T: Serialize` can also be treated like a `T: Debug`.
Implement nth_back for slice::{Iter, IterMut}
Part of #54054.
I implemented `nth_back` as straightforwardly as I could, and then slightly changed `nth` to match `nth_back`. I believe I did so correctly, but please double-check 🙂
I also added the helper methods `zst_shrink`, `next_unchecked`, and `next_back_unchecked` to get rid of some duplicated code. These changes hopefully make this code easier to understand for new contributors like me.
I noticed the `is_empty!` and `len!` macros which sole purpose seems to be inlining, according to the comment right above them, but the `is_empty` and `len` methods are already marked with `#[inline(always)]`. Does that mean we could replace these macros with method calls, without affecting anything? I'd love to get rid of them.
Implement nth_back for RChunks(Exact)(Mut)
Part of #54054.
These implementations may not be optimal because of the use of `self.len()`, but it's quite cheap and simplifies the code a lot.
There's quite some duplication going on here, I wouldn't mind cleaning this up later. A good next step would probably be to add private `split_off_up_to`/`split_off_from` helper methods for slices since their behavior is commonly useful throughout the `Chunks` types.
r? @scottmcm
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.
