Commit Graph

15566 Commits

Author SHA1 Message Date
Matthias Krüger
c1bbe347c2
Rollup merge of #127594 - c6c7:fuchsia-status-code-match-arm, r=tmandry
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
2024-07-18 23:05:21 +02:00
Matthias Krüger
6f7fa03a06
Rollup merge of #127748 - scottmcm:option_len, r=joboet
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.
2024-07-18 18:10:16 +02:00
Matthias Krüger
f62aa415c3
Rollup merge of #124881 - Sp00ph:reentrant_lock_tid, r=joboet
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`
2024-07-18 18:10:14 +02:00
Markus Everling
fe89962237 Update ReentrantLock implementation, add CURRENT_ID thread local.
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()`.
2024-07-18 14:09:25 +00:00
Matthias Krüger
3aafbd28e5
Rollup merge of #127077 - tbu-:pr_doc_fd_to_owned, r=workingjubilee
Make language around `ToOwned` for `BorrowedFd` more precise
2024-07-18 08:08:58 +02:00
Trevor Gross
8bb057874d
Rollup merge of #127861 - Kriskras99:patch-1, r=tgross35
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.
2024-07-17 19:53:29 -05:00
Trevor Gross
c36a39cd1f
Rollup merge of #127859 - RalfJung:ptr-dyn-metadata, r=scottmcm
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.
2024-07-17 19:53:28 -05:00
Trevor Gross
3c4f820c5b
Rollup merge of #127845 - workingjubilee:actually-break-up-big-ass-stack-overflow-fn, r=joboet
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.
2024-07-17 19:53:28 -05:00
bors
e35364a521 Auto merge of #127865 - matthiaskrgr:rollup-8m49dlg, r=matthiaskrgr
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
2024-07-17 21:52:29 +00:00
bors
fcc325f1bc Auto merge of #125942 - timokroeger:windows-once-futex, r=ChrisDenton
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>
-->
2024-07-17 19:28:24 +00:00
Matthias Krüger
3ddfd97198
Rollup merge of #127337 - celinval:intrinsics-fallback, r=oli-obk
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?
2024-07-17 16:22:28 +02:00
Tobias Bucher
2162f3f34b Mention how you can go from BorrowedFd to OwnedFd and back 2024-07-17 14:34:00 +02:00
Tobias Bucher
538b31e977 Make language around ToOwned for BorrowedFd more precise 2024-07-17 14:33:39 +02:00
Kriskras99
99f879c32f
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.
2024-07-17 14:10:41 +02:00
Ralf Jung
f9c0d3370f ptr::metadata: update comment on vtable_ptr work-around 2024-07-17 13:56:25 +02:00
Ralf Jung
21dc49c587 ptr::metadata: avoid references to extern types 2024-07-17 13:50:01 +02:00
Trevor Gross
599d32414b
Rollup merge of #127813 - ChrisDenton:win-futex, r=joboet
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
2024-07-17 04:05:59 -05:00
Trevor Gross
56f95559da
Rollup merge of #127763 - ChrisDenton:safe-unsafe-unsafe, r=tgross35
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
2024-07-17 04:05:59 -05:00
Jubilee Young
d47cb26ddd unix: unsafe-wrap install_main_guard_default 2024-07-17 00:08:05 -07:00
Jubilee Young
6ed563d491 unix: clean up install_main_guard_freebsd
This just was a mess.
2024-07-17 00:06:27 -07:00
Jubilee Young
e285c95cee unix: stack_start_aligned is a safe fn
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)]
2024-07-16 23:46:03 -07:00
Jubilee Young
17c70a9aac unix: split stack_overflow::install_main_guard by os 2024-07-16 23:32:02 -07:00
Chris Denton
0585c4a23e
Prevent double reference in generic futex 2024-07-17 05:57:39 +00:00
Chris Denton
2043de12a3
Narrow the scope of the ReadFile unsafe block 2024-07-17 05:53:20 +00:00
Chris Denton
a33abbba98
forbid(unsafe_op_in_unsafe_fn) in sys/os_str 2024-07-17 05:52:38 +00:00
Trevor Gross
1a1b44fcae
Rollup merge of #127836 - workingjubilee:forbid-unsafe-ops-in-xous-uefi, r=tgross35
std: Forbid unwrapped unsafe ops in xous and uefi modules
2024-07-16 20:10:14 -05:00
Trevor Gross
dd80a728cc
Rollup merge of #127833 - risc0:erik/zkvm-deny-unsafe, r=workingjubilee
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.
2024-07-16 20:10:13 -05:00
Trevor Gross
446e0177ec
Rollup merge of #127807 - ChrisDenton:win-parking, r=joboet
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
2024-07-16 20:10:12 -05:00
Trevor Gross
045b8107f2
Rollup merge of #127792 - workingjubilee:read-unaligned-is-dwarfier, r=joboet
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.
2024-07-16 20:10:12 -05:00
Trevor Gross
4013acdda2
Rollup merge of #127444 - Sky9x:cstr-bytes-iter, r=dtolnay
`impl Send + Sync` and override `count` for the `CStr::bytes` iterator

cc tracking issue #112115
2024-07-16 20:10:11 -05:00
Trevor Gross
606d8cf9e8
Rollup merge of #126776 - nnethercote:rustfmt-use-pre-cleanups-2, r=cuviper
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``
2024-07-16 20:10:10 -05:00
Trevor Gross
fe1dc02163
Rollup merge of #126271 - diondokter:dec2flt-skip-fast-path, r=tgross35
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.
2024-07-16 20:10:09 -05:00
Trevor Gross
689d27293a
Rollup merge of #125206 - mgeisler:simplify-std-env-vars, r=jhpratt,tgross35
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.
2024-07-16 20:10:09 -05:00
Jubilee Young
586ef83f3f uefi: Forbid unwrapped unsafe in platform modules 2024-07-16 16:21:10 -07:00
Dion Dokter
33f1d9d554
Cfg nit
Co-authored-by: Clar Fon <15850505+clarfonthey@users.noreply.github.com>
2024-07-17 01:20:56 +02:00
Jubilee Young
b5a83a6f71 xous: Forbid unwrapped unsafe in platform modules 2024-07-16 16:16:03 -07:00
Erik Kaneda
e48d33e18a
zkvm: add #[forbid(unsafe_op_in_unsafe_fn)] in stdlib
This also adds an additional `unsafe` block to address compiler errors.
2024-07-16 16:04:02 -07:00
Nicholas Nethercote
7f0ccfe69d Adjust some comments on individual use declarations.
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.
2024-07-17 08:05:39 +10:00
Nicholas Nethercote
75b6ec9800 Avoid comments that describe multiple use items.
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.
2024-07-17 08:02:46 +10:00
Nicholas Nethercote
d9fde2504a Merge some core::iter entries. 2024-07-17 08:02:46 +10:00
Chris Denton
10b845cbc8
Add unsafe blocks in unsafe Thread::new 2024-07-16 20:48:39 +00:00
Chris Denton
55c84e39cc
Remove slice_to_end 2024-07-16 20:24:57 +00:00
Jubilee
249905780f
std: unwrapped unsafe is VERBOTEN!
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
2024-07-16 12:51:14 -07:00
Matthias Krüger
08809eb746
Rollup merge of #127789 - Sword-Destiny:master, r=petrochenkov
delete #![allow(unsafe_op_in_unsafe_fn)] in teeos

deny unsafe_op_in_unsafe_fn for teeos
2024-07-16 18:09:11 +02:00
Chris Denton
51bdcf66d3
Use futex.rs for Windows thread parking 2024-07-16 11:21:51 +00:00
Jubilee Young
8dafc5c819 std: Use read_unaligned for reading DWARF 2024-07-16 00:10:08 -07:00
Trevor Gross
57fef31096
Rollup merge of #127047 - tspiteri:f128-aconsts-lsd, r=tgross35
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.
2024-07-16 02:02:24 -05:00
袁浩----天命剑主
9183af25e5
deny unsafe_op_in_unsafe_fn for teeos 2024-07-16 11:47:22 +08:00
袁浩----天命剑主
af5c90d33f
clean unsafe op in unsafe fn 2024-07-16 11:46:16 +08:00
袁浩----天命剑主
00fff8ac64
clean unsafe op in unsafe fn 2024-07-16 11:34:23 +08:00