remove multiple unhelpful `reason = "..."` values from `#[unstable(...)]` invocations
The vast majority of `#[unstable()]` attributes already has no explicit reason specified. This PR removes the `reason = "..."` value for the following unhelpful or meaningless reasons:
* "recently added"
* "new API"
* "recently redesigned"
* "unstable"
An example of how the message looks with and without a reason:
```rust
fn main() {
Vec::<()>::into_parts;
Vec::<()>::const_make_global;
}
```
```
error[E0658]: use of unstable library feature `box_vec_non_null`: new API
--> src/main.rs:2:5
|
2 | Vec::<()>::into_parts;
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #130364 <https://github.com/rust-lang/rust/issues/130364> for more information
= help: add `#![feature(box_vec_non_null)]` to the crate attributes to enable
= note: this compiler was built on 2026-01-15; consider upgrading it if it is out of date
error[E0658]: use of unstable library feature `const_heap`
--> src/main.rs:3:5
|
3 | Vec::<()>::const_make_global;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #79597 <https://github.com/rust-lang/rust/issues/79597> for more information
= help: add `#![feature(const_heap)]` to the crate attributes to enable
= note: this compiler was built on 2026-01-15; consider upgrading it if it is out of date
```
Most of the remaining reasons after this are something similar to "this is an implementation detail for XYZ" or "this is not public". If this PR is approved, I'll look into those next.
The PR also removes the `fd_read` feature gate. It only consists of one attribute applied to an implementation inside a module that is already private and unstable and should not be needed.
This reverts PR <https://github.com/rust-lang/rust/pull/130998> because
the added test seems to be flaky / non-deterministic, and has been
failing in unrelated PRs during merge CI.
`Vec::push` in consts MVP
Example:
```rust
const X: &'static [u32] = {
let mut v = Vec::with_capacity(6);
let mut x = 1;
while x < 42 {
v.push(x);
x *= 2;
}
assert!(v.len() == 6);
v.const_make_global()
};
assert_eq!([1, 2, 4, 8, 16, 32], X);
```
Oh this is fun...
* We split out the implementation of `Global` such that it calls `intrinsics::const_allocate` and `intrinsics::const_deallocate` during compile time. This is achieved using `const_eval_select`
* This allows us to `impl const Allocator for Global`
* We then constify everything necessary for `Vec::with_capacity` and `Vec::push`.
* Added `Vec::const_make_global` to leak and intern the final value via `intrinsics::const_make_global`. If we see any pointer in the final value of a `const` that did not call `const_make_global`, we error as implemented in rust-lang/rust#143595.
r? `@rust-lang/wg-const-eval`
To-do for me:
* [x] Assess the rustdoc impact of additional bounds in the method
* [x] ~~Increase test coverage~~ I think this is enough for an unstable feature.
Improve alloc `Vec::retain_mut` performance
Hi,
While reading the rustc source code, I noticed it uses `smallvec` and `thin-vec` in many places. I started reviewing those crates, optimized their `retain_mut` implementation, and then realized they were using the exact same algorithm as `alloc::vec::Vec` with less unsafe So now I’m back here with a PR for the standard library 😂.
In my benchmarks, this version is noticeably faster when `retain_mut` actually removes elements (thanks to fewer pointer operations, it just advances `write_index`), while performing identically to the current implementation when nothing is removed.
Let’s see if bors likes this change or not.
alloc: Move Cow impl to existing ones
Right now, the `borrow.rs` module starts with a `Cow` impl, although most of them can be found below.
This hurts code readability because there is `ToOwned` alongside its impl directly below it.
Moving it to the others down below makes sense here, given that the entire enum depends on `ToOwned` anyways.
make specialization of `Vec::extend` and `VecDeque::extend_front` work for vec::IntoIter with any `Allocator`, not just `Global`
These functions consume all the elements from the respective collection, but do not care about the `Allocator` they use. Without specifying one (like in `vec::IntoIter<T>`) the specialization is only chosen when `A=Global`.
(extra context: `VecDeque::extend_front` is unstable and tracked by rust-lang/rust#146975)
Add specialization for `deque1.prepend(deque2.drain(range))` (VecDeque::prepend and extend_front)
Tracking issue: rust-lang/rust#146975
This specialization makes sure `deque1.prepend(deque2.drain(..))` gets similar speed to `deque1.append(&mut deque2)`. `deque1.prepend(deque2.drain(..))` is the equivalent of `deque1.append(&mut deque2)` but appending to the front (see the [second example of prepend](https://doc.rust-lang.org/nightly/std/collections/struct.VecDeque.html#method.prepend), prepend is from the same tracking issue).
Right now, the `borrow.rs` module starts with a `Cow` impl, although
most of them can be found below.
This hurts code readability because there is `ToOwned` alongside its
impl directly below it.
Moving it to the others down below makes sense here, given that the
entire enum depends on `ToOwned` anyways.
Fixes the sentence "Attempts to converts a Vec<u8> to a CString.", where "converts" should be in the base form as it is part of the to-infinitive form.
Cleanup linked list
- Replaces some checked_sub().unwrap_or(0) with saturating_sub().
- Replaces NonNull::from(Box::leak(node)) with Box::into_non_null(node)
alloc: specialize String::extend for slices of str
Here's a small optimization via specialization that can potentially eliminate a fair few reallocations when building strings using specific patterns, unsure if this justifies the use of unsafe, but I had the code implemented from rust-lang/rust#148604, so I thought it was worth submitting to see.
Fix `LinkedList::CursorMut::pop_front` to correctly update index
When `pop_front` was called while the cursor pointed to the front element, `move_next` incremented the index but it was never decremented afterwards, causing the index to incorrectly report 1 instead of 0.
Always decrement the index after popping from front using `saturating_sub` to handle edge cases safely.
Fixesrust-lang/rust#147616
When `pop_front` was called while the cursor pointed to the front
element, `move_next` incremented the index but it was never decremented
afterwards, causing the index to incorrectly report 1 instead of 0.
Always decrement the index after popping from front using
`saturating_sub` to handle edge cases safely.
