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
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>
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.
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``
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!).
`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".
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.
Fix doc comment of File::try_lock and File::try_lock_shared
The doc comments of functions `File::try_lock` and `File::try_lock_shared` stabilized today in version 1.89.0 document an incorrect type of `Ok`.
The result type was changed in rust-lang/rust#139343 after the latest change to the doc comments in rust-lang/rust#136876.
compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled
Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled.
Enabling LSE is the primary motivator for rust-lang/rust#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE.
r? ```````@tgross35```````
bump bootstrap compiler to 1.90 beta
There were significantly less `cfg(bootstrap)` and `cfg(not(bootstrap))` this release. Presumably due to the fact that we change the bootstrap stage orderings to reduce the need for them and it was successful 🙏
Miri: non-deterministic floating point operations in `foreign_items`
Part of [rust-lang/miri/#3555](https://github.com/rust-lang/miri/issues/3555#issue-2278914000), this pr does the `foreign_items` work.
Some things have changed since rust-lang/rust#138062 and rust-lang/rust#142514. I moved the "helpers" used for creating fixed outputs and clamping operations to their defined ranges to `math.rs`. These are now also extended to handle the floating-point operations in `foreign_items`. Tests in `miri/tests/float.rs` were changed/added.
Failing tests in `std` were extracted, run under miri with `-Zmiri-many-seeds=0..1000` and changed accordingly. Double checked with `-Zmiri-many-seeds`.
I noticed that the C standard doesn't specify the output ranges for all of its mathematical operations; it just specifies them as:
```
Returns
The sinh functions return sinh x.
```
So I used [Wolfram|Alpha](https://www.wolframalpha.com/).
Print thread ID in panic message
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (12345) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: dist-apple-various
try-job: dist-various-*
try-job: dist-x86_64-freebsd
try-job: dist-x86_64-illumos
try-job: dist-x86_64-netbsd
try-job: dist-x86_64-solaris
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-mingw-1
try-job: x86_64-msvc-1
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
add code example showing that file_prefix treats dotfiles as the name of a file, not an extension
This came up in a libs-api meeting while we were reviewing rust-lang/rust#144870
Change visibility of Args new function
Currently the Args new function is constrained to pub(super) but this stops me from being able to construct Args structs in unit tests.
This pull request is to change this to pub.
