std: implement `clear` via `truncate`
This gets rid of some `unsafe`. `truncate(0)` is even documented to be equivalent to `clear`, this makes that equivalence even more obvious.
`bufreader::Buffer`: Remove leftover note about `initialized` field
Just a boring little doc fix! : v)
https://github.com/rust-lang/rust/pull/150129 reworked the `initialized` field to be a `bool` instead of a `usize`.
And then https://github.com/rust-lang/rust/pull/155314 reworked this field's comment (among other things).
But, there's still a leftover note in the comment, which no longer makes sense:
``Note that while this often the same as `filled`, it doesn't need to be.``
This is referencing that back when `initialized` was a `usize`, it was common for it to have the same value as `filled`.
----
Fun fact: there's a typo in the note too! It's missing an "is" before or after "often".
Do not run jump-threading for GPUs
GPU targets have convergent operations that must not be duplicated or
moved in or out of control-flow.
An example convergent operation is a barrier/syncthreads.
The only MIR pass affected by this is jump-threading, it can duplicate
calls. Disable jump-hreading for GPU targets to prevent generating
incorrect code.
This affects the amdgpu and nvptx targets.
Fixesrust-lang/rust#137086, see this issue for details.
Tracking issue: rust-lang/rust#135024
cc @RDambrosio016 @kjetilkjeka for nvptx
cc @ZuseZ4
https://github.com/rust-lang/rust/pull/150129 reworked this field to use `bool` instead of `usize`, which is awesome!
But the field's comment has a leftover note in it which is no longer true, and that needs to be removed.
std_detect: support detecting more features on aarch64 Windows
Wires `IsProcessorFeaturePresent` calls for the `PF_ARM_*` constants exposed in Windows SDK 26100 (Windows 11 24H2), plus an architectural derivation for `rdm`. All eight feature names have been stable in `is_aarch64_feature_detected!` on Linux/Darwin/BSD since Rust 1.60 — this brings the Windows backend to parity.
| Feature | Source on Windows |
|---|---|
| `fp16` | `PF_ARM_V82_FP16_INSTRUCTIONS_AVAILABLE` (value 67) |
| `i8mm` | `PF_ARM_V82_I8MM_INSTRUCTIONS_AVAILABLE` (value 66) |
| `bf16` | `PF_ARM_V86_BF16_INSTRUCTIONS_AVAILABLE` (value 68) |
| `sha3` | `PF_ARM_SHA3` (value 64) **AND** `PF_ARM_SHA512` (value 65) |
| `lse2` | `PF_ARM_LSE2_AVAILABLE` (value 62) |
| `f32mm` | `PF_ARM_SVE_F32MM_INSTRUCTIONS_AVAILABLE` (value 58) |
| `f64mm` | `PF_ARM_SVE_F64MM_INSTRUCTIONS_AVAILABLE` (value 59) |
| `rdm` | derived from `PF_ARM_V82_DP` (see below) |
`PF_ARM_SVE_F32MM` / `PF_ARM_SVE_F64MM` (values 58 / 59) were already added as commented-out placeholders in rust-lang/stdarch#1749 — they have direct stable Feature mappings (`f32mm`, `f64mm`), unlike their sibling values 52 / 53 / 57 (`SVE_BF16`, `SVE_EBF16`, `SVE_I8MM`) which have no SVE-specific stdarch Feature name and remain commented for that reason.
`sha3` requires both `PF_ARM_SHA3` (FEAT_SHA3) and `PF_ARM_SHA512` (FEAT_SHA512), matching the existing convention from rust-lang/stdarch#1749 where `sve2-aes` is set only when both `PF_ARM_SVE_AES` and `PF_ARM_SVE_PMULL128` are present.
### `rdm` derivation
There is no `PF_ARM_RDM_*` constant; Microsoft has never defined one. We derive it from `PF_ARM_V82_DP_INSTRUCTIONS_AVAILABLE` (FEAT_DotProd) via the following architectural chain:
1. FEAT_DotProd is an optional v8.2-A feature, so its presence implies the core implements at least v8.1-A.
2. Per Arm ARM K.a §D17.2.91: *"In an ARMv8.1 implementation, if FEAT_AdvSIMD is implemented, FEAT_RDM is implemented."*
3. AdvSIMD is universally implemented on every Windows-on-ARM SKU.
4. Therefore: DotProd ⇒ v8.1-A baseline + AdvSIMD ⇒ FEAT_RDM.
This is the same derivation .NET 10 uses, with comment cited verbatim ([dotnet/runtime PR 109493](https://github.com/dotnet/runtime/pull/109493), shipped in v10.0.0 at [`src/native/minipal/cpufeatures.c`](https://github.com/dotnet/runtime/blob/v10.0.0/src/native/minipal/cpufeatures.c)):
> *"IsProcessorFeaturePresent does not have a dedicated flag for RDM, so we enable it by implication.
> 1) DP is an optional instruction set for Armv8.2, which may be included only in processors implementing at least Armv8.1.
> 2) Armv8.1 requires RDM when AdvSIMD is implemented, and AdvSIMD is a baseline requirement of .NET.
> Therefore, by documented standard, DP cannot exist here without RDM. In practice, there is only one CPU supported by Windows that includes RDM without DP, so this implication also has little practical chance of a false negative."*
The "one CPU with RDM without DP" trade-off applies equally to us: we accept a possible false negative on that single SKU rather than introducing a more aggressive heuristic.
### Tests
Adds `println!` lines to the existing `aarch64_windows()` test in `library/std_detect/tests/cpu-detection.rs` for each newly-detected feature, mirroring the existing single-line pattern. No structural assertions added.
### Scope
Stable feature names only. The unstable SME family (`sme`, `sme2`, `sme2p1`, `sme_*`, `ssve_fp8*`) and other unstable additions tracked under rust-lang/rust#127764 are intentionally out of scope here to keep this PR minimal — happy to do a follow-up.
### References
- Tracking issue: rust-lang/rust#127764 (`stdarch_aarch64_feature_detection`)
- Precedent: rust-lang/stdarch#1749 (taiki-e, merged 2025-03-24) — added the SVE constants this builds on
- MS docs: [`IsProcessorFeaturePresent`](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-isprocessorfeaturepresent) — full PF_ARM_* table
r? @Amanieu
cc @taiki-e (author of rust-lang/stdarch#1749, would appreciate your eyes on the `rdm` inference)
@rustbot label +T-libs +O-windows +O-ARM
c-variadic: more precise compatibility check in const-eval
tracking issue: https://github.com/rust-lang/rust/issues/44930
This came up in the stabilization report discussion https://github.com/rust-lang/rust/pull/155697#discussion_r3139778447.
As a reminder, this is what C says (in section 7.16.1.1 of the [C23 standard](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf#page=302).
> If type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined, except for the following cases:
>
> - both types are pointers to qualified or unqualified versions of compatible types;
> - one type is compatible with a signed integer type, the other type is compatible with the
> corresponding unsigned integer type, and the value is representable in both types;
> - one type is pointer to qualified or unqualified void and the other is a pointer to a qualified or
> unqualified character type;
> - or, the type of the next argument is `nullptr_t` and type is a pointer type that has the same representation and alignment requirements as a pointer to a character type
I think the last rule is not relevant for us, we don't really have an equivalent of `nullptr_t` as far as I know.
r? RalfJung
cc @tgross35
fix: ✏️ forgot to change the stable version for `assert_matches!` macro.
The `assert_matches` macro was delayed because of rust-lang/rust#154406 and the `#[stable(since)]` wasn't changed to the next version.
Document that CFI diverges from Rust wrt. ABI-compatibility rules
The CFI sanitizer is a sanitizer that checks that no ABI-incompatible function calls are made at runtime, but there is currently an unfortunate divergence between the Rust ABI-compatibility rules and what the CFI sanitizer checks. Thus, document that this divergence exists.
There are proposals for how we can align the ABI rules to eliminate this discrepancy, and I would like to follow through with those, but for now I think we can at least document that the discrepancy exists.
For further discussion please see [Re-evaluate ABI compatibility rules in light of CFI](https://github.com/rust-lang/unsafe-code-guidelines/issues/489) and [Can CFI be made compatible with type erasure schemes?](https://github.com/rust-lang/rust/issues/128728) and [`fn_cast!` macro](https://github.com/rust-lang/rust/issues/140803).
cc @rcvalle @samitolvanen @maurer @bjorn3 @RalfJung
Rendered:
<img width="956" height="391" alt="image" src="https://github.com/user-attachments/assets/410d3eaa-9476-4800-9ef8-bbb100a100c5" />
Rename the diagnostic item for `std::sync::mpsc::Receiver`
`MpscReceiver` aligns with `MpscSender`. The original name appears to not actually have been in use, for better or worse.
r? mejrs
`slice::join`: borrow only once during length calc
This ensures the length calculation will always be self-consistent even if the real length changes when we actually come to use them.
This is a follow up to rust-lang/rust#155708
Don't reload length in String::push
Same as in `Vec::push_mut`, we get `.len()` once at the start since it won't change in the `reserve()` call.
Saves reloading the length after the allocation: https://godbolt.org/z/W3G165Gd7
`MpscReceiver` aligns with `MpscSender`. The original name appears to
not actually have been in use, for better or worse.
Along the way, sprinkle the attribute onto `mpmc::Receiver` and
`mpmc::Sender` too.
Wire IsProcessorFeaturePresent for the PF_ARM_* constants exposed in
Windows SDK 26100 (Win11 24H2):
fp16 PF_ARM_V82_FP16_INSTRUCTIONS_AVAILABLE (67)
i8mm PF_ARM_V82_I8MM_INSTRUCTIONS_AVAILABLE (66)
bf16 PF_ARM_V86_BF16_INSTRUCTIONS_AVAILABLE (68)
sha3 PF_ARM_SHA3 (64) AND PF_ARM_SHA512 (65)
lse2 PF_ARM_LSE2_AVAILABLE (62)
f32mm PF_ARM_SVE_F32MM_INSTRUCTIONS_AVAILABLE (58)
f64mm PF_ARM_SVE_F64MM_INSTRUCTIONS_AVAILABLE (59)
Also derive `rdm` from FEAT_DotProd. There is no PF_ARM_RDM_* constant;
FEAT_DotProd is an optional v8.2-A feature only present on cores that
implement at least v8.1-A, and v8.1-A with AdvSIMD mandates FEAT_RDM
(Arm ARM K.a §D17.2.91). AdvSIMD is universal on Windows-on-ARM. See
PR description for full rationale and .NET 10 precedent.
All eight feature names have been stable in `is_aarch64_feature_detected!`
on Linux/Darwin/BSD since Rust 1.60.
std: sys: process: uefi: Add program searching
- Follow UEFI Shell search flow to search for programs while launching.
- Tested using OVMF on QEMU.
@rustbot label +O-UEFI
Fix heap overflow in slice::join caused by misbehaving Borrow
This code allocates a buffer using lengths calculated by calling `.borrow()` on some slices, and then copies them over after again calling `.borrow()`. There is no safety-reliable guarantee that these will return the same slices.
While this code calls `.borrow()` three times, only one of them is problematic: the others already use checked indexing.
I made the test a normal library test, but let me know if it should go elsewhere.
Bug discovered by Rust Foundation Security using AI. I'm just helping with the patch as a member of wg-security-response. We do not believe this bug needs embargo, it is a soundness fix for hard-to-trigger unsoundness.
Implement more traits for FRTs
From https://github.com/rust-lang/rust/pull/154927#discussion_r3068460955.
FRTs now implement the following traits: `Sized + Freeze + RefUnwindSafe + Send + Sync + Unpin + UnsafeUnpin + UnwindSafe + Copy + Debug + Default + Eq + Hash + Ord`.
Let me know if there is any trait missing.
I also removed the explicit `Send` and `Sync` impls, since commit cb37ee2c87 ("make field representing types invariant over the base type") made the auto-trait impl work even if `T: !Send` or `T: !Sync`. Very happy to see unsafe impls get dropped :)
Note that I used the reflection feature (cc @oli-obk) to print the actual field names in the debug implementation. I think this is a cool way to use it, but if it isn't ready for that, I'm happy to change it to the alternative implementation I gave in the note comment (it's essentially Mark's suggestion but printing `T`'s name instead of `Self`'s).
Since this is a library change, I'll give this to Mark; feel free to also take a look/leave comments, Oli :)
r? @Mark-Simulacrum
Make Rcs and Arcs use pointer comparison for unsized types
`Rc` and `Arc`s have an `Eq` implementation that first attempt to compare the pointers as an optimization. This, however, was not extended to DSTs, which is what this PR fixes.
Fixesrust-lang/rust#154998.
`std::io::Take`: Clarify & optimize `BorrowedBuf::set_init` usage.
Don't initialize `buf` if it was already initialized. Clarify safety comments.
Move the `buf.advance()` call to make the initialization more like
calling `buf.ensure_init()`, then clarify how the code here is an
optimized variant of `ensure_init`.
Same as in Vec::push_mut, we get `.len()` once at the start since
it won't change in the `reserve()` call.
Saves reloading the length after the allocation: https://godbolt.org/z/W3G165Gd7
Fix minor panic-unsoundness in CString::clone_into
`CString` must always contain a null byte, calling `mem::take` on its inner allocation puts it in an invalid state (causing UB if e.g. it hits `CString::drop`) that can be observed if the allocator panics.
Unfortunately, this solution allocates an intermediate 1-element `Box`. I'm not sure of a clean way to avoid that additional allocation; we could directly `realloc` if we want but it's tricky. Might be something we can do with `ManuallyDrop`.
I do have a gnarly miri test for this that uses a panicky allocator, but I'm not sure where it would go. Happy to push it up if someone has a suggestion.
Bug discovered by Rust Foundation Security using AI. I'm just helping with the patch as a member of wg-security-response. We do not believe this bug needs embargo, it is a soundness fix for hard-to-trigger unsoundness.
Move `std::io::RawOsError` to `core::io`
ACP: https://github.com/rust-lang/libs-team/issues/755
Tracking issue: https://github.com/rust-lang/rust/issues/154046
Related: https://github.com/rust-lang/rust/pull/154654
## Description
As a part of moving components of `std::io` into `alloc::io` and `core::io`, there will need to be a new home for the type `RawOsError`. In this PR, I propose moving it to `core::io`, and removing it from `std::sys`. I suspect this will be quite controversial as it is a platform dependent type, but this is not the only instance of a type being conditioned on `target_os` in `core` (e.g., `core::os` and `core::ffi`).
Since `RawOsError` is currently unstable, I think it's reasonable to make this move now, and worry about making it platform independent if/when it is stabilized (e.g., replacing it with a wrapper around `isize` on all platforms).
---
## Notes
* No AI tooling of any kind was used during the creation of this PR.
Windows: Cache the pipe filesystem handle
Updates the anonymous pipe handling based on feedback from @lhecker (see https://github.com/rust-lang/rust/pull/142517#discussion_r3065864262). This does two things:
1. Cache the handle to the pipe filesystem so we don't have to reopen it each time.
2. Use the `\Device\NamedPipe\` directly instead of the symlink to it.
bors