https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=stable 2025-07-29T10:19:51+00:00 2025-07-29T10:19:51+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-07-29T10:19:51+00:00 urn:sha1:4bfbd80babd7186598afae348023580c06a28109 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 2025-07-28T16:09:35+00:00 joboet jonasboettiger@icloud.com 2025-07-26T12:29:00+00:00 urn:sha1:73751a04910d08052bf6b825f8829cacba86c648 2025-07-26T07:19:29+00:00 Trevor Gross t.gross35@gmail.com 2025-07-26T07:19:29+00:00 urn:sha1:2fcea9fb68c8e04f10e5cb15bbfb486de9800afa Guarantee 8 bytes of alignment in Thread::into_raw When using `AtomicPtr` for synchronization it's incredibly useful when you've got a couple bits you can stuff metadata in. By guaranteeing that `Thread`'s `Inner` struct is aligned to 8 bytes everyone can use the bottom 3 bits to signal other things, such as a critical section, etc. This guarantee is thus very useful and costs us nothing. 2025-07-15T21:17:57+00:00 Cameron Steffen cam.steffen94@gmail.com 2025-07-15T19:14:22+00:00 urn:sha1:1120cb2fe54fae7a1a8ccd5beb941f5b207084c0 2025-07-12T23:20:29+00:00 Orson Peters orsonpeters@gmail.com 2025-07-12T23:20:29+00:00 urn:sha1:6f4d0bdde85f9e2a0e61bb3e16d407540ddc09ba 2025-07-12T22:58:46+00:00 Orson Peters orsonpeters@gmail.com 2025-07-12T22:58:12+00:00 urn:sha1:69b9bae57ded527f5fd7f036b6cc1cca0b462ac4 2025-07-06T23:00:51+00:00 bors bors@rust-lang.org 2025-07-06T23:00:51+00:00 urn:sha1:ca98d4d4b3114116203699c2734805547df86f9a Specialize sleep_until implementation for unix (except mac) related tracking issue: https://github.com/rust-lang/rust/issues/113752 Supersedes https://github.com/rust-lang/rust/pull/118480 for the reasons see: https://github.com/rust-lang/rust/issues/113752#issuecomment-2902594469 Replaces the generic catch all implementation with target_os specific ones for: linux/netbsd/freebsd/android/solaris/illumos etc. Other platforms like wasi, macos/ios/tvos/watchos and windows will follow in later separate PR's (once this is merged). 2025-07-06T15:36:49+00:00 dvdsk noreply@davidsk.dev 2025-05-31T13:33:46+00:00 urn:sha1:f24ee2c9b15dc3734e9ebd74ba0563a1e6c545db Using clock nanosleep leads to more accurate sleep times on platforms where it is supported. To enable using clock_nanosleep this makes `sleep_until` platform specific. That unfortunatly requires identical placeholder implementations for the other platforms (windows/mac/wasm etc). we will land platform specific implementations for those later. See the `sleep_until` tracking issue. This requires an accessors for the Instant type. As that accessor is only used on the platforms that have clock_nanosleep it is marked as allow_unused. 32bit time_t targets do not use clock_nanosleep atm, they instead rely on the same placeholder as the other platforms. We could make them use clock_nanosleep too in the future using `__clock_nanosleep_time64`. __clock_nanosleep_time64 is documented at: https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html 2025-07-03T07:51:06+00:00 klensy klensy@users.noreply.github.com 2024-12-07T10:51:08+00:00 urn:sha1:c76d032f0144b650a438ee1efba89c475e0b115b 2025-05-12T13:33:37+00:00 Pietro Albini pietro@pietroalbini.org 2025-05-10T08:51:12+00:00 urn:sha1:2ce08ca5d6046600ff641bfa4018247f3b9451c5