std: thread: Return error if setting thread stack size fails
Currently, when setting the thread stack size fails, it would be rounded up to the nearest multiple of the page size and the code asserts that the next call to `pthread_attr_setstacksize` succeeds.
This may be true for glibc, but it isn't true for musl, which not only enforces a minimum stack size, but also a maximum stack size of `usize::MAX / 4 - PTHREAD_STACK_MIN` [1], triggering the assert rather than erroring gracefully.
There isn't any way to handle this properly other than bailing out and letting the user know it didn't succeed.
[1]: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c#n5
Resolve the prelude import in `build_reduced_graph`
This pr tries to resolve the prelude import at the `build_reduced_graph` stage.
Part of batched import resolution in rust-lang/rust#145108 (cherry picked commit) and maybe needed for rust-lang/rust#139493.
r? petrochenkov
Fix description of unsigned `checked_exact_div`
Like its signed counterpart, this function does not panic. Also, fix the examples to document how it returns Some/None.
Implement autodiff using intrinsics
This PR aims to move autodiff logic to `autodiff` intrinsic. Allowing us to delete a great part of our frontend code and overall, simplify the compilation pipeline of autodiff functions.
cfg_select: Support unbraced expressions
Tracking issue for `cfg_select`: rust-lang/rust#115585
When operating on expressions, `cfg_select!` can now handle expressions
without braces. (It still requires braces for other things, such as
items.)
Expand the test coverage and documentation accordingly.
---
I'm not sure whether deciding to extend `cfg_select!` in this way is T-lang or T-libs-api. I've labeled for both, with the request that both teams don't block on each other. :)
Currently, when setting the thread stack size fails, it would be rounded
up to the nearest multiple of the page size and the code asserts that
the next call to pthread_attr_setstacksize succeeds.
This may be true for glibc, but it isn't true for musl, which not only
enforces a minimum stack size, but also a maximum stack size of
usize::MAX / 4 - PTHREAD_STACK_MIN [1], triggering the assert rather
than erroring gracefully.
There isn't any way to handle this properly other than bailing out and
letting the user know it didn't succeed.
[1]: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c#n5
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Stabilize `sse4a` and `tbm` target features
This PR stabilizes the feature flag `sse4a_target_feature` and `tbm_target_feature` (tracking issue rust-lang/rust#44839).
# Public API
The 2 `x86` target features `sse4a` and `tbm`
Also, these were added in LLVM2.6 and LLVM3.4-rc1, respectively, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now. The intrinsics were stabilized *long* ago, in 1.27.0
Reference PR:
- https://github.com/rust-lang/reference/pull/1949
cc `@rust-lang/lang`
`@rustbot` label I-lang-nominated
r? lang
doc test: fix mpsc.rs try_send doc test
This Pr want to fix the doctest, to make https://github.com/rust-lang/rust/pull/145293 's CI pass:
r? ``@Zalathar``
https://github.com/rust-lang/rust/actions/runs/16903356990/job/47887354221
```bash
2025-08-12T10:19:32.3873237Z test library/std/src/thread/scoped.rs - thread::scoped::ScopedJoinHandle<'scope,T>::join (line 302) ... ok
2025-08-12T10:19:32.4370250Z test library/std/src/time.rs - time::SystemTimeError::duration (line 688) ... ok
2025-08-12T10:19:32.5121966Z test library/std/src/time.rs - time::UNIX_EPOCH (line 664) ... ok
2025-08-12T10:19:32.5122586Z
2025-08-12T10:19:32.5122738Z failures:
2025-08-12T10:19:32.5122973Z
2025-08-12T10:19:32.5123482Z ---- library/std/src/sync/mpsc.rs - sync::mpsc::SyncSender<T>::try_send (line 691) stdout ----
2025-08-12T10:19:32.5124286Z Test executable failed (exit status: 1).
2025-08-12T10:19:32.5124518Z
2025-08-12T10:19:32.5124605Z stdout:
2025-08-12T10:19:32.5124810Z message 3 received
2025-08-12T10:19:32.5125043Z message 1 received
2025-08-12T10:19:32.5125288Z the third message was never sent
2025-08-12T10:19:32.5125497Z
2025-08-12T10:19:32.5125581Z stderr:
2025-08-12T10:19:32.5125701Z
2025-08-12T10:19:32.5125935Z thread '<unnamed>' (203874) panicked at library/std/src/sync/mpsc.rs:14:25:
2025-08-12T10:19:32.5126459Z called `Result::unwrap()` on an `Err` value: SendError { .. }
2025-08-12T10:19:32.5126836Z stack backtrace:
2025-08-12T10:19:32.5127568Z ␛[0m␛[1m␛[38;5;9merror␛[0m␛[0m␛[1m: the main thread terminated without waiting for all remaining threads␛[0m
2025-08-12T10:19:32.5127971Z
2025-08-12T10:19:32.5128335Z ␛[0m␛[1m␛[38;5;10mnote␛[0m␛[0m␛[1m: set `MIRIFLAGS=-Zmiri-ignore-leaks` to disable this check␛[0m
2025-08-12T10:19:32.5128694Z
2025-08-12T10:19:32.5128943Z ␛[0m␛[1m␛[38;5;9merror␛[0m␛[0m␛[1m: aborting due to 1 previous error␛[0m
2025-08-12T10:19:32.5129519Z
2025-08-12T10:19:32.5129527Z
2025-08-12T10:19:32.5129532Z
2025-08-12T10:19:32.5129537Z
2025-08-12T10:19:32.5129631Z failures:
2025-08-12T10:19:32.5130018Z library/std/src/sync/mpsc.rs - sync::mpsc::SyncSender<T>::try_send (line 691)
2025-08-12T10:19:32.5130396Z
2025-08-12T10:19:32.5130713Z test result: FAILED. 999 passed; 1 failed; 16 ignored; 0 measured; 344 filtered out; finished in 105.92s
```
Avoid abbreviating "numerator" as "numer", to allow catching typo "numer" elsewhere
`typos.toml` has an exception for "numer", to avoid flagging its use as an abbreviation for "numerator". Remove the use of that abbrevation, spelling out "numerator" instead, and remove the exception, so that typo checks can find future instances of "numer" as a typo for "number".
Add `cast_init` and `cast_uninit` methods for pointers
ACP: rust-lang/libs-team#627
Tracking issue: rust-lang/rust#145036
This includes an incredibly low-effort search to find uses that could be switched to using these methods. I only searched for `cast::<\w>` and `cast::<MaybeUninit` because there would otherwise be way too much to look through, and I also didn't modify anything inside submodules/subtrees.
Adjust documentation of `dangling`
I believe the current doc of `dangling` is slightly off as it indicates:
`Note that the pointer value may potentially represent a valid pointer to a T`
The returned pointer has no provenance, so it may not be a valid pointer (except in the case of ZSTs, but I don't think this is what the documentation is trying to warn about).
See: https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Dangling.20pointers.3A.20definition
The value returned by dangling may never be used to dereference a value that isn't a ZST, even if address equality is detected with that of a valid pointer.
This is a minor fix, but this doc still got me confused for a second
Deprecate RUST_TEST_* env variables
Like with rust-lang/rust#139224, this is a documentation-only deprecation for now. Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to compatibility)
Longer term, we expect test runners, like `cargo test`, to provide the necessary mechanisms for environmental or persistent configuration (e.g. using cargo config which supports `.cargo/config.toml` as well as environment variables).
This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)
The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to implement
- Reduce the mechanisms that test runners, like `cargo test`, are expected to track when they are being bypassed to protect against negative interactions, e.g. `RUST_TEST_NOCAPTURE=1` when json output is being read.
For testing-devex FCP, see rust-lang/testing-devex-team#10Fixesrust-lang/testing-devex-team#10
History
-------
At each step, I could not find evidence of design discussions on whether to support CLI, env, or both. The first env variable seems to come from the fact that it was being forked out of an existing env variable that had a much wider scope.
At best, this seems like a way to offer a more persistent configuration for these flags but environment variables hidden away in libtest is a bit clunky and this seems like the wrong layer to handle this problem.
**Originally:** `RUST_THREADS` was respected by the Rust runtime and libextra/test got this for free
**2013:** rust-lang/rust#7335 suggested splitting `RUST_TEST_TASKS` out of `RUST_THREADS`. In that issue and the implementation (rust-lang/rust#8823).
**2014:** rust-lang/rust#13374 ask for support to disable capturing of stdout/stderr. `--nocapture` and `RUST_TEST_NOCAPTURE` were added together.
**2015:** rust-lang/rust#23525 renamed `RUST_TEST_TASKS` to `RUST_TEST_THREADS`
**2016:** rust-lang/rust#25636 asked to configure `RUST_TEST_THREADS` via `--test-threads` which was implemented in rust-lang/rust#35414
**2021:** rust-lang/rust#85440 asked for test randomization which was implemented in rust-lang/rust#89082, adding `--shuffle` / RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED`
Potentially relevant issues
---------------------------
- rust-lang/rust#74845
Constify `SystemTime` methods
This is separated out from rust-lang/rust#143949 due to the fact that it touches nontrivial system code. While the same arithmetic methods on `Instant` could be made const, since that type explicitly cannot be constructed at const-time, we don't bother. However, due to the fact that `SystemTime::UNIX_EPOCH` exists, it can be useful to create other anchors at other points in time, and thus these methods should be possible to use in const context.
> Side comment: I would honestly like to just move every single implementation which is a thin wrapper over `Duration` or some integer clock into their own module which is tested on all targets, so that we don't have to worry about code for lower-tier targets not being tested. However, the comments in `std::sys_common` pointing out the desire to move things to `std::sys::common` confused me, particularly due to the fact that `std::sys::common` is taken from the hellish asterisk-import of `std::sys::pal::common` and others.
>
> I think that, for trivial types like this, we should just have a platform-independent module that can be tested on all platforms, to both ensure that the code is properly tested regardless of whether higher-tier platforms needed, and to avoid the extreme mental gymnastics required to determine where in the code it lies.
>
> However, since I'm not on any of the teams maintaining this code and am not involved, I'll settle for just copy-pasting like everyone else has been doing. I just want to express how I'm not happy about that.
**Reviewer note: please only pay attention to the last commit of this PR, until its blocker is merged.**
Since this depends on the previous PR:
`@rustbot` blocked
Add ASCII-related methods from `u8` and `MIN`/`MAX` to `core::ascii::Char`
* Add ASCII-related methods from `u8` to `core::ascii::Char`.
* Add `core::ascii::Char::MIN` and `core::ascii::Char::MAX`.
Make explicit guarantees about `Vec`’s allocator
This commit amends the documentation of `Vec::as_mut_ptr` and `Vec::into_raw_parts` to make it explicit that such calls may be paired with calls to `dealloc` with a suitable layout. This guarantee was effectively already provided by the docs of `Vec::from_raw_parts` mentioning `alloc`.
Additionally, we copy-paste and adjust the “Memory layout” section from the documentation of `std::boxed` to `std::vec`. This explains the allocator guarantees in more detail.
This is a documentation-only deprecation for now.
Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to
compatibility)
Longer term, we expect test runners, like `cargo test`, to provide the
necessary mechanisms for environmental or persistent configuration (e.g.
using cargo config which supports `.cargo/config.toml` as well as
environment variables).
This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)
The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to
implement
- Reduce the mechanisms that test runners, like `cargo test`, are
expected to track when they are being bypassed to protect against
negative interactions, e.g. `RUST_TEST_NOCAPTURE=1` when json output
is being read.
This commit amends the documentation of `Vec::as_mut_ptr` and
`Vec::into_raw_parts` to make it explicit that such calls may be paired
with calls to `dealloc` with a suitable layout. This guarantee was
effectively already provided by the docs of `Vec::from_raw_parts`
mentioning `alloc`.
Additionally, we copy-paste and adjust the “Memory layout” section from
the documentation of `std::boxed` to `std::vec`. This explains the allocator
guarantees in more detail.
Use a time representation with 1900-01-01-00:00:00 at timezone -1440 min as
anchor. This is the earliest time supported in UEFI.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
std: sys: io: io_slice: Add UEFI types
UEFI networking APIs do support vectored read/write. While the types for UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially the same C struct. So we can map IoSlice and IoSliceMut to have the same binary representation.
Since all UEFI networking types for read/write are DSTs, `IoSlice` and `IoSliceMut` will need to be copied to the end of the transmit/receive structures. So having the same binary representation just allows us to do a single memcpy instead of having to loop and set the DST.
cc ``@nicholasbishop``
document assumptions about `Clone` and `Eq` traits
Most standard library collections break if `Clone` has a non-standard implementation which violates `x.clone() == x`. [Here](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b7fc6dfa8410cbb673eb8d38393d81de) the resulting broken behaviour of different collections is shown. I originally created an issue at https://github.com/rust-lang/hashbrown/issues/629, but the conclusion there was that `x.clone()` resulting in an object that compares equal to the original one is probably a very universal assumption. However, this assumption is (to my knowledge) not documented anywhere.
I propose to make this assumption explicit in the `Clone` trait documentation. The property that seems the most reasonable to me is the following: When implementing both `Clone` and `PartialEq`, then
```text
x == x -> x.clone() == x
```
is expected to hold. This way, when also implementing `Eq`, it automatically follows that `x.clone() == x` has to hold, which should be enough for the collections to not break. At the same time, the property also works for the "normal" elements of a type with `PartialEq`. For the wording, I tried to follow the [`Hash` and `Eq`](https://doc.rust-lang.org/std/hash/trait.Hash.html#hash-and-eq) documentation.
As I am fairly new to Rust, it might well be that this property cannot be generally expected – it seems reasonable to me, but any counter-examples or critique, both content- and wording-wise, would be very welcome. If the property turns out to be too general, I would suggest to at least document the assumption of `x.clone() == x` for the collections somehow.
An additional thought of mine:
If it is indeed generally expected that `x == x -> x.clone() == x`, then, for the sake of completeness, one could also define that `x != x -> y != y for y = x.clone()` should hold, i.e., that an object that did not compare equal to itself before cloning, should also not compare equal to itself afterwards.
Constify remaining traits/impls for `const_ops`
Tracking issue: rust-lang/rust#143802
This is split into two commits for ease of reviewability:
1. Updates the `forward_ref_*` macros to accept multiple attributes (in anticipation of needing `rust_const_unstable` attributes) and also *require* attributes in these macros. Since the default attribute only helps for the initial implementations, it means it's easy to get wrong for future implementations, as shown for the saturating implementations which were incorrect before.
2. Actually constify the traits/impls.
A few random other notes on the implementation specifically:
* I unindented the attributes that were passed to the `forward_ref_*` macro calls because in some places rustfmt wanted them to be unindented, and in others it was allowed because they were themselves inside of macro bodies. I chose the consistent indenting even though I (personally) think it looks worse.
----
As far as the actual changes go, this constifies the following additional traits:
* `Neg`
* `Not`
* `BitAnd`
* `BitOr`
* `BitXor`
* `Shl`
* `Shr`
* `AddAssign`
* `SubAssign`
* `MulAssign`
* `DivAssign`
* `RemAssign`
* `BitAndAssign`
* `BitOrAssign`
* `BitXorAssign`
* `ShlAssign`
* `ShrAssign`
In terms of constified implementations of these traits, it adds the reference-forwarded versions of all the arithmetic operators, which are defined by the macros in `library/core/src/internal_macros.rs`. I'm not going to fully enumerate these because we'd be here all day, but sufficed to say, it effectively allows adding an `&` to one or both sides of an operator for primitives.
Additionally, I constified the implementations for `Wrapping`, `Saturating`, and `NonZero` as well, since all of them forward to already-const-stable methods. (potentially via intrinsics, to avoid extra overhead)
There are three "non-primitive" types which implement these traits, listed below. Note that I put "non-primitive" in quotes since I'm including `Wrapping`, `Saturating`, and `NonZero`, which are just wrappers over primitives.
* `Duration` (arithmetic operations)
* `SystemTime` (arithmetic operations)
* `Ipv4Addr` (bit operations)
* `Ipv6Addr` (bit operations)
Additionally, because the methods on `SystemTime` needed to make these operations const were not marked const, a separate tracking issue for const-stabilising those methods is rust-lang/rust#144517.
Stuff left out of this PR:
* `Assume` (this could trivially be made const, but since the docs indicate this is still under heavy design, I figured I'd leave it out)
* `Instant` (this could be made const, but cannot reasonably be constructed at constant time, so, isn't useful)
* `SystemTime` (will submit separate PR)
* SIMD types (I'm tackling these all at once later; see rust-lang/portable-simd#467)
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_CONCERN-ISSUE_START -->
> [!NOTE]
> # Concerns (0 active)
>
> - ~~[May break Clippy](https://github.com/rust-lang/rust/pull/143949#issuecomment-3081466077)~~ resolved in [this comment](https://github.com/rust-lang/rust/pull/143949#issuecomment-3083628215)
>
> *Managed by ```@rustbot`—see`` [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*
<!-- TRIAGEBOT_CONCERN-ISSUE_END -->
<!-- TRIAGEBOT_END -->
When operating on expressions, `cfg_select!` can now handle expressions
without braces. (It still requires braces for other things, such as
items.)
Expand the test coverage and documentation accordingly.
Replace unsafe `security_attributes` function with safe `inherit_handle` alternative
The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now. However, we only ever set one bool so it's easy enough to replace with something that's actually safe.
In the future we might want to expose the ability for users to set security attributes. But that should be properly designed (and safe!).
