Print thread ID in panic message #115746

tgross35 · 2023-09-11T05:19:01Z

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

rustbot · 2023-09-11T05:19:09Z

r? @davidtwco

(rustbot has picked a reviewer for you, use r? to override)

tgross35 · 2023-09-11T05:19:52Z

I think this needs FCP since it's a visible change

@rustbot label -T-libs -T-compiler +T-libs-api
r? libs-api

rustbot · 2023-09-11T05:35:09Z

The Miri subtree was changed

cc @rust-lang/miri

tgross35 · 2023-09-11T06:21:00Z

cc @m-ou-se since you recently did the formatting in #112849

bjorn3 · 2023-09-11T08:16:28Z

Maybe

thread '<unnamed 2>' panicked at src/main.rs:3:5:
explicit panic

or

thread '<unnamed#2>' panicked at src/main.rs:3:5:
explicit panic

? That fits more with the way named threads are shown.

the8472 · 2023-09-11T09:22:55Z

Note that this is a rust-internal thread ID, which isn't the OS thread ID which can be relevant if you're also logging from C code or looking at things with GDB. And as_u64() is unstable and there are questions about stabilizing it (#110738).

tgross35 · 2023-09-11T10:04:18Z

Maybe

thread '<unnamed 2>' panicked at src/main.rs:3:5:
explicit panic

or

thread '<unnamed#2>' panicked at src/main.rs:3:5:
explicit panic

I just proposed the syntax as a demo, figured libs-api would make the final choice - though between those two, I like the first one better

Note that this is a rust-internal thread ID, which isn't the OS thread ID which can be relevant if you're also logging from C code or looking at things with GDB. And as_u64() is unstable and there are questions about stabilizing it (#110738).

It is kind of unfortunate that Rust and C won't use the same thread IDs. But this seems worthwhile still - Rust-only applications printing the thread ID in logs is common (tracing even has a builtin way to do this), probably more common than Rust thread IDs silently mixing with C thread IDs in logs. And even in that case, it still gives you something more concrete to trace than "something failed".

This is all inspired by the below failure I recently had in an highly threaded system. The entire backtrace uselessly displayed one repeated function, with no hints about which preceding log events were relevant:

thread '<unnamed>' panicked at src/scan.rs:101:55:
called `Result::unwrap()` on an `Err` value: ()
stack backtrace:
   0:        0x1009661d0 - __mh_execute_header
   1:        0x10088869b - __mh_execute_header
   2:        0x10093ba0e - __mh_execute_header
   4:        0x10096757c - __mh_execute_header
   5:        0x100968632 - __mh_execute_header
   6:        0x1009680f4 - __mh_execute_header
   7:        0x100968059 - __mh_execute_header
   8:        0x100968042 - __mh_execute_header
   9:        0x100bdd913 - __mh_execute_header

I don't think that stability of the thread ID is much of a concern since we will always have some integer ID for a thread, even if the semantics of that ID might change. The important thing is probably just that this panic message thread ID is the same as what shows up as Debug for ThreadId (or as_u64 as applicable) since that is what other libraries are directed to use. That is the case here

tgross35 · 2023-09-15T07:18:44Z

Another display option - it looks a bit cleaner to not even call out that a thread is unnamed, and I don't think it adds much

thread with ID 2 panicked at src/main.rs:3:5:
explicit panic

Or we could use ThreadId's debug formatting which tracing and I think log do, but that seems unnecessarily clunky

thread with `ThreadId(2)` panicked at src/main.rs:3:5:
explicit panic

I also tried to poke some discussion at #67939

bors · 2023-09-19T19:48:12Z

☔ The latest upstream changes (presumably #115627) made this pull request unmergeable. Please resolve the merge conflicts.

tgross35 · 2023-10-23T23:50:36Z

@joshtriplett do you have any thoughts on this?

timClicks · 2023-11-10T03:02:51Z

Sorry to add bike shedding to the thread. Here is a slight derivative of the last suggestion, which omits a "with":

thread `ThreadId(2)` panicked at src/main.rs:3:5:
explicit panic

Although it's uglier than using the thread identifier in a sentence, using the Debug form makes it look like a Rust value rather than something else. It's also consistent with other output from Rust, although the case can definitely be made that thread IDs deserve a special case.

tgross35 · 2023-12-01T05:35:09Z

I know Josh has a pretty busy queue, so perhaps it is best to reroll

r? libs-api

dtolnay · 2023-12-01T06:37:52Z

I think this needs FCP since it's a visible change

@rustbot label -T-libs -T-compiler +T-libs-api

I think it wouldn't need one. T-libs-api FCP is primarily for any time a permanent API commitment is being made by the standard library, and deprecations. In contrast, anything that we can just change back with minimal effort or disruption would not warrant FCP.

#112849 had a T-libs FCP but I am not familiar with their criteria for that. @rust-lang/libs would you want to handle this PR?

In any case, this looks good to me.

thomcc · 2023-12-01T06:44:15Z

I don't know that this needs FCP. I'm not opposed and there is precedent for it, but OTOH we wouldn't FCP a panic message change somewhere in the stdlib. So I don't feel strongly.

In any case, I think this change is a good idea, and am in favor.

github-actions · 2025-08-07T06:03:14Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 6bcdcc7 (parent) -> 61cb1e9 (this PR)

Test differences

Show 5 test diffs

Stage 1

thread::tests::test_thread_os_id_not_equal: [missing] -> pass (J0)

Additionally, 4 doctest diffs were found. These are ignored, as they are noisy.

Job group index

J0: aarch64-apple, aarch64-gnu, aarch64-gnu-llvm-19-1, aarch64-msvc-1, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-gnu-nopt-2, i686-msvc-1, pr-check-2, test-various, x86_64-apple-1, x86_64-gnu, x86_64-gnu-aux, x86_64-gnu-llvm-19-2, x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-2, x86_64-gnu-llvm-20-3, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 61cb1e97fcf954c37d0a457a8084ed9ad8b3cb82 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

x86_64-apple-1: 10634.5s -> 7029.8s (-33.9%)
aarch64-apple: 7102.2s -> 4831.2s (-32.0%)
tidy: 109.1s -> 130.8s (19.9%)
dist-x86_64-apple: 10256.2s -> 11471.1s (11.8%)
dist-aarch64-linux: 5681.3s -> 6319.9s (11.2%)
x86_64-msvc-ext2: 5929.4s -> 6483.7s (9.3%)
aarch64-gnu-llvm-19-2: 2610.6s -> 2388.9s (-8.5%)
dist-x86_64-musl: 7548.0s -> 8130.3s (7.7%)
dist-aarch64-apple: 6820.2s -> 6332.8s (-7.1%)
x86_64-gnu-llvm-20-1: 3601.8s -> 3344.9s (-7.1%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-08-07T07:14:15Z

Finished benchmarking commit (61cb1e9): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.6%	[-0.6%, -0.6%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -0.0%, secondary 3.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	3.8%	[3.8%, 3.8%]	1
Improvements ✅ (primary)	-3.1%	[-3.1%, -3.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.0%	[-3.1%, 3.1%]	2

Cycles

Results (primary -2.7%, secondary 1.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	8.8%	[8.8%, 8.8%]	1
Improvements ✅ (primary)	-2.7%	[-2.7%, -2.7%]	1
Improvements ✅ (secondary)	-5.4%	[-5.4%, -5.4%]	1
All ❌✅ (primary)	-2.7%	[-2.7%, -2.7%]	1

Binary size

Results (primary 0.1%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.1%]	8
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	36
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.0%, 0.1%]	8

Bootstrap: 465.172s -> 464.27s (-0.19%)
Artifact size: 377.40 MiB -> 377.42 MiB (0.00%)

matthiaskrgr · 2025-08-07T17:29:17Z

is there a way to disable this somehow?
I need to be able to deduplicate ICEs by panic message which no longer works because there is now this unique thread id everywhere lol

thread 'rustc' (4177193) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (1391033) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (1624389) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (1843097) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2090645) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2317017) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2544727) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2766673) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2886828) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2902558) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2997793) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (3202048) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (3220713) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (3449388) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (3570138) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (3664373) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (3799135) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (3886577) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (4052293) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (4107610) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (141970) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (171035) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (365708) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (601993) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (843766) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (1088718) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (1330640) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (1579684) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (1829619) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2068333) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2305687) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2551740) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2614985) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'
thread 'rustc' (2771709) panicked at compiler/rustc_mir_transform/src/simplify_comparison_integral.rs:58:57: 'called `Option::unwrap()` on a `None` value'

tgross35 · 2025-08-07T17:38:33Z

There is not any way currently. It's probably possible but that's just an extra knob that we should probably avoid. Can you preprocess the text before saving or before deduplicating, like compiletest does

rust/src/tools/compiletest/src/runtest.rs

Lines 2570 to 2573 in 321a89b

    
           // Normalize thread IDs in panic messages 
        
           normalized = static_regex!(r"thread '(?P<name>.*?)' \((rtid )?\d+\) panicked") 
        
               .replace_all(&normalized, "thread '$name' ($$TID) panicked") 
        
               .into_owned();

?

rust-lang/rust#115746 changed to print thread ID so we update accordinly.

rust-lang/rust#115746 changed to print thread ID, so we update accordingly.

rust-lang/rust#115746 changed to print thread ID, so we update accordingly. See <https://github.com/rust-lang/cargo/actions/runs/16839675728/job/47707652618?pr=15821>

Fix wasm target build with atomics feature Introduced by rust-lang#115746 close rust-lang#145101

Rollup merge of #145096 - Spxg:w/wasm_atomic, r=tgross35 Fix wasm target build with atomics feature Introduced by #115746 close #145101

…ge, r=cuviper 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

Fix wasm target build with atomics feature Introduced by rust-lang#115746 close rust-lang#145101

HKalbasi · 2025-08-14T15:21:26Z

This makes snapshot testing of rust programs that panic very hard, since the id will change in each run. A way to disable this is much appreciated. If a specific knob for this is too much, I would suggest showing this only on RUST_BACKTRACE=1.

tgross35 · 2025-08-14T23:14:10Z

Is there any reason the snapshots can't normalize the message? (e.g. #115746 (comment))

HKalbasi · 2025-08-14T23:47:14Z

It is not the end of the world, there are workarounds like that normalization. It's just a tradeoff between creating work for people working with the output of panicking Rust binaries, and annoying people who need this thread id feature by forcing them to use RUST_BACKTRACE=1. I guess the number of people in the first group are more, but I'm definitely biased.

tgross35 · 2025-08-15T00:30:19Z

So, the main motivation for this change is when the thread ID is printed as part of log/tracing output and then seeing a panic, which allows tying the panic to the exact events that happened before it (previously not possible in multithreaded applications unless you set the thread name, which might also not be possible depending on what library spawned it). I think that requiring RUST_BACKTRACE would be a step backward because if you happen to forget to set it, that association is lost again. And it becomes something that you need to actually know about in order to benefit from.

I also don't understand what makes this a "very hard" thing to adjust to: it seems like it should be reasonably trivial, ours was a three line change. Of course it's unfortunate that all snapshot libraries need to handle this, but we don't guarantee panic output so infrequent changes are expected if you're doing a 1:1 comparison (which should be way less frequent than something like #[should_panic = "hi"]).

I don't mind discussing further, but it should be in a new issue (there are nearly 20 people on this thread and it's closed anyway).

Fix all the broken intra-doc links docs(build-rs): Fix broken intra-doc links These were caught with the latest nightly This was pulled from rust-lang#15800 chore(deps): update rust crate cargo_metadata to 0.21.0 docs: `-Zpackage-workspace` has been stabilized chore: bump to 0.92.0 docs: update changelog for 1.90.0 Add test for multiple build scripts in different order Preserve order of build scripts Update semver tests for 1.89 This updates the tests where messages have changed in 1.89. chore(deps): update msrv (1 version) to v1.89 chore: Bump versions test(build-std): relax the thread name assertion rust-lang/rust#115746 changed to print thread ID, so we update accordingly. chore(deps): update cargo-semver-checks to v0.43.0 docs(unstable): Link out to the Plumbing commands effort This is intended to help people discover where to go to discuss plumbing command efforts. chore(deps): update compatible add is_inherited method to InheritableDependency add is_inherited method to InheritableField Add unstable `-Zsection-timings` flag Pass `--json=timings` to rustc when `--timings` and `-Zsection-timings` is enabled Parse and store section timing events Add section timing data to JSON `--timings` output Make headers of the HTML `--timings` unit table dynamic Add compilation sections to the HTML unit table Duplicates of unknown_feature test More helpful error for invalid cargo-features = [] test(package): Add test to verify package build cache behavior fix(package): Fixed inconsistent build cache behavior during package verify When running `cargo package` the verify the build cache (target-dir/build-dir) will not be used and all dependencies will be recompiled. This is inconsistent as setting target dir (via `CARGO_TARGET_DIR` for example) will cause `cargo package` to reuse the build cache. This commit changes the default behavior to always use the build cache, matching the behavior of having target-dir set. chore(deps): update msrv (3 versions) to v1.87 chore: remove x86_64-apple-darwin from CI and tests RFC 3841 has merged, and x86_64-apple-darwin will be demoted to tier-2 in 1.90.0. In Cargo we usually run test against tier-1 platforms, so x86_64-apple-darwin should be removed. Also, that target platform is often the slowest one in CI, we are happy to remove it to save us a couple of minutes. https://rust-lang.github.io/rfcs/3841-demote-x86_64-apple-darwin.html chore(deps): bump slab from 0.4.10 to 0.4.11 Bumps [slab](https://github.com/tokio-rs/slab) from 0.4.10 to 0.4.11. - [Release notes](https://github.com/tokio-rs/slab/releases) - [Changelog](https://github.com/tokio-rs/slab/blob/master/CHANGELOG.md) - [Commits](tokio-rs/slab@v0.4.10...v0.4.11) --- updated-dependencies: - dependency-name: slab dependency-version: 0.4.11 dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]> refactor: make resolve features public feat(build-dir): Stabilize build-dir docs: Formatting and cross-linking to build-dir/target-dir docs Update src/doc/man/cargo-doc.md as per the feedback recieved regenerated pages using cargo build-man and ran ./ci/validate-man.sh and sync branch with master branch

rustbot assigned davidtwco Sep 11, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 11, 2023

rustbot added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 11, 2023

rustbot assigned joshtriplett and unassigned davidtwco Sep 11, 2023

tgross35 force-pushed the unnamed-threads-panic-message branch from d68fab6 to 371dd28 Compare September 11, 2023 05:35

tgross35 force-pushed the unnamed-threads-panic-message branch 2 times, most recently from 8e72037 to 3da1046 Compare September 11, 2023 06:13

rustbot removed the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 11, 2023

tgross35 force-pushed the unnamed-threads-panic-message branch from 3da1046 to e055544 Compare November 9, 2023 17:20

rustbot assigned dtolnay and unassigned joshtriplett Dec 1, 2023

dtolnay approved these changes Dec 1, 2023

View reviewed changes

bors merged commit 61cb1e9 into rust-lang:master Aug 7, 2025
11 checks passed

rustbot added this to the 1.91.0 milestone Aug 7, 2025

tgross35 deleted the unnamed-threads-panic-message branch August 7, 2025 06:02

This was referenced Aug 7, 2025

ci: Begin running ui tests with rust.debuginfo-level-tests=1 #144499

Open

Add fast-path for accessing the current thread id #143069

Open

Spxg mentioned this pull request Aug 8, 2025

Fix wasm target build with atomics feature #145096

Merged

weihanglo added a commit to weihanglo/cargo that referenced this pull request Aug 8, 2025

test(build-std): relax the thread name assertion

b9b3729

rust-lang/rust#115746 changed to print thread ID so we update accordinly.

weihanglo added a commit to weihanglo/cargo that referenced this pull request Aug 8, 2025

test(build-std): relax the thread name assertion

58ff5ef

rust-lang/rust#115746 changed to print thread ID, so we update accordingly.

weihanglo mentioned this pull request Aug 8, 2025

test(build-std): relax the thread name assertion rust-lang/cargo#15822

Merged

Zalathar added a commit to Zalathar/rust that referenced this pull request Aug 9, 2025

Rollup merge of rust-lang#145096 - Spxg:w/wasm_atomic, r=tgross35

f47557c

Fix wasm target build with atomics feature Introduced by rust-lang#115746 close rust-lang#145101

rust-timer added a commit that referenced this pull request Aug 9, 2025

Unrolled build for #145096

2265486

Rollup merge of #145096 - Spxg:w/wasm_atomic, r=tgross35 Fix wasm target build with atomics feature Introduced by #115746 close #145101

saethlin mentioned this pull request Aug 10, 2025

Panics don't work on Android since TIDs were added to panic messages rust-lang/miri#4519

Closed

github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request Aug 12, 2025

Rollup merge of rust-lang#145096 - Spxg:w/wasm_atomic, r=tgross35

f82e30c

Fix wasm target build with atomics feature Introduced by rust-lang#115746 close rust-lang#145101

smoelius added a commit to trailofbits/cast_checks that referenced this pull request Aug 13, 2025

Account for rust-lang/rust#115746

0be33bc

smoelius added a commit to trailofbits/cast_checks that referenced this pull request Aug 13, 2025

Account for rust-lang/rust#115746

3dc078b

HKalbasi mentioned this pull request Aug 14, 2025

Get underling values of Fields HKalbasi/zngur#49

Open

matthiaskrgr mentioned this pull request Aug 15, 2025

rustc output no longer reproducible if it crashes #145424

Open

nickpdemarco added a commit to nickpdemarco/zngur that referenced this pull request Aug 15, 2025

Switch to rust stable to work around rust-lang/rust#115746

c5b992d

Print thread ID in panic message #115746

Print thread ID in panic message #115746

Conversation

tgross35 commented Sep 11, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 11, 2023

Uh oh!

tgross35 commented Sep 11, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 11, 2023

Uh oh!

tgross35 commented Sep 11, 2023

Uh oh!

bjorn3 commented Sep 11, 2023

Uh oh!

the8472 commented Sep 11, 2023

Uh oh!

tgross35 commented Sep 11, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgross35 commented Sep 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bors commented Sep 19, 2023

Uh oh!

tgross35 commented Oct 23, 2023

Uh oh!

timClicks commented Nov 10, 2023

Uh oh!

tgross35 commented Dec 1, 2023

Uh oh!

dtolnay commented Dec 1, 2023

Uh oh!

thomcc commented Dec 1, 2023

Uh oh!

Uh oh!

github-actions bot commented Aug 7, 2025

Test differences

Stage 1

Job duration changes

Uh oh!

rust-timer commented Aug 7, 2025

Overall result: ✅ improvements - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

matthiaskrgr commented Aug 7, 2025

Uh oh!

tgross35 commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HKalbasi commented Aug 14, 2025

Uh oh!

tgross35 commented Aug 14, 2025

Uh oh!

HKalbasi commented Aug 14, 2025

Uh oh!

tgross35 commented Aug 15, 2025

Uh oh!

Uh oh!

tgross35 commented Sep 11, 2023 •

edited

Loading

tgross35 commented Sep 11, 2023 •

edited

Loading

tgross35 commented Sep 11, 2023 •

edited

Loading

tgross35 commented Sep 15, 2023 •

edited

Loading

tgross35 commented Aug 7, 2025 •

edited

Loading