Skip to content

Fix LazyLock poison panic message #145307

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

connortsui20
Copy link
Contributor

Fixes the issue raised in #144872 (comment)

r? @Amanieu

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 12, 2025
Fixes an issue where if the underlying `Once` panics because it is
poisoned, the panic displays the wrong message.

Also consolidates all of the `Once` panic messages in one place so that
we don't have to edit the message in 6 different files if we want to
change it.

Signed-off-by: Connor Tsui <[email protected]>

// If the internal `Once` is poisoned, it will panic with "Once instance has previously been
// poisoned", but we want to panic with "LazyLock instance ..." instead.
let result = panic::catch_unwind(AssertUnwindSafe(call_once_closure));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

catch_unwind can't be used to override the panic message. By the time catch_unwind returns, the panic message has already been printed. In addition catch_unwind would cause an abort in case of a foreign exception.

Maybe you can have an internal method like call_once except with a panic message as argument?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm that does make sense, but at the same time I think it's fine if the user gets 2 error messages?

I'm a bit worried about the footprint of updating the internal call_once method with a panic message as argument since that would require changing all of the underlying implementations as well. But if that is the only acceptable way then I'm happy to do it

/// instance has previously been poisoned") instead of the underlying `Once` error message.
#[test]
#[cfg_attr(not(panic = "unwind"), ignore = "test requires unwinding support")]
#[should_panic(expected = "LazyLock instance has previously been poisoned")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason this test passes is because #[should_panic(expected = "...")] likely checks the last panic message, not the first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants