Print thread ID in panic message

[tgross35]

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]

r? @davidtwco

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

[tgross35]

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

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

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[tgross35]

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

[bjorn3]

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]

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]

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]

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]

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

[tgross35]

@joshtriplett do you have any thoughts on this?

[timClicks]

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]

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

r? libs-api

[dtolnay]

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]

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.

[cuviper]

@bors r+ rollup=iffy

[bors]

📌 Commit 1fae81d has been approved by cuviper

It is now in the queue for this repository.

[rustbot]

This PR modifies tests/ui/issues/. If this PR is adding new tests to tests/ui/issues/,
please refrain from doing so, and instead add it to more descriptive subdirectories.

[tgross35]

Rebased in case we picked up some new tests that need adjustment, but from running locally it seems like this is still fine.

@bors r=cuviper

[bors]

📌 Commit 289fe36 has been approved by cuviper

It is now in the queue for this repository.

[bors]

⌛ Testing commit 289fe36 with merge 61cb1e9...

[bors]

☀️ Test successful - checks-actions
Approved by: cuviper
Pushing 61cb1e9 to master...

[github-actions]

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

1. x86_64-apple-1: 10634.5s -> 7029.8s (-33.9%)
2. aarch64-apple: 7102.2s -> 4831.2s (-32.0%)
3. tidy: 109.1s -> 130.8s (19.9%)
4. dist-x86_64-apple: 10256.2s -> 11471.1s (11.8%)
5. dist-aarch64-linux: 5681.3s -> 6319.9s (11.2%)
6. x86_64-msvc-ext2: 5929.4s -> 6483.7s (9.3%)
7. aarch64-gnu-llvm-19-2: 2610.6s -> 2388.9s (-8.5%)
8. dist-x86_64-musl: 7548.0s -> 8130.3s (7.7%)
9. dist-aarch64-apple: 6820.2s -> 6332.8s (-7.1%)
10. 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]

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]

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]

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();

?