Guard against calling `libc::exit` multiple times on Linux.
Mitigates (but does not fix) #126600 by ensuring only one thread which calls Rust `exit` actually calls `libc::exit`, and all other callers of Rust `exit` block.
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.
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: #82971
clarify `sys::unix::fd::FileDesc::drop` comment
closes#66876
simply clarifies some resource-relevant things regarding the `close` syscall to reduce the amount of search needed in other parts of the web.
once_lock: make test not take as long in Miri
Allocating 1000 list elements takes a while (`@zachs18` reported >5min), so let's reduce the iteration count when running in Miri. Unfortunately due to this clever `while let i @ 0..LEN =` thing, the count needs to be a constants, and constants cannot be shadowed, so we need to use another trick to hide the `cfg!(miri)` from the docs. (I think this loop condition may be a bit too clever, it took me a bit to decipher. Ideally this would be `while let i = ... && i < LEN`, but that is not stable yet.)
Improve std::Path's Hash quality by avoiding prefix collisions
This adds a bit rotation to the already existing state so that the same sequence of characters chunked at different offsets into separate path components results in different hashes.
The tests are from #127255Closes#127254
Update windows-bindgen to 0.58.0
This also switches from the bespoke `std` generated bindings to the normal `sys` ones everyone else uses.
This has almost no difference except that the `sys` bindings use the `windows_targets::links!` macro for FFI imports, which we implement manually. This does cause the diff to look much larger than it really is but the bulk of the changes are mostly contained to the generated code.
Remove unqualified form import of io::Error in process_vxworks.rs and fallback on remove_dir_impl for vxworks
Hi all,
This is to address issue #127084. On inspections it was found that io::Error refrences were all of qualified form and there was no need to add a unqualified form import. Also to successfully build rust for vxworks, we need to fallback on the remove_impl_dir implementations.
Thank you.
Stabilize `PanicInfo::message()` and `PanicMessage`
Resolves#66745
This stabilizes the [`PanicInfo::message()`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.message) and [`PanicMessage`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicMessage.html).
Demonstration of [custom panic handler](https://github.com/StackOverflowExcept1on/panicker):
```rust
#![no_std]
#![no_main]
extern crate libc;
#[no_mangle]
extern "C" fn main() -> libc::c_int {
panic!("I just panic every time");
}
#[panic_handler]
fn my_panic(panic_info: &core::panic::PanicInfo) -> ! {
use arrayvec::ArrayString;
use core::fmt::Write;
let message = panic_info.message();
let location = panic_info.location().unwrap();
let mut debug_msg = ArrayString::<1024>::new();
let _ = write!(&mut debug_msg, "panicked with '{message}' at '{location}'");
if debug_msg.try_push_str("\0").is_ok() {
unsafe {
libc::puts(debug_msg.as_ptr() as *const _);
}
}
unsafe { libc::exit(libc::EXIT_FAILURE) }
}
```
```
$ cargo +stage1 run --release
panicked with 'I just panic every time' at 'src/main.rs:8:5'
```
- [x] FCP: https://github.com/rust-lang/rust/issues/66745#issuecomment-2198143725
r? libs-api
std: separate TLS key creation from TLS access
Currently, `std` performs an atomic load to get the OS key on every access to `StaticKey` even when the key is already known. This PR thus replaces `StaticKey` with the platform-specific `get` and `set` function and a new `LazyKey` type that acts as a `LazyLock<Key>`, allowing the reuse of the retreived key for multiple accesses.
Related to #110897.
