…or to allow unsized T.

we now distinguish between pidfd_spawn support, pidfd-via-fork/exec and not-supported

previously, we only held a lock for printing the backtrace itself. since all threads were printing to the same file descriptor, that meant random output in the default panic hook would be interleaved with the backtrace. now, we hold the lock for the full duration of the hook, and the output is ordered.

binutils 2.40 is required by LLVM 19, as older versions do not
know about the zmmull extension.

I've had to backport some patches to glibc and gcc as well,
as they don't build with binutils 2.40. Alternatively, we could
also switch to glibc 2.35 and gcc 12 (I think). I figured we'd
want to avoid the glibc version change, but if that's fine for
riscv I can go with that instead.

A `rustc_const_stable` attribute by itself has nonintuitive purpose when
placed in a public module.

Separately, it would probably be okay to rename `const_strlen` to just
`strlen` to make it more clear this is our general-purpose
implementation of strlen now, not something specifically for const
(avoiding confusion like in PR 127444).

Generalize `fn allocator` for Rc/Arc.

Split out from rust-lang#119761

- For `Rc`/`Arc`, the existing associated `fn`s are changed to allow unsized pointees.
 - For `Weak`s, new methods are added.

`@rustbot` label +A-allocators

Add AMX target-features and `x86_amx_intrinsics` feature flag

This is an effort towards rust-lang#126622. This adds support for all 5 target-features for `AMX`, and introduces the feature flag `x86_amx_intrinsics`, which would gate these target-features and the yet-to-be-implemented amx intrinsics in stdarch.

Use pidfd_spawn for faster process spawning when a PidFd is requested

glibc 2.39 added `pidfd_spawnp` and `pidfd_getpid` which makes it possible to get pidfds while staying on the CLONE_VFORK path.

verified that vfork gets used with strace:

```
$  strace -ff -e pidfd_open,clone3,openat,execve,waitid,close ./x test std --no-doc -- pidfd
[...]
[pid 2820532] clone3({flags=CLONE_VM|CLONE_PIDFD|CLONE_VFORK|CLONE_CLEAR_SIGHAND, pidfd=0x7b7f885fec6c, exit_signal=SIGCHLD, stack=0x7b7f88aff000, stack_size=0x9000}strace: Process 2820533 attached
 <unfinished ...>
[pid 2820533] execve("/home/the8472/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */) = -1 ENOENT (No such file or directory)
[pid 2820533] execve("/home/the8472/.cargo/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */) = -1 ENOENT (No such file or directory)
[pid 2820533] execve("/usr/local/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */) = -1 ENOENT (No such file or directory)
[pid 2820533] execve("/usr/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */ <unfinished ...>
[pid 2820532] <... clone3 resumed> => {pidfd=[3]}, 88) = 2820533
[pid 2820533] <... execve resumed>)     = 0
[pid 2820532] openat(AT_FDCWD, "/proc/self/fdinfo/3", O_RDONLY|O_CLOEXEC) = 4
[pid 2820532] close(4)                  = 0
```

Tracking issue: rust-lang#82971

…workingjubilee

fix interleaved output in the default panic hook when multiple threads panic simultaneously

previously, we only held a lock for printing the backtrace itself. since all threads were printing to the same file descriptor, that meant random output in the default panic hook from one thread would be interleaved with the backtrace from another. now, we hold the lock for the full duration of the hook, and the output is ordered.

---

i noticed some odd things while working on this you may or may not already be aware of.

- libbacktrace is included as a submodule instead of a normal rustc crate, and as a result uses `cfg(backtrace_in_std)` instead of a more normal `cfg(feature = "rustc-dep-of-std")`. probably this is left over from before rust used a cargo-based build system?
- the default panic handler uses `trace_unsynchronized`, etc, in `sys::backtrace::print`. as a result, the lock only applies to concurrent *panic handlers*, not concurrent *threads*.  in other words, if another, non-panicking, thread tried to print a backtrace at the same time as the panic handler, we may have UB, especially on windows.
    - we have the option of changing backtrace to enable locking when `backtrace_in_std` is set so we can reuse their lock instead of trying to add our own.

Stabilize const_cstr_from_ptr (CStr::from_ptr, CStr::count_bytes)

Completed the pair of FCPs rust-lang#113219 (comment) + rust-lang#114441 (comment).

`CStr::from_ptr` is covered by just the first FCP on its own. `CStr::count_bytes` requires the approval of both FCPs. The second paragraph of the first link and the last paragraph of the second link explain the relationship between the two FCPs. As both have been approved, we can proceed with stabilizing `const` on both of these already-stable functions.

Update dist-riscv64-linux to binutils 2.40

binutils 2.40 is required by LLVM 19, as older versions do not know about the zmmul extension.

I've had to backport some patches to glibc and gcc as well, as they don't build with binutils 2.40. Alternatively, we could also switch to glibc 2.35 and gcc 10 (I think). I figured we'd want to avoid the glibc version change, but if that's fine for riscv I can go with that instead.

r? `@cuviper`

try-job: dist-riscv64-linux

…rustdoc, r=fmease

Implement `precise_capturing` support for rustdoc

Implements rustdoc (+json) support for local (i.e. non-cross-crate-inlined) RPITs with `use<...>` precise capturing syntax.

Tests kinda suck. They're really hard to write 😰

r? `@fmease` or re-roll if you're too busy!
also cc `@aDotInTheVoid` for the json side

Tracking:
* rust-lang#127228 (comment) (not fully fixed for cross-crate-inlined opaques)
* rust-lang#123432