Merge Apple `std::os` extensions modules into `std::os::darwin`
The functionality available on Apple platforms are very similar, and were (basically) duplicated for each platform.
This PR rectifies that by merging the code into one module.
Ultimately, I've done this to fix `./x build library --target=aarch64-apple-tvos,aarch64-apple-watchos,aarch64-apple-visionos`, as that currently fails because of dead code warnings.
Publically exposing these to tvOS/watchOS/visionOS targets is considered in https://github.com/rust-lang/rust/pull/123723, but that seems to be dragging out, and in any case I think it makes sense to do the refactor separately from stabilization.
r? libs
Fixes https://github.com/rust-lang/rust/issues/121640 and https://github.com/rust-lang/rust/issues/124825.
The functionality available on Apple platforms are very similar, and
were duplicated for each platform.
Additionally, this fixes a warning when compiling the standard library
for tvOS, watchOS and visionOS by marking the corresponding code as
dead code.
Use ManuallyDrop in BufWriter::into_parts
The fact that `mem::forget` takes by value means that it interacts very poorly with Stacked Borrows; generally users think of calling it as a no-op, but in Stacked Borrows, the field retagging tends to cause surprise tag invalidation.
Remove memory leaks in doctests in `core`, `alloc`, and `std`
cc `@RalfJung` https://github.com/rust-lang/rust/issues/126067https://github.com/rust-lang/miri/issues/3670
Should be no actual *documentation* changes[^1], all added/modified lines in the doctests are hidden with `#`,
This PR splits the existing memory leaks in doctests in `core`, `alloc`, and `std` into two general categories:
1. "Non-focused" memory leaks that are incidental to the thing being documented, and/or are easy to remove, i.e. they are only there because preventing the leak would make the doctest less clear and/or concise.
- These doctests simply have a comment like `# // Prevent leaks for Miri.` above the added line that removes the memory leak.
- [^2]Some of these would perhaps be better as part of the public documentation part of the doctest, to clarify that a memory leak can happen if it is not otherwise mentioned explicitly in the documentation (specifically the ones in `(A)Rc::increment_strong_count(_in)`).
2. "Focused" memory leaks that are intentional and documented, and/or are possibly fragile to remove.
- These doctests have a `# // FIXME` comment above the line that removes the memory leak, with a note that once `-Zmiri-disable-leak-check` can be applied at test granularity, these tests should be "un-unleakified" and have `-Zmiri-disable-leak-check` enabled.
- Some of these are possibly fragile (e.g. unleaking the result of `Vec::leak`) and thus should definitely not be made part of the documentation.
This should be all of the leaks currently in `core` and `alloc`. I only found one leak in `std`, and it was in the first category (excluding the modules `@RalfJung` mentioned in https://github.com/rust-lang/rust/issues/126067 , and reducing the number of iterations of [one test](https://github.com/rust-lang/rust/blob/master/library/std/src/sync/once_lock.rs#L49-L94) from 1000 to 10)
[^1]: assuming [^2] is not added
[^2]: backlink
Windows: Add experimental support for linking std-required system DLLs using raw-dylib
For Windows, this allows std to define system imports without needing the user to have import libraries. It's intended for this to become the default.
For now it's an experimental feature so it can be tested using build-std.
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.
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
std: Set `has_reliable_f16` to false for MIPS targets in build.rs
This PR makes std tests link for MIPS again (they broke with https://github.com/rust-lang/rust/pull/126608) by avoiding the following link errors. Step-by-step instructions on how to reproduce these errors in docker can be found below.
std.9e27ea-cgu.12:(.text._ZN3std3num8test_num17edc3E+0x38): undefined reference to `__gnu_f2h_ieee'
std.9e27ea-cgu.12:(.text._ZN3std3num8test_num17hdc3E+0x38): undefined reference to `__gnu_h2f_ieee'
This PR just adds one line of config in existing f16 infrastructure. It also disables four doctests that fails with the same link errors.
## Step-by-step to reproduce linking error
1. Prepare:
```sh
docker run -it ubuntu:24.10
apt update && apt install -y \
libc6-mips-cross \
libc6-mipsel-cross \
libc6-mips64-cross \
libc6-mips64el-cross \
gcc-mips-linux-gnu \
gcc-mipsel-linux-gnu \
gcc-mips64-linux-gnuabi64 \
gcc-mips64el-linux-gnuabi64 \
git curl python3 build-essential
git clone --depth 1 https://github.com/rust-lang/rust.git
cd rust
```
2. Try to link std tests for any of these 4 MIPS targets by running any one of these commands:
```sh
CC_mips_unknown_linux_gnu=mips-linux-gnu-gcc \
CARGO_TARGET_MIPS_UNKNOWN_LINUX_GNU_LINKER=mips-linux-gnu-gcc \
./x test library/std --target mips-unknown-linux-gnu
CC_mipsel_unknown_linux_gnu=mipsel-linux-gnu-gcc \
CARGO_TARGET_MIPSEL_UNKNOWN_LINUX_GNU_LINKER=mipsel-linux-gnu-gcc \
./x test library/std --target mipsel-unknown-linux-gnu
CC_mips64_unknown_linux_gnuabi64=mips64-linux-gnuabi64-gcc \
CARGO_TARGET_MIPS64_UNKNOWN_LINUX_GNUABI64_LINKER=mips64-linux-gnuabi64-gcc \
./x test library/std --target mips64-unknown-linux-gnuabi64
CC_mips64el_unknown_linux_gnuabi64=mips64el-linux-gnuabi64-gcc \
CARGO_TARGET_MIPS64EL_UNKNOWN_LINUX_GNUABI64_LINKER=mips64el-linux-gnuabi64-gcc \
./x test library/std --target mips64el-unknown-linux-gnuabi64
```
### Expected
No link error. After this PR there are no link errors.
### Actual
```
error: linking with `mips-linux-gnu-gcc` failed: exit status: 1
|
= note: LC_ALL="C" PATH="/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "mips-linux-gnu-gcc" "/tmp/rustcEtKsay/symbols.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.00.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.01.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.02.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.03.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.04.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.05.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.06.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.07.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.08.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.09.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.10.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.11.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.12.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.13.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.14.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.15.rcgu.o" "-Wl,--as-needed" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/release/deps" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand_xorshift-deb32232a867c543.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand-5a391600dce9d98f.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand_core-a11cfba3d86c5298.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libtest-65b05caf5a9b99a4.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libgetopts-ba692b2f798aef60.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libunicode_width-20ec8b475126cb0b.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/librustc_std_workspace_std-c17f739fee51cc86.rlib" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-Wl,-Bdynamic" "-lstd-124ee57a4c00deda" "-Wl,-Bstatic" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/libcompiler_builtins-bd55a137b89bc81f.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs" "-Wl,-z,origin" "-Wl,-rpath,$ORIGIN/../lib"
= note: /usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: /rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.12.rcgu.o: in function `std::num::test_num':
std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x38): undefined reference to `__gnu_f2h_ieee'
/usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x3c): undefined reference to `__gnu_f2h_ieee'
/usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x44): undefined reference to `__gnu_h2f_ieee'
...
collect2: error: ld returned 1 exit status
error: could not compile `std` (lib test) due to 1 previous error
```
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.
To avoid this linker error:
$ sudo apt install libc6-mips-cross gcc-mips-linux-gnu
$ CC_mips_unknown_linux_gnu=mips-linux-gnu-gcc \
CARGO_TARGET_MIPS_UNKNOWN_LINUX_GNU_LINKER=mips-linux-gnu-gcc \
./x test library/std --target mips-unknown-linux-gnu
undefined reference to `__gnu_f2h_ieee'
You get the same linker error also with mipsel, mips64 and
mips64el toolchains.
The target_arch of `powerpc64le` is `powerpc64`, so
`powerpc64le` can be removed from a match arm in build.rs
related to f16.
You can check available `target_arch`:s with:
$ rustc +nightly -Zunstable-options --print all-target-specs-json \
| grep powerpc | grep arch | sort | uniq
"arch": "powerpc",
"arch": "powerpc64",
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
Cleanup bootstrap check-cfg
This PR cleanup many custom `check-cfg` in bootstrap that have been accumulated over the years.
As well as updating some outdated comments.
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.
Add more constants, functions, and tests for `f16` and `f128`
This adds everything that was in some way blocked on const eval, since https://github.com/rust-lang/rust/pull/126429 landed. There is a lot of `cfg(bootstrap)` since that is a fairly recent change.
`f128` tests are disabled on everything except x86_64 and Linux aarch64, which are two platforms I know have "good" support for these types - meaning basic math symbols are available and LLVM doesn't hit selection crashes. `f16` tests are enabled on almost everything except for known LLVM crashes. Doctests are only enabled on x86_64.
Tracking issue: https://github.com/rust-lang/rust/issues/116909
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.
This suite tests all library functions that are now available for the
types. Tests are only run on certain platforms where `f16` and `f128`
are known to work (have symbols available and don't crash LLVM).
This adds everything that was directly or transitively blocked on const
arithmetic for these types, which was recently merged.
Since const arithmetic is recent, most of these need to be gated by
`bootstrap`.
Anything that relies on intrinsics that are still missing is excluded.
There are some complexities about what platforms we can test f16 and
f128 on. Put this in build.rs so we have an easy way to configure tests
with a single attribute, and keep it up to date.
Remove `MaybeUninit::uninit_array()` and replace it with inline const blocks.
\[This PR originally contained the changes in #125995 too. See edit history for the original PR description.]
The documentation of `MaybeUninit::uninit_array()` says:
> Note: in a future Rust version this method may become unnecessary when Rust allows [inline const expressions](https://github.com/rust-lang/rust/issues/76001). The example below could then use `let mut buf = [const { MaybeUninit::<u8>::uninit() }; 32];`.
The PR adding it also said: <https://github.com/rust-lang/rust/pull/65580#issuecomment-544200681>
> if it’s stabilized soon enough maybe it’s not worth having a standard library method that will be replaceable with `let buffer = [MaybeUninit::<T>::uninit(); $N];`
That time has come to pass — inline const expressions are stable — so `MaybeUninit::uninit_array()` is now unnecessary. The only remaining question is whether it is an important enough *convenience* to keep it around.
I believe it is net good to remove this function, on the principle that it is better to compose two orthogonal features (`MaybeUninit` and array construction) than to have a specific function for the specific combination, now that that is possible.
This is possible now that inline const blocks are stable; the idea was
even mentioned as an alternative when `uninit_array()` was added:
<https://github.com/rust-lang/rust/pull/65580#issuecomment-544200681>
> if it’s stabilized soon enough maybe it’s not worth having a
> standard library method that will be replaceable with
> `let buffer = [MaybeUninit::<T>::uninit(); $N];`
Const array repetition and inline const blocks are now stable (in the
next release), so that circumstance has come to pass, and we no longer
have reason to want `uninit_array()` other than convenience. Therefore,
let’s evaluate the inconvenience by not using `uninit_array()` in
the standard library, before potentially deleting it entirely.
std: refactor the TLS implementation
As discovered by Mara in #110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with #117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.
Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that
Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.
`@rustbot` label +A-thread-locals
std::unix::fs: copy simplification for apple.
since we do support from macOs Sierra, we avoid the little runtime overhead with the fclonefileat symbol check.
Remove use of const traits (and `feature(effects)`) from stdlib
The current uses are already unsound because they are using non-const impls in const contexts. We can reintroduce them by reverting the commit in this PR, after #120639 lands.
Also, make `effects` an incomplete feature.
cc `@rust-lang/project-const-traits`
r? `@compiler-errors`
Add PidFd::{kill, wait, try_wait}
#117957 changed `Child` kill/wait/try_wait to use its pidfd instead of the pid, when one is available.
This PR extracts those implementations and makes them available on `PidFd` directly.
The `PidFd` implementations differ significantly from the corresponding `Child` methods:
* the methods can be called after the child has been reaped, which will result in an error but will be safe. This state is not observable in `Child` unless something stole the zombie child
* the `ExitStatus` is not kept, meaning that only the first time a wait succeeds it will be returned
* `wait` does not close stdin
* `wait` only requires `&self` instead of `&mut self` since there is no state to maintain and subsequent calls are safe
Tracking issue: #82971
As long as a pidfd is on a child it can be safely reaped. Taking it
would mean the child would now have to be awaited through its pid, but could also
be awaited through the pidfd. This could then suffer from a recycling race.
Most modules have such a blank line, but some don't. Inserting the blank
line makes it clearer that the `//!` comments are describing the entire
module, rather than the `use` declaration(s) that immediately follows.
This makes their intent and expected location clearer. We see some
examples where these comments were not clearly separate from `use`
declarations, which made it hard to understand what the comment is
describing.
export std::os::fd module on HermitOS
The HermitOS' IO interface is similiar to Unix. Consequently, this PR synchronize the FD implementation between both.
closes#126198
Document behavior of `create_dir_all` wrt. empty path
The behavior makes sense because `Path::new("one_component").parent() == Some(Path::new(""))`, so if one naively wants to create the parent directory for a file to be written, it simply works.
Closes#105108 by documenting the current behavior.
Bump windows-bindgen to 0.57
This PR updates our generated Windows API bindings using the latest version of `windows-bindgen`.
The only change to the generated code is that `derive` is used for `Copy` and `Clone` instead of `impl`.
As discovered by Mara in #110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with #117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.
Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that
Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.
@rustbot label +A-thread-locals
Rollup of 9 pull requests
Successful merges:
- #125829 (rustc_span: Add conveniences for working with span formats)
- #126361 (Unify intrinsics body handling in StableMIR)
- #126417 (Add `f16` and `f128` inline ASM support for `x86` and `x86-64`)
- #126424 ( Also sort `crt-static` in `--print target-features` output)
- #126428 (Polish `std::path::absolute` documentation.)
- #126429 (Add `f16` and `f128` const eval for binary and unary operationations)
- #126448 (End support for Python 3.8 in tidy)
- #126488 (Use `std::path::absolute` in bootstrap)
- #126511 (.mailmap: Associate both my work and my private email with me)
r? `@ghost`
`@rustbot` modify labels: rollup
These changes bring it closer to other standard library documentation
and, in particular, `std::fs::canonicalize`, which it will often be
compared with.
* Add `# Platform-specific behavior` section, with content moved from
Examples section.
* Create `# Errors` section.
* Phrase error description to allow future platforms to have new
syntactic errors, rather than only emptiness.
* Add missing commas.
* Indent example code 4 spaces.
Rollup of 7 pull requests
Successful merges:
- #123769 (Improve escaping of byte, byte str, and c str proc-macro literals)
- #126054 (`E0229`: Suggest Moving Type Constraints to Type Parameter Declaration)
- #126135 (add HermitOS support for vectored read/write operations)
- #126266 (Unify guarantees about the default allocator)
- #126285 (`UniqueRc`: support allocators and `T: ?Sized`.)
- #126399 (extend the check for LLVM build)
- #126426 (const validation: fix ICE on dangling ZST reference)
r? `@ghost`
`@rustbot` modify labels: rollup
Unify guarantees about the default allocator
`std::alloc` said that the default allocator is unspecified for all crrate types except `cdylib` and `staticlib`. Adjust `std::alloc::System` documentation to say the same.
Fixes#125870.
add HermitOS support for vectored read/write operations
In general, the I/O interface of hermit-abi is revised and now a more POSIX-like interface. Consequently, platform abstraction layer for HermitOS has slightly adjusted and some inaccuracies remove.
Hermit is a tier 3 platform and this PR changes only files, wich are related to the tier 3 platform.
std::unix::fs::link using direct linkat call for Solaris.
Since we support solaris 11 as minimum, we can get rid of the runtime overhead.
try-job: dist-various-2
Clarify `Command::new` behavior for programs with arguments
I mistakenly passed program path along arguments as the same string into `Command::new` a couple of times now. It might be useful to explicitly highlight that `Command::new` intends to accept path to a program, not path to a program plus arguments. Also nudge the user to use `Command::arg` or `Command::args` if they wish to pass arguments.
Rollup of 16 pull requests
Successful merges:
- #123374 (DOC: Add FFI example for slice::from_raw_parts())
- #124514 (Recommend to never display zero disambiguators when demangling v0 symbols)
- #125978 (Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking)
- #125980 (Nvptx remove direct passmode)
- #126187 (For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.)
- #126210 (docs(core): make more const_ptr doctests assert instead of printing)
- #126249 (Simplify `[T; N]::try_map` signature)
- #126256 (Add {{target}} substitution to compiletest)
- #126263 (Make issue-122805.rs big endian compatible)
- #126281 (set_env: State the conclusion upfront)
- #126286 (Make `storage-live.rs` robust against rustc internal changes.)
- #126287 (Update a cranelift patch file for formatting changes.)
- #126301 (Use `tidy` to sort crate attributes for all compiler crates.)
- #126305 (Make PathBuf less Ok with adding UTF-16 then `into_string`)
- #126310 (Migrate run make prefer rlib)
- #126314 (fix RELEASES: we do not support upcasting to auto traits)
r? `@ghost`
`@rustbot` modify labels: rollup
Make PathBuf less Ok with adding UTF-16 then `into_string`
Fixes#126291 which is, as far as I can tell, a regression introduced by #96869.
try-job: x86_64-msvc
Update a cranelift patch file for formatting changes.
PR #125443 will reformat all the use declarations in the repo. This would break a patch kept in `rustc_codegen_cranelift` that gets applied to `library/std/src/sys/pal/windows/rand.rs`.
So this commit formats the use declarations in `library/std/src/sys/pal/windows/rand.rs` in advance of #125443 and updates the patch file accordingly.
The motivation is that #125443 is a huge change and we want to get fiddly little changes like this out of the way so it can be nothing more than an `x fmt --all`.
r? ``@bjorn3``
set_env: State the conclusion upfront
People tend to skim or skip over long explanations so we should be very upfront that `set_var` and `remove_var` are being made unsafe for a very good reason.
This is just the conclusion restated almost verbatim but earlier in the docs and separated from the explanation:
0c960618b5/library/std/src/env.rs (L338-L339)
I think this may help with people who may not be entirely comfortable with #125937 being rejected.
PR #125443 will reformat all the use declarations in the repo. This
would break a patch kept in `rustc_codegen_cranelift` that gets applied
to `library/std/src/sys/pal/windows/rand.rs`.
So this commit formats the use declarations in
`library/std/src/sys/pal/windows/rand.rs` in advance of #125443 and
updates the patch file accordingly.
The motivation is that #125443 is a huge change and we want to get
fiddly little changes like this out of the way so it can be nothing more
than an `x fmt --all`.
`std::alloc` said that the default allocator is unspecified for all
crrate types except `cdylib` and `staticlib`. Adjust
`std::alloc::System` documentation to say the same.
Fixes#125870.
std::unix::os current_exe implementation simplification for haiku.
_get_net_image_info is a bit overkill as it allows to get broader informations about the process.
std::unix::fs::get_mode implementation for illumos/solaris.
they both support the F_GETFL fctnl flag/O_ACCMODE mask to get the file descriptor access modes.
In general, the I/O interface of hermit-abi is more POSIX-like
interface. Consequently, platform abstraction layer for HermitOS
has slightly adjusted and some inaccuracies remove.
