Migrate the standard library from using the external `cfg_if` crate to
using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from
`library/std/Cargo.toml`, because while the standard library itself no
longer uses `cfg_if`, it also incorporates the `backtrace` crate, which
does.
Migration assisted by the following vim command (after selecting the
full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This
prompts for confirmation on the `} else {` since that can also appear
inside one of the arms. This also requires manual intervention to handle
any multi-line conditions.
Revert "Partially outline code inside the panic! macro".
This reverts https://github.com/rust-lang/rust/pull/115670
Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect. (And if it did, whether that effect is still achieved today.)
Stabilize `const_exposed_provenance` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/144538) and stabilises `fn with_exposed_provenance` and `fn with_exposed_provenance_mut` in const
Implement `#[derive(From)]`
Implements the `#[derive(From)]` feature ([tracking issue](https://github.com/rust-lang/rust/issues/144889), [RFC](https://github.com/rust-lang/rfcs/pull/3809)).
It allows deriving the `From` impl on structs and tuple structs with exactly one field. Some implementation notes:
- I wasn't exactly sure which spans to use in the derive generating code, so I just used `span` everywhere. I don't know if it's the Right Thing To Do. In particular the errors when `#[derive(From)]` is used on a struct with an unsized field are weirdly duplicated.
- I had to solve an import stability problem, where if I just added the unstable `macro From` to `core::convert`, previously working code like `use std::convert::From` would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. `@petrochenkov` suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?).
- I had to add `Ty::AstTy`, because the `from` function receives an argument with the type of the single field, and the existing variants of the `Ty` enum couldn't represent an arbitrary type.
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.
This is practically a revert of a revert, making the
commit e907456b2e10622ccd854a3bba8d02ce170b5dbb on `stdarch` come around
again with minor fixes, enhancements and adjustments.
An excerpt from the original commit message follows:
Since there's no architectural feature detection on RISC-V (unlike `CPUID`
on x86 architectures and some system registers on Arm/AArch64), runtime
feature detection entirely depends on the platform-specific facility.
As a result, availability of each feature heavily depends on the platform
and its version.
To help users make a decision for feature checking on a RISC-V system, this
commit adds a platform guide with minimum supported platform versions.
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
Currently they are skipped, which is a bit weird, and it sometimes
causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`.
Most regions are erased by the time `type_name` does its work. So all
regions are now printed as `'_` in non-optional places. Not perfect, but
better than the status quo.
`c_name` is updated to trim lifetimes from MIR pass names, so that the
`PASS_NAMES` sanity check still works. It is also renamed as
`simplify_pass_type_name` and made non-const, because it doesn't need
to be const and the non-const implementation is much shorter.
The commit also renames `should_print_region` as
`should_print_optional_region`, which makes it clearer that it only
applies to some regions.
Fixes#145168.
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`.
Without any tests/benchmarks that show some improvement, it's hard to
know whether the change had any positive effect at all. (And if it did,
whether that effect is still achieved today.)
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.
Josh Triplett