Fuchsia status code match arm
Adds a match arm for the Fuchsia status code upon a process abort. An additional change moves the Windows status code down into the match arm itself instead of being defined as a constant elsewhere.
r? tmandry
Use Option's discriminant as its size hint
I was looking at this in MIR after a question on discord, and noticed that it ends up with a switch in MIR (<https://rust.godbolt.org/z/3q4cYnnb3>), which it doesn't need because (as `Option::as_slice` uses) the discriminant is already the length.
Use ThreadId instead of TLS-address in `ReentrantLock`
Fixes#123458
`ReentrantLock` currently uses the address of a thread local variable as an ID that's unique across all currently running threads. This can lead to uninituitive behavior as in #123458 if TLS blocks get reused. This PR changes `ReentrantLock` to instead use the `ThreadId` provided by `std` as the unique ID. `ThreadId` guarantees uniqueness across the lifetime of the whole process, so we don't need to worry about reusing IDs of terminated threads. The main appeal of this PR is thus the possibility of changing the `ReentrantLock` API to guarantee that if a thread leaks a lock guard, no other thread may ever acquire that lock again.
This does entail some complications:
- previously, the only way to retrieve the current thread ID would've been using `thread::current().id()` which creates a temporary `Arc` and which isn't available in TLS destructors. As part of this PR, the thread ID instead gets cached in its own thread local, as suggested [here](https://github.com/rust-lang/rust/issues/123458#issuecomment-2038207704).
- `ThreadId` is always 64-bit whereas the current implementation uses a usize-sized ID. Since this ID needs to be updated atomically, we can't simply use a single atomic variable on 32 bit platforms. Instead, we fall back to using a (sound) seqlock on 32-bit platforms, which works because only one thread at a time can write to the ID. This seqlock is technically susceptible to the ABA problem, but the attack vector to create actual unsoundness has to be very specific:
- You would need to be able to lock+unlock the lock exactly 2^31 times (or a multiple thereof) while a thread trying to lock it sleeps
- The sleeping thread would have to suspend after reading one half of the thread id but before reading the other half
- The teared result from combining the halves of the thread ID would have to exactly line up with the sleeping thread's ID
The risk of this occurring seems slim enough to be acceptable to me, but correct me if I'm wrong. This also means that the size of the lock increases by 8 bytes on 32-bit platforms, but this also shouldn't be an issue.
Performance wise, I did some crude testing of the only case where this could lead to real slowdowns, which is the case of locking a `ReentrantLock` that's already locked by the current thread. On both aarch64 and x86-64, there is (expectedly) pretty much no performance hit. I didn't have any 32-bit platforms to test the seqlock performance on, so I did the next best thing and just forced the 64-bit platforms to use the seqlock implementation. There, the performance degraded by ~1-2ns/(lock+unlock) on x86-64 and ~6-8ns/(lock+unlock) on aarch64, which is measurable but seems acceptable to me seeing as 32-bit platforms should be a small minority anyways.
cc `@joboet` `@RalfJung` `@CAD97`
This changes `ReentrantLock` to use `ThreadId` for the thread ownership check instead of the address of a thread local. Unlike TLS blocks, `ThreadId` is guaranteed to be unique across the lifetime of the process, so if any thread ever terminates while holding a `ReentrantLockGuard`, no other thread may ever acquire that lock again.
On platforms with 64-bit atomics, this is a very simple change. On other platforms, the approach used is slightly more involved, as explained in the module comment.
This also adds a `CURRENT_ID` thread local in addition to the already existing `CURRENT`. This allows us to access the current `ThreadId` without the relatively heavy machinery used by `thread::current().id()`.
Document the column numbers for the dbg! macro
The line numbers were also made consistent, some examples used the line numbers as shown on the playground while others used the line numbers that you would expect when just seeing the documentation.
The second option was chosen to make everything consistent.
ptr::metadata: avoid references to extern types
References to `extern types` are somewhat dubious entities, since generally we say that references must be dereferenceable for their size as determined via `size_of_val`, but with `extern type` that is an ill-defined statement. I'd like to make Miri warn for such cases since it interacts poorly with Stacked Borrows. To avoid warnings people can't fix, this requires not using references to `extern type` in the standard library, and I think `DynMetadata` is the only currently remaining use. so this changes `DynMetadata` to use a NonNull raw pointer instead. Given that the alignment was 1, this shouldn't really change anything meaningful.
I also updated a comment added by `@scottmcm` in https://github.com/rust-lang/rust/pull/125479, since I think the old comment is wrong. The `DynMetadata` type itself is not special, it is a normal aggregate. But computing field types for wide pointers (including references) is special.
unix: break `stack_overflow::install_main_guard` into smaller fn
This was one big deeply-indented function for no reason. This made it hard to reason about the boundaries of its safety. Or just, y'know, read. Simplify it by splitting it into platform-specific functions, but which are still asked to keep compiling (a desirable property, since all of these OS use a similar API).
This is mostly a whitespace change, so I suggest reviewing it only after setting Files changed -> (the options gear) -> [x] Hide whitespace as that will make it easier to see how the code was actually broken up instead of raw line diffs.
Rollup of 8 pull requests
Successful merges:
- #125042 (Use ordinal number in argument error)
- #127229 (rustdoc: click target for sidebar items flush left)
- #127337 (Move a few intrinsics to Rust abi)
- #127472 (MIR building: Stop using `unpack!` for `BlockAnd<()>`)
- #127579 (Solve a error `.clone()` suggestion when moving a mutable reference)
- #127769 (Don't use implicit features in `Cargo.toml` in `compiler/`)
- #127844 (Remove invalid further restricting suggestion for type bound)
- #127855 (Add myself to review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Windows: Use futex implementation for `Once`
Keep the queue implementation for win7.
Inspired by PR #121956
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Move a few intrinsics to Rust abi
Move a few more intrinsic functions to the convention added in #121192. In the second commit, I added documentation about their safety requirements. Let me know if you would like me to move the second commit to a different PR.
Note: I kept the same signature of `pref_align_of`, but I was wondering why this function is considered unsafe?
The line numbers were also made consistent, some examples used the line numbers as shown on the playground while others used the line numbers that you would expect when just seeing the documentation.
The second option was chosen to make everything consistent.
Prevent double reference in generic futex
In the Windows futex implementation we were a little lax at allowing references to references (i.e. `&&`) which can lead to deadlocks due to reading the wrong memory address. This uses a trait to tighten the constraints and ensure this doesn't happen.
r? libs
Make more Windows functions `#![deny(unsafe_op_in_unsafe_fn)]`
As part of #127747, I've evaluated some more Windows functions and added `unsafe` blocks where necessary. Some are just trivial wrappers that "inherit" the full unsafety of their function, but for others I've added some safety comments. A few functions weren't actually unsafe at all. I think they were just using `unsafe fn` to avoid an `unsafe {}` block.
I'm not touching `c.rs` yet because that is partially being addressed by another PR and also I have plans to further reduce the number of wrapper functions we have in there.
r? libs
This function is purely informative, answering where a stack starts.
This is a safe operation, even if an answer requires unsafe code,
and even if the result is some unsafe code decides to trust the answer.
It also doesn't need to fetch the PAGE_SIZE when its caller just did so!
Let's complicate its signature and in doing so simplify its operation.
This allows sprinkling around #[forbid(unsafe_op_in_unsafe_fn)]
zkvm: add `#[forbid(unsafe_op_in_unsafe_fn)]` in `stdlib`
This also adds an additional `unsafe` block to address compiler errors.
This PR is intended to address https://github.com/rust-lang/rust/issues/127747 for the zkvm target.
Use futex.rs for Windows thread parking
If I'm not overlooking anything then the Windows 10+ thread parking implementation is practically the same as the futex.rs implementation. So we may as well use the same implementation for both. The old version is still kept around for Windows 7 support.
r? ````@joboet```` if you wouldn't mind double checking I've not missed something
std: Use `read_unaligned` for reads from DWARF
There's a lot of... *stuff* going on here. Meanwhile, `read_unaligned` has been available since 1.17.0, so let's just use that.
Clean up more comments near use declarations
#125443 will reformat all use declarations in the repository. There are a few edge cases involving comments on use declarations that require care. This PR fixes them up so #125443 can go ahead with a simple `x fmt --all`. A follow-up to #126717.
r? ``@cuviper``
Skip fast path for dec2flt when optimize_for_size
Tracking issue: https://github.com/rust-lang/rust/issues/125612
Skip the fast algorithm when optimizing for size.
When compiling for https://github.com/quartiq/stabilizer I get these numbers:
Before
```
text data bss dec hex filename
192192 8 49424 241624 3afd8 dual-iir
```
After
```
text data bss dec hex filename
191632 8 49424 241064 3ada8 dual-iir
```
This saves 560 bytes.
Simplify environment variable examples
I’ve found myself visiting the documentation for `std::env::vars` every few months, and every time I do, it is because I want to quickly get a snippet to print out all environment variables :-)
So I think it could be nice to simplify the examples a little to make them self-contained. It is of course a style question if one should import a module a not, but I personally don’t import modules used just once in a code snippet.
When we do the big `use` reformatting there are a tiny number of cases
where rustfmt moves a comment from one `use` item to another in an
undesirable way. This commit pre-emptively rearranges things to prevent
this from happening.
There are some comments describing multiple subsequent `use` items. When
the big `use` reformatting happens some of these `use` items will be
reordered, possibly moving them away from the comment. With this
additional level of formatting it's not really feasible to have comments
of this type. This commit removes them in various ways:
- merging separate `use` items when appropriate;
- inserting blank lines between the comment and the first `use` item;
- outright deletion (for comments that are relatively low-value);
- adding a separate "top-level" comment.
We also entirely skip formatting for four library files that contain
nothing but `pub use` re-exports, where reordering would be painful.
fix least significant digits of f128 associated constants
While the numbers are parsed to the correct value, the decimal numbers in the source were rounded to zero instead of to the nearest, making the literals different from the values shown in the documentation.