Debug-print result when an unstable fingerprint is detected

[Aaron1011]

Helps with issues like #83311

I had previously tried to do this in #80692, but it had a significant performance impact (even though the code was never actually run). Hopefully, this will be better now that #79100 has been merged.

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 443cef5 with merge 42a82e0e789fcafa494356e56cfe095c3309f6f6...

[bors]

☀️ Try build successful - checks-actions
Build commit: 42a82e0e789fcafa494356e56cfe095c3309f6f6 (42a82e0e789fcafa494356e56cfe095c3309f6f6)

[rust-timer]

Queued 42a82e0e789fcafa494356e56cfe095c3309f6f6 with parent f5f33ec, future comparison URL.

[rust-timer]

Finished benchmarking try commit (42a82e0e789fcafa494356e56cfe095c3309f6f6): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[lcnr]

this actually looks like a small perf improvement?

well, i guess as it isn't a regression:
@bors r+

[bors]

📌 Commit 443cef5 has been approved by lcnr

[bors]

⌛ Testing commit 443cef5 with merge 61edfd5...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 61edfd5 to master...

[klensy]

this actually looks like a small perf improvement?

But how it can be improvement, if there only thing changed is added new string for format! output? Strange.

[Aaron1011]

Yeah, the performance improvement is quite odd. Maybe the additional code we generate causes LLVM to decide to not inline something, which ends up improving performance?