https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=beta 2025-09-12T10:02:10+00:00 2025-09-12T10:02:10+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-12T10:02:10+00:00 urn:sha1:1037c082bc7d3ccd803b3eb0d48fc7fd81ddc733 thread parking: fix docs and examples Fixes https://github.com/rust-lang/rust/issues/145816 r? ```@joboet``` Cc ```@m-ou-se``` ```@Amanieu``` 2025-09-10T13:26:17+00:00 joboet jonasboettiger@icloud.com 2025-08-09T17:07:08+00:00 urn:sha1:ad08577a503dfd03e308bd272e76d95e31c6d0ef 2025-09-03T07:14:25+00:00 Ralf Jung post@ralfj.de 2025-08-26T16:12:36+00:00 urn:sha1:39d51d04e706dee462ac4a17508ed87eb52e7715 2025-08-19T23:05:19+00:00 Quinn Tucker qxzcode@users.noreply.github.com 2025-08-19T23:05:19+00:00 urn:sha1:e84d29284c0f4d83e4033b39c6f21826d448373b 2025-08-19T21:14:26+00:00 Quinn Tucker qxzcode@users.noreply.github.com 2025-08-19T21:14:26+00:00 urn:sha1:14022c8a9a3c667f24602fae3cbfad9a3ead50b1 2025-08-19T20:47:25+00:00 Quinn Tucker qxzcode@users.noreply.github.com 2025-08-19T20:47:25+00:00 urn:sha1:d0841c7decfa4a9cda77c0078c9140036273133f 2025-08-16T12:28:31+00:00 Josh Triplett josh@joshtriplett.org 2025-08-10T21:25:43+00:00 urn:sha1:1ae4a0cc3487f28b29f36afe8056535afad21e7b 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. 2025-08-06T23:59:47+00:00 Trevor Gross tmgross@umich.edu 2023-09-11T04:59:31+00:00 urn:sha1:289fe36d373c5a13fa7f1b93f39ff88425ab2351 `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. 2025-08-04T01:24:36+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-08-04T01:24:36+00:00 urn:sha1:e65201ccb88c5abee4cd02fa619620fc63b5325f `available_parallelism`: Add documentation for why we don't look at `ulimit` 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