Using a pure spin lock for a critical section in a preemptable thread
is always wrong, however short the critical section may be. The thread
might be preempted, which will cause all other threads to hammer
busily at the core for the whole quant. Moreover, if threads have
different priorities, this might lead to a priority inversion problem
and a deadlock. More generally, a spinlock is not more efficient than
a well-written mutex, which typically does several spin iterations at
the start anyway.

The advise about UP vs SMP is also irrelevant in the context of
preemptive threads.

I believe rustdoc should not be conflating private items (visibility
lower than `pub`) and hidden items (attribute `doc(hidden)`). This
matters now that Cargo is passing --document-private-items by default
for bin crates. In bin crates that rely on macros, intentionally hidden
implementation details of the macros can overwhelm the actual useful
internal API that one would want to document.

This PR restores the strip-hidden pass when documenting private items,
and introduces a separate unstable --document-hidden-items option to
skip the strip-hidden pass. The two options are orthogonal to one
another.

Also includes a simple test with a custom panic hook to ensure we don't regress.

Co-Authored-By: lzutao <taolzu@gmail.com>

These notes are about a distinction that is not going to be observable
in the API. Whether or not the UTF-8 check knows the string length ahead
of time, these methods require linear time.

The only two uses of the associated methods are in librustc_mir and
librustdoc. Please tell me if there is a better choice.

Try statx for all linux-gnu target.

After rust-lang/libc#1577, which is contained in `libc` 0.2.66,  provides `SYS_statx` for all Linux platform, so we can try to use `statx` for ~all Linux target~ all linux-gnu targets.

Unfortunately, `struct statx` and `fn statx` is not a part of public interface of musl (currently), ~we still need to invoke it through `syscall`~ we does **not** support statx for musl or other libc impls currently.

Previous PR: rust-lang#65094

cc @alexcrichton

Move `is_min_const_fn` query to librustc_mir.

The only two uses of the associated methods are in `librustc_mir` and
`librustdoc`. Please tell me if there is a better choice.

cc rust-lang#65031

Remove wrong advice about spin locks from `spin_loop_hint` docs

Using a pure spin lock for a critical section in a preemptable thread
is always wrong, however short the critical section may be. The thread
might be preempted, which will cause all other threads to hammer
busily at the core for the whole quant. Moreover, if threads have
different priorities, this might lead to a priority inversion problem
and a deadlock. More generally, a spinlock is not more efficient than
a well-written mutex, which typically does several spin iterations at
the start anyway.

The advise about UP vs SMP is also irrelevant in the context of
preemptive threads.

See also accompanying piece: https://matklad.github.io/2020/01/02/spinlocs-considered-harmful.html

And another, independent piece: https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is

EDIT: obligatory disclosure that I am not an expert in these things, and might be terribly wrong :)

Add a check for swapped words when we can't find an identifier

Fixes rust-lang#66968

Couple things here:
1. The matches take the precedence of case insensitive match, then levenshtein match, then swapped words match. Doing this allows us to not even check for swapped words unless the other checks return `None`.
2. I've assumed that the swapped words check is not held to the limits of the max levenshtein distance threshold (ie. we want to try and find a match even if the levenshtein distance is very high). This means that we cannot perform this check in the `fold` that occurs after the `filter_map` call, because the candidate will be filtered out. So, I've split this into two separate `fold` calls, and had to collect the original iterator into a vec so it can be copied (I don't think we want to change the function signature to take a vec or require the `Copy` trait). An alternative implemenation may be to remove the `filter_map`, `fold` over the entire iterator, and do a check against `max_dist` inside the relevant cases there.

r? @estebank

Distinguish between private items and hidden items in rustdoc

I believe rustdoc should not be conflating private items (visibility lower than `pub`) and hidden items (attribute `doc(hidden)`). This matters now that Cargo is passing --document-private-items by default for bin crates. In bin crates that rely on macros, intentionally hidden implementation details of the macros can overwhelm the actual useful internal API that one would want to document.

This PR restores the strip-hidden pass when documenting private items, and introduces a separate unstable --document-hidden-items option to skip the strip-hidden pass. The two options are orthogonal to one another.

Fixes rust-lang#67851. Closes rust-lang#60884.

`Option::{expect,unwrap}` and `Result::{expect, expect_err, unwrap, unwrap_err}` have `#[track_caller]`

The annotated functions now produce panic messages pointing to the location where they were called, rather than `core`'s internals.

…umeGomez

rustdoc: Remove more `#[doc(cfg(..))]` duplicates

This is a follow up to rust-lang#66959.

r? @GuillaumeGomez

Updates for VxWorks

r? @alexcrichton

Remove insignificant notes from CStr documentation

The to_str and to_string_lossy methods contain a note about the behavior possibly changing in the future. But those notes are referring to a distinction that is not observable in the API. Whether or not the UTF-8 check knows the string length ahead of time, these methods require linear time.

…fix, r=Mark-Simulacrum

ci: fix wrong shared.sh import for publish_toolstate

r? @Mark-Simulacrum