compiler-builtins: Remove the no-f16-f128 feature
This option was used to gate `f16` and `f128` when support across backends and targets was inconsistent. We now have the rustc builtin cfg `target_has_reliable{f16,f128}` which has taken over this usecase. Remove no-f16-f128 since it is now unused and redundant.
Add some clarifications and fixes for fmt syntax
This tries to clarify a few things regarding fmt syntax:
- The comment on `Parser::word` seems to be wrong, as that underscore-prefixed words are just fine. This was changed in https://github.com/rust-lang/rust/pull/66847.
- I struggled to follow the description of the width argument. It referred to a "second argument", but I don't know what second argument it is referring to (which is the first?). Either way, I rewrote the paragraph to try to be a little more explicit, and to use shorter sentences.
- The description of the precision argument wasn't really clear about the distinction of an Nth argument and a named argument. I added a sentence to try to emphasize the difference.
- `IDENTIFIER_OR_KEYWORD` was changed recently in https://github.com/rust-lang/reference/pull/2049 to include bare `_`. But fmt named arguments are not allowed to be a bare `_`.
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.
This tries to clarify a few things regarding fmt syntax:
- The comment on `Parser::word` seems to be wrong, as that
underscore-prefixed words are just fine. This was changed in
https://github.com/rust-lang/rust/pull/66847.
- I struggled to follow the description of the width argument. It
referred to a "second argument", but I don't know what second argument
it is referring to (which is the first?). Either way, I rewrote the
paragraph to try to be a little more explicit, and to use shorter
sentences.
- The description of the precision argument wasn't really clear about
the distinction of an Nth argument and a named argument. I added
a sentence to try to emphasize the difference.
- `IDENTIFIER_OR_KEYWORD` was changed recently in
https://github.com/rust-lang/reference/pull/2049 to include bare `_`.
But fmt named arguments are not allowed to be a bare `_`.
This option was used to gate `f16` and `f128` when support across
backends and targets was inconsistent. We now have the rustc builtin cfg
`target_has_reliable{f16,f128}` which has taken over this usecase.
Remove no-f16-f128 since it is now unused and redundant.
`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.
