rustc output no longer reproducible if it crashes

[matthiaskrgr]

I tried this code:

pub fn main() { break rust }

command:
RUST_BACKTRACE=0 RUSTC_ICE=0 rustc a.rs

I expected to see this happen:
Equal output on all runs (current behavior on stable 1.89.0 )

Instead, this happened:
thread id that changes every run

--- 1	2025-08-15 08:31:33.671734318 +0200
+++ 2	2025-08-15 08:31:34.932738329 +0200
@@ -21,7 +21,7 @@
   = note: rustc 1.91.0-nightly (898aff704 2025-08-14) running on x86_64-unknown-linux-gnu


-thread 'rustc' (3427246) panicked at compiler/rustc_hir_typeck/src/lib.rs:549:10:
+thread 'rustc' (3427309) panicked at compiler/rustc_hir_typeck/src/lib.rs:549:10:
 Box<dyn Any>
 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Meta

since #115746

rustc --version --verbose:

rustc 1.91.0-nightly (898aff704 2025-08-14)
binary: rustc
commit-hash: 898aff704d6f0d00343f21d31b8b9bfac8e43007
commit-date: 2025-08-14
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0

[Noratrieb]

Why do you want this to be supported?

[matthiaskrgr]

#115746 (comment)

#115746 (comment)

[tgross35]

Would it be possible to explain why preprocessing isn't an option for applications that need exact panic output? Nothing on the PR thread clarifies what makes this infeasible, and we even provide a regex to do the normalization

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

.

If it's something related to not having a Rust wrapper available, any reason piping through rustc main.rs 2> >(sed 's/([[:digit:]]*) panicked/panicked/' >&2) wouldn't work?

[matthiaskrgr]

Is sed available on windows?

[tgross35]

Is that meant to be a rhetorical question? I assume you know more about your environment than I do.

The powershell equivalent would be 2>&1 | %{$_ -replace "\(\d+\) panicked","panicked"}, I'm not sure about redirecting only stderr if it matters.

[matthiaskrgr]

What I mean is, we would need a potentially workaround for every os/platform that rust runs on.

I also don't know how third party tools that deal with rust, such as tree-crasher, cargo-minimize, cargo-bisect-rustc handle it, but I did built mine on the assumption that rustc is kind of deterministic as it was the case back then.

Using a regex to edit rustc output has a bunch of drawbacks.
Additional complexity
The output may change without anyone noticing and the regex no longer works.
I've had edgecases where I could not load the entire output of rustc into memory due to OOM (32gb), I don't know if this is still possible though.

Maybe only printing the threadID with RUST_BACKTRACE=full is a solution?

[HKalbasi]

Replying to the #115746 (comment) here to not spam that thread:

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 see the value of this, and while I don't have a use for it in my current projects since my logs don't print thread ID, I can definitely imagine that this might save someone's day in debugging the panics.

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.

This is a problem with RUST_BACKTRACE. It happened many times to me that I needed the backtrace but RUST_BACKTRACE was off, and I needed to rerun my program, sometimes it was hard to reproduce the panic again. You may want to argue that RUST_BACKTRACE=1 is a better default, which I agree, but there is value in RUST_BACKTRACE=0. It hides information people don't want in their panic logs. People don't want full stack trace sometimes, because it costs performance and bloats the logs, and they don't want thread id sometimes, because it makes the logs nondeterministic.

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

That's exactly the point. It's easier for me to implement the normalization than discussing about it here. But I guess I'm not alone, and I want to speak on behalf of people who are using stable and are going to break in a few weeks. The fact that it is easy for me does not mean that it is easy for them as well, they may have not access to the code to change the result, they may need to support multiple platforms, rust panics (or even rust itself) might be a small part of the project, making it hard to justify the normalizing code, and there may be more problems unknown to me. Even if it was easy, it is still some code to maintain forever in every of these.

but we don't guarantee panic output so infrequent changes are expected if you're doing a 1:1 comparison

I don't expect them to be stable, and I'm fine if they break in every release, but adding thread id make it to break on every run, which make things more complex.