Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#147585 (Suppress the error for private fields with non_exhaustive attribute)
- rust-lang/rust#149215 (Emit `check-cfg` lints during attribute parsing rather than evaluation)
- rust-lang/rust#149652 (Add release notes for 1.92.0)
- rust-lang/rust#149720 (rustdoc book: mention inner doc attribute)
- rust-lang/rust#149730 (lint: emit proper diagnostic for unsafe binders in improper_ctypes instead of ICE)
- rust-lang/rust#149754 (Retire `opt_str2` from compiletest cli parsing)
- rust-lang/rust#149755 (bootstrap: Use a `CompiletestMode` enum instead of bare strings)
- rust-lang/rust#149763 (Add inline attribute to generated delegation function if needed)
- rust-lang/rust#149772 (test: Add a test for 146133)
- rust-lang/rust#149779 (Fix typo "an" → "and")
- rust-lang/rust#149782 (Remove `[no-mentions]` handler in the triagebot config)
Failed merges:
- rust-lang/rust#148491 ( Correctly provide suggestions when encountering `async fn` with a `dyn Trait` return type)
r? `@ghost`
`@rustbot` modify labels: rollup
This commit is a large change to the implementation of filesystem and
other system-related operations on WASI targets. Previously the standard
library explicitly used the `wasi` crate at the 0.11.x version track
which means that it used WASIp1 APIs directly. This meant that `std` was
hard-coded to use WASIp1 syscalls and there was no separate
implementation for the WASIp{2,3} targets, for example. The high-level
goal of this commit is to decouple this interaction and avoid the use of
the `wasi` crate on the WASIp2 target.
Historically when WASIp1 was originally added to Rust the wasi-libc
library was in a much different position than it is today. Nowadays Rust
already depends on wasi-libc on WASI targets for things like memory
allocation and environment variable management. As a libc library it
also has all the functions necessary to implement all filesystem
operations Rust wants. Recently wasi-libc additionally was updated to
use WASIp2 APIs directly on the `wasm32-wasip2` target instead of using
`wasm32-wasip1` APIs. This commit is leveraging this work by enabling
Rust to completely sever the dependence on WASIp1 APIs when compiling
for `wasm32-wasip2`. This is also intended to make it easier to migrate
to `wasm32-wasip3` internally in the future where now only libc need be
updated and Rust doesn't need to explicitly change as well.
The overall premise of this commit is that there's no need for
WASI-specific implementation modules throughout the standard library.
Instead the libc-style bindings already implemented for Unix-like
targets are sufficient. This means that Rust will now be using
libc-style interfaces to interact with the filesystem, for example, and
wasi-libc is the one responsible for translating these POSIX-ish
functions into WASIp{1,2} calls.
Concrete changes here are:
* `std` for `wasm32-wasip2` no longer depends on `wasi 0.11.x`
* The implementation of `std::os::wasi::fs`, which was previously
unstable and still is, now has portions gated to only work on the
WASIp1 target which use the `wasi` crate directly. Traits have been
trimmed down in some cases, updated in others, or now present a
different API on WASIp1 and WASIp2. It's expected this'll get further
cleanup in the future.
* The `std::sys::fd::wasi` module is deleted and `unix` is used instead.
* The `std::sys::fs::wasi` module is deleted and `unix` is used instead.
* The `std::sys::io::io_slice::wasi` module is deleted and `unix` is used
instead.
* The `std::sys::pal::{wasip1,wasip2}` modules are now merged together
as their difference is much smaller than before.
* The `std::sys::pal::wasi::time` is deleted and the `unix` variant is
used directly instead.
* The `std::sys::stdio::wasip{1,2}` modules are deleted and the `unix`
variant is used instead.
* The `std::sys::thread::wasip{1,2}` modules are deleted and the `unix`
variant is used instead.
Overall Rust's libstd is effectively more tightly bound to libc when
compiled to WASI targets. This is intended to mirror how it's expected
all other languages will also bind to WASI. This additionally has the
nice goal of drastically reducing the WASI-specific maintenance burden
in libstd (in theory) and the only real changes required here are extra
definitions being added to `libc` (done in separate PRs). This might be
required for more symbols in the future but for now everything should be
mostly complete.
`c_variadic`: make `VaList` abi-compatible with C
tracking issue: https://github.com/rust-lang/rust/issues/44930
related PR: rust-lang/rust#144529
On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly.
In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy,
In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang/rust#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct.
Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (https://github.com/rust-lang/rust/issues/141524#issuecomment-3028383594), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms).
Previous discussion: rust-lang/rust#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI)
Tracking issue: https://github.com/rust-lang/rust/issues/44930
r? `@joshtriplett`
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#147224 (Emscripten: Turn wasm-eh on by default)
- rust-lang/rust#149405 (Recover on misspelled item keyword)
- rust-lang/rust#149443 (Tidying up UI tests [6/N])
- rust-lang/rust#149524 (Move attribute safety checking to attribute parsing)
- rust-lang/rust#149593 (powf, powi: point out SNaN non-determinism)
- rust-lang/rust#149605 (Use branch name instead of HEAD when unshallowing)
- rust-lang/rust#149612 (Apply the `bors` environment also to the `outcome` job)
- rust-lang/rust#149623 (Don't require a normal tool build of clippy/rustfmt when running their test steps)
- rust-lang/rust#149627 (Point to the item that is incorrectly annotated with `#[diagnostic::on_const]`)
r? `@ghost`
`@rustbot` modify labels: rollup
powf, powi: point out SNaN non-determinism
The non-determinism has two sources:
- LLVM reserves the right to treat signaling NaNs as-if they were quiet, so it may fold `powf(x, 0)` to `1` even if `x` might be a signaling NaN.
- Some libm `pow` implementations (e.g. the one in musl) don't implement the signaling NaN special-case. See https://rust.godbolt.org/z/chsbv5v4d.
Cc `@tgross35` `@Amanieu`
Motor OS: fix compile error
[PR 148765](https://github.com/rust-lang/rust/pull/148765) changed the expected signature of Thread::new(), which broke Motor OS target.
Also set thread name while at it.
std: don't call `current_os_id` from signal handler
`current_os_id` is not always async-signal-safe depending on the platform, hence it may not be called from the SIGSEGV handler. Instead, store the thread ID along with the thread name during setup. With rust-lang/rust#144465 merged, this information is available even before the thread main function.
Remove initialized-bytes tracking from `BorrowedBuf` and `BorrowedCursor`
As discussed extensively in libs-api, the initialized-bytes tracking primarily benefits calls to `read_buf` that end up initializing the buffer and calling `read`, at the expense of calls to `read_buf` that *don't* need to initialize the buffer. Essentially, this optimizes for the past at the expense of the future. If people observe performance issues using `read_buf` (or something that calls it) with a given `Read` impl, they can fix those performance issues by implementing `read_buf` for that `Read`.
Update the documentation to stop talking about initialized-but-unfilled bytes.
Remove all functions that just deal with those bytes and their tracking, and remove usage of those methods.
Remove `BorrowedCursor::advance` as there's no longer a safe case for advancing within initialized-but-unfilled bytes. Rename `BorrowedCursor::advance_unchecked` to `advance`.
Update tests.
r? ``@Amanieu``
At least on OVMF, some files copied over from linux file system seem
to have invalid time (year = 1980 and everything else 0). Since Rust
allows time to be optional and we can return error, that seems to be
the way to go for now.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
As discussed extensively in libs-api, the initialized-bytes tracking
primarily benefits calls to `read_buf` that end up initializing the
buffer and calling `read`, at the expense of calls to `read_buf` that
*don't* need to initialize the buffer. Essentially, this optimizes for
the past at the expense of the future. If people observe performance
issues using `read_buf` (or something that calls it) with a given `Read`
impl, they can fix those performance issues by implementing `read_buf`
for that `Read`.
Update the documentation to stop talking about initialized-but-unfilled
bytes.
Remove all functions that just deal with those bytes and their tracking,
and remove usage of those methods.
Remove `BorrowedCursor::advance` as there's no longer a safe case for
advancing within initialized-but-unfilled bytes. Rename
`BorrowedCursor::advance_unchecked` to `advance`.
Update tests.
std: split up the `thread` module
Almost all functionality in `std::thread` is currently implemented in `thread/mod.rs`, resulting in a *huge* file with more than 2000 lines and multiple, interoperating `unsafe` sections. This PR splits the file up into multiple different private modules, each implementing mostly independent parts of the functionality. The only remaining `unsafe` interplay is that of the `lifecycle` and `scope` modules, the `spawn_scoped` implementation relies on the live thread count being updated correctly by the `lifecycle` module.
This PR contains no functional changes and only moves code around for the most part, with a few notable exceptions:
* `with_current_name` is moved to the already existing `current` module and now uses the `name` method instead of calculating the name from private fields. The old code was just a reimplementation of that method anyway.
* The private `JoinInner` type used to implement both join handles now has some more methods (`is_finished`, `thread` and the `AsInner`/`IntoInner` implementations) to avoid having to expose private fields and their invariants.
* The private `spawn_unchecked_` (note the underscore) method of `Builder` is now a freestanding function in `lifecycle`.
The rest of the changes are just visibility annotations.
I realise this PR ended up quite large – let me know if there is anyway I can aid the review process.
Edit: I've simplified the diff by adding an intermediate commit that creates all the new files by duplicating `mod.rs`. The actual changes in the second commit thus appear to delete the non-relevant parts from the respective file.
Remove outdated comment
The comment was added in rust-lang/rust#136897 , but wasn't removed when the feature gate was stabilized (again).
Also, `it's` -> `its` :)
Allow the global allocator to use thread-local storage and std::thread::current()
Fixes https://github.com/rust-lang/rust/issues/115209.
Currently the thread-local storage implementation uses the `Global` allocator if it needs to allocate memory in some places. This effectively means the global allocator can not use thread-local variables. This is a shame as an allocator is precisely one of the locations where you'd *really* want to use thread-locals. We also see that this lead to hacks such as https://github.com/rust-lang/rust/pull/116402, where we detect re-entrance and abort.
So I've made the places where I could find allocation happening in the TLS implementation use the `System` allocator instead. I also applied this change to the storage allocated for a `Thread` handle so that it may be used care-free in the global allocator as well, for e.g. registering it to a central place or parking primitives.
r? `@joboet`
Show backtrace on allocation failures when possible
And if an allocation while printing the backtrace fails, don't try to print another backtrace as that will never succeed.
Split out of https://github.com/rust-lang/rust/pull/147725 to allow landing this independently of a decision whether or not to remove `-Zoom=panic`.
Remove outdated part of comment claiming thread_local re-enters global allocator
Fix typo in doc comment
Add comments for guarantees given and footnote that System may still be called
Revise mention of using the global allocator
Allow for the possibility that the global allocator is the system allocator.
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
Stabilize `maybe_uninit_write_slice`
Stabilize feature `maybe_uninit_write_slice` (closes https://github.com/rust-lang/rust/issues/79995).
Note that this also const-stabilizes `<[MaybeUninit<_>]>::write_copy_of_slice`. That method depends on `<[_]>::copy_from_slice`, which is already const-stable, and `<[MaybeUninit<_>]>::assume_init_mut` which is now also stable.
bors