| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
Strategies B and C both show a full buffer before the capacity increase, while strategy A had one empty element left. Filled the last element in.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* advance
* aligned
* borrowed
* calculate
* debugable
* debuggable
* declarations
* desugaring
* documentation
* enclave
* ignorable
* initialized
* iterator
* kaboom
* monomorphization
* nonexistent
* optimizer
* panicking
* process
* reentrant
* rustonomicon
* the
* uninitialized
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
Enhanced doucmentation of binary search methods for `slice` and `VecDeque` for unsorted instances
Fixes #106746. Issue #106746 raises the concern that the binary search methods for slices and deques aren't explicit enough about the fact that they are only applicable to sorted slices/deques. I changed the explanation for these methods. I took the relatively harsh description of the behaviour of binary search on unsorted collections ("unspecified and meaningless") from the description of the [`partition_point`](https://doc.rust-lang.org/std/primitive.slice.html#method.partition_point) method:
> If this slice is not partitioned, the returned result is unspecified and meaningless, as this method performs a kind of binary search.
|
|
|
|
unsorted instances
|
|
|
|
|
|
A successful advance is now signalled by returning `0` and other values now represent the remaining number
of steps that couldn't be advanced as opposed to the amount of steps that have been advanced during a partial advance_by.
This simplifies adapters a bit, replacing some `match`/`if` with arithmetic. Whether this is beneficial overall depends
on whether `advance_by` is mostly used as a building-block for other iterator methods and adapters or whether
we also see uses by users where `Result` might be more useful.
|
|
Fix `vec_deque::Drain` FIXME
In my original `VecDeque` rewrite, I didn't use `VecDeque::slice_ranges` in `Drain::as_slices`, even though that's basically the exact use case for `slice_ranges`. The reason for this was that a `VecDeque` wrapped in a `Drain` actually has its length set to `drain_start`, so that there's no potential use after free if you `mem::forget` the `Drain`. I modified `slice_ranges` to accept an explicit `len` parameter instead, which it now uses to bounds check the given range. This way, `Drain::as_slices` can use `slice_ranges` internally instead of having to basically just copy paste the `slice_ranges` code. Since `slice_ranges` is just an internal helper function, this shouldn't change the user facing behavior in any way.
|
|
Fix `VecDeque::append` capacity overflow for ZSTs
Fixes #108454.
|
|
|
|
This adds both a test specific to #108453 as well as an exhaustive test
that goes through all possible combinations of head index, length and target capacity
for a deque with capacity 16.
|
|
|
|
|
|
Implement more methods for `vec_deque::IntoIter`
This implements a couple `Iterator` methods on `vec_deque::IntoIter` (`(try_)fold`, `(try_)rfold` `advance_(back_)by`, `next_chunk`, `count` and `last`) to allow these to be more efficient than their default implementations, also allowing many other `Iterator` methods that use these under the hood to take advantage of these manual implementations. `vec::IntoIter` has similar implementations for many of these methods. This PR does not yet implement `TrustedRandomAccess` and friends, as I'm not very familiar with the required safety guarantees.
r? `@the8472` (since you also took over my last PR)
|
|
|
|
|
|
|
|
Clarify examples for `VecDeque::get/get_mut`
Closes #106114
``@rustbot`` label +A-docs
|
|
Add O(1) `Vec -> VecDeque` conversion guarantee
(See #105072)
|
|
|
|
|
|
Make `VecDeque::new` const
(See #105072)
|
|
* A few typos around generic types (`;` vs `,`)
* Use inline code formatting for code fragments
* One instance of wrong wording
|
|
|
|
|
|
|
|
Send `VecDeque::from_iter` via `Vec::from_iter`
Since it's O(1) to convert between them now, might as well reuse the logic.
Mostly for the various specializations it does, but might also save some monomorphization work if, say, people collect slice iterators into both `Vec`s and `VecDeque`s.
|
|
|
|
|
|
|
|
Since it's O(1) to convert between them now, might as well reuse the logic.
Mostly for the various specializations it does, but might also save some monomorphization work if, say, people collect slice iterators into both `Vec`s and `VecDeque`s.
|
|
|
|
|
|
|
|
|
