rust/library/alloc/src/collections/vec_deque, branch 1.82.0

replace placeholder version

2024-09-02T16:48:42+00:00

Stabilize `min_exhaustive_patterns`

2024-08-10T10:07:17+00:00

Rollup merge of #128261 - clarfonthey:iter-default, r=dtolnay

2024-08-07T18:28:16+00:00

impl `Default` for collection iterators that don't already have it There is a pretty strong precedent for implementing `Default` for collection iterators, and this does so for some where this implementation was missed. I don't think this needs a separate ACP (since this precedent already exists, and these feel like they were just missed), however, it *will* need an FCP since these implementations are instantly stable.

Reformat `use` declarations.

2024-07-28T22:26:52+00:00

The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.

Okay, I guess I have to give these a different feature name

2024-07-27T06:48:55+00:00

impl Default for collection iterators that don't already have it

2024-07-27T06:04:32+00:00

Specialize `TrustedLen` for `Iterator::unzip()`

2024-07-07T03:58:52+00:00

Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented). I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it. It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`. A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.

Replace `MaybeUninit::uninit_array()` with array repeat expression.

2024-06-24T17:23:50+00:00

This is possible now that inline const blocks are stable; the idea was even mentioned as an alternative when `uninit_array()` was added: > if it’s stabilized soon enough maybe it’s not worth having a > standard library method that will be replaceable with > `let buffer = [MaybeUninit::::uninit(); $N];` Const array repetition and inline const blocks are now stable (in the next release), so that circumstance has come to pass, and we no longer have reason to want `uninit_array()` other than convenience. Therefore, let’s evaluate the inconvenience by not using `uninit_array()` in the standard library, before potentially deleting it entirely.

Move `test_shrink_to_unwind` to its own file.

2024-05-07T19:43:54+00:00

This way, no other test can be tripped up by `test_shrink_to_unwind` changing the alloc error hook.

Fix `VecDeque::shrink_to` UB when `handle_alloc_error` unwinds.

2024-05-07T19:30:34+00:00

Luckily it's comparatively simple to just restore the `VecDeque` into a valid state on unwinds.