rust/library/std, branch stable

Rust build fails on OpenBSD after using file_lock feature

2025-09-08T21:25:58+00:00

PR 130999 added the file_lock feature, but doesn't included OpenBSD in the supported targets (Tier 3 platform), leading to a compilation error ("try_lock() not supported"). (cherry picked from commit 8792010768cff60d202b3608e6918be3199aeae2)

replace version placeholder

2025-08-04T09:52:21+00:00

Remove `std`'s dependency on `compiler-builtins`

2025-07-31T22:47:24+00:00

`compiler-builtins` is already in the crate graph via `alloc`, and all features related to `compiler-builtins` goes through `alloc`. There isn't any reason that `std` needs this direct dependency, so remove it.

uefi: Use slice equality rather than `memcmp`

2025-07-31T22:47:24+00:00

`compiler_builtins` shouldn't be called directly. Change the `PartialEq` implementation for `DevicePathNode` to use slice equality instead, which will call `memcmp`/`bcmp` via the intrinsic.

Rollup merge of #144500 - joboet:thread-name-stack-overflow, r=ChrisDenton

2025-07-29T10:19:51+00:00

thread name in stack overflow message Fixes rust-lang/rust#144481, which is caused by the thread name not being initialised yet when setting up the stack overflow information. Unfortunately, the stack overflow UI test did not test for the correct thread name being present, and testing this separately didn't occur to me when writing https://github.com/rust-lang/rust/pull/140628. This PR contains the smallest possible fix I could think of: passing the thread name explicitly to the platform thread creation function. In the future I'd very much like to explore some possibilities around merging the thread packet and thread handle into one structure and using that in the platform code instead – but that's best left for another PR. This PR also amends the stack overflow test to check for thread names, so we don't run into this again. ``@rustbot`` label +beta-nominated

Rollup merge of #144022 - connortsui20:sync_nonpoison, r=tgross35

2025-07-29T10:19:48+00:00

Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]` Continuation of https://github.com/rust-lang/rust/pull/134663 Tracking Issue: https://github.com/rust-lang/rust/issues/134645 This PR implements a new `sync/nonpoison` module, as well as the `nonpoison` variant of the `Mutex` lock. There are 2 main changes here, the first is the new `nonpoison::mutex` module, and the second is the `mutex` integration tests. For the `nonpoison::mutex` module, I did my best to align it with the current state of the `poison::mutex` module. This means that several unstable features (`mapped_lock_guards`, `lock_value_accessors`, and `mutex_data_ptr`) are also in the new `nonpoison::mutex` module, under their respective feature gates. Everything else in that file is under the correct feature gate (`#[unstable(feature = "nonpoison_mutex", issue = "134645")]`). Everything in the `nonpoison::mutex` file is essentially identical in spirit, as we are simply removing the error case from the original `poison::mutex`. The second big change is in the integration tests. I created a macro called that allows us to duplicate tests that are "generic" over the different mutex types, in that the poison mutex is always `unwrap`ped. ~~I think that there is an argument against doing this, as it can make the tests a bit harder to understand (and language server capabilities are weaker within macros), but I think the benefit of code deduplication here is worth it. Note that it is definitely possible to generalize this (with a few tweaks) to testing the other `nonpoison` locks when they eventually get implemented, but I'll leave that for a later discussion.~~

add extra drop, panic, and unwind tests

2025-07-29T08:44:36+00:00

add nonpoison and poison mutex tests

2025-07-29T08:36:26+00:00

Adds tests for the `nonpoison::Mutex` variant by using a macro to duplicate the existing `poison` tests. Note that all of the tests here are adapted from the existing `poison` tests.

reorder mutex tests

2025-07-29T08:33:05+00:00

This commit simply helps discern the actual changes needed to test both poison and nonpoison locks.

add `nonpoison::mutex` implementation

2025-07-29T08:32:15+00:00

Adds the equivalent `nonpoison` types to the `poison::mutex` module. These types and implementations are gated under the `nonpoison_mutex` feature gate. Also blesses the ui tests that now have a name conflicts (because these types no longer have unique names). The full path distinguishes the different types. Co-authored-by: Aandreba Co-authored-by: Trevor Gross