Document const-initialization for thread_local! macro

[AnthonyMikh]

#83416 added const initialization for statics in std::thread::thread_local macro. Surprisingly, it was merged completely undocumented, so I suspect most of Rust users are not even aware of this functionality. This PR intents to close this gap.

@rustbot labels: +A-docs

[rustbot]

r? @joshtriplett

(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

[ChrisDenton]

Documenting this looks great to me. I do however have a concern about going into the details of const contexts.

It talks a bit about what can and can't be done in const contexts, which is more or less true enough today but might not be tomorrow. E.g. "doing so does not change the behavior" and the failing example using vec![0]. IIRC, these are both actually open questions. Can a function act differently in const contexts (e.g. float operations)? Will we be able to have (limited) use of Vec in const?

Documenting the current const details may be useful but I'm not sure that this is the place to do it.

[AnthonyMikh]

@ChrisDenton I understand your concerns, but I think that without such a counterexample the documentation would be incomplete. Besides, it is a compile_fail test, so if in any future version of Rust this test will fail to fail to compile, this will cause std doc-tests to fail and thus prevent the respective PR from landing without fixing these tests.

[ChrisDenton]

Fair enough. Then I would narrow my concerns to the following suggestion:

Suggested change

	/// Doing so does not change the behavior, but might enable more efficient implementation
	/// of [`LocalKey`][`std::thread::LocalKey`] on supported platforms.
	/// Doing so might enable more efficient implementation
	/// of [`LocalKey`][`std::thread::LocalKey`] on supported platforms.

[AnthonyMikh]

Superseded by now merged #110620