Document panic from thread::current

[dtolnay]

Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=978be7b8cb9d857f33f217ab4ff13eca

extern "C" fn get_thread() {
    let _ = std::panic::catch_unwind(std::thread::current);
}

fn main() {
    unsafe { libc::atexit(get_thread) };
}

thread '<unnamed>' panicked at 'use of std::thread::current() is not possible after the thread's local data has been destroyed', library/std/src/thread/mod.rs:733:5
stack backtrace:
   5: core::option::Option<T>::expect
             at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/core/src/option.rs:741:21
   6: std::thread::current
             at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/thread/mod.rs:733:5
   7: core::ops::function::FnOnce::call_once
             at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/core/src/ops/function.rs:251:5
  11: std::panic::catch_unwind
             at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panic.rs:137:14
  12: playground::get_thread
             at ./[src/main.rs:2](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021#):13
  14: exit
  15: __libc_start_main
  16: _start

[rustbot]

r? @thomcc

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

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[dtolnay]

Not sure whether we're able to guarantee a safe panic in this situation, or if this use of atexit is unsound.

@rfcbot poll libs Guarantee panic?

[rfcbot]

Team member @dtolnay has asked teams: T-libs, for consensus on:

Guarantee panic?

• @Amanieu
• @cuviper
• @joshtriplett
• @m-ou-se
• @the8472

[thomcc]

Guaranteeing anything after main is probably pretty difficult in general.

[thomcc]

In particular, if an implementation ran TLS dtors for the main thread after calling atexit callbacks, I'm unsure how we would implement this if we wanted to guarantee panic in that case -- we could do it in the case where we control main(), but that's not guaranteed.

I think it's reasonable to document that this will panic in some cases, though.

[ChrisDenton]

See also Windows.

In general I think it'd be good to actually document that the stdlib should not be used before/after main (or at least that your on your own if you try). But by the same token we can't really guarantee anything specific happens if you do do stuff before or after main. At least not in a cross-platform way.

[cuviper]

Why not just remove the guarantee?

Suggested change

	/// Panics if called beyond the end of `main`, when the Rust standard library's
	/// This may panic if called beyond the end of `main`, if the Rust standard library's

[the8472]

This isn't really the right place to mention this, as ChrisDenton said it would be good to have some module documentation (perhaps on the std top level module) explaining this and then linking to that section.

[dtolnay]

I'll look for a spot. Is it fair to say 100% of libcore is fine to use before/after main, but the default assumption for libstd stuff like std::thread and std::io is it's UB to use before/after main, with the observable behavior being indistinguishable from a panic in the best case? How about liballoc?

[the8472]

Some core and alloc functions could get poisoned through hooks like the global allocator or panic hooks.

I'll look for a spot.

Since this affects multiple modules maybe the top level?

the default assumption for libstd stuff like std::thread and std::io is it's UB to use before/after main, with the observable behavior being indistinguishable from a panic in the best case

That's a tough one, I guess it's true that there might be UB lurking somewhere but feels a bit like a "known to the state of california to cause cancer" statement.

[thomcc]

Technically there are some functions that are probably UB on Windows. In particular when you're running before main on Windows, the loader lock is likely held, and we may call into functions that are UB if the loader lock is helt (but in practice these are likely to be just a deadlock).

We historically have taken measures to reduce the damage of UB (usually by mitigating it into a "does not work" state) from doing stuff to std before main, as people do do it. I would certainly like to discourage it, though.

[ChrisDenton]

with the observable behavior being indistinguishable from a panic in the best case

The best case is that it just works. But that depends on the platform and operation.

[dtolnay]

I filed #110708 with takeaways from the feedback above, and I'll close this PR since I agree this is not appropriate to document like this.