Clarify note in `std::sync::LazyLock` example
I doubt most people know what it means, as I did not until a week ago. In the current form, it seems like a `TODO:`.
std: lazily allocate the main thread handle
https://github.com/rust-lang/rust/pull/123550 eliminated the allocation of the main thread handle, but at the cost of greatly increased complexity. This PR proposes another approach: Instead of creating the main thread handle itself, the runtime simply remembers the thread ID of the main thread. The main thread handle is then only allocated when it is used, using the same lazy-initialization mechanism as for non-runtime use of `thread::current`, and the `name` method uses the thread ID to identify the main thread handle and return the correct name ("main") for it.
Thereby, we also allow accessing `thread::current` before main: as the runtime no longer tries to install its own handle, this will no longer trigger an abort. Rather, the name returned from `name` will only be "main" after the runtime initialization code has run, but I think that is acceptable.
This new approach also requires some changes to the signal handling code, as calling `thread::current` would now allocate when called on the main thread, which is not acceptable. I fixed this by adding a new function (`with_current_name`) that performs all the naming logic without allocation or without initializing the thread ID (which could allocate on some platforms).
Reverts #123550, CC ``@GnomedDev``
Update `ReadDir::next` in `std::sys::pal::unix::fs` to use `&raw const (*p).field` instead of `p.byte_offset().cast()`
Since https://github.com/rust-lang/reference/pull/1387 and https://github.com/rust-lang/rust/pull/117572, `&raw mut (*p).field`/`addr_of!((*p).field)` is defined to have the same inbounds preconditions as `ptr::offset`/`ptr::byte_offset`. I.e. `&raw const (*p).field` does not require that `p: *const T` point to a full `size_of::<T>()` bytes of memory, only that `p.byte_add(offset_of!(T, field))` is defined.
The old comment "[...] we don't even get to use `&raw const (*entry_ptr).d_name` because that operation requires the full extent of *entry_ptr to be in bounds of the same allocation, which is not necessarily the case here [...]" is now outdated, and the code can be simplified to use `&raw const (*entry_ptr).field`.
-------
There should be no behavior differences from this PR.
The `: *const dirent64` on line 716 and the `const _: usize = mem::offset_of!(dirent64, $field);` and comment on lines 749-751 are just sanity checks and should not affect semantics.
Since the `offset_ptr!` macro is only called three times, and all with the same local variable entry_ptr, I just used the local variable directly in the macro instead of taking it as an input, and renamed the macro to `entry_field_ptr!`.
The whole macro could also be removed and replaced with just using `&raw const (*entry_ptr).field` in the three places, but the comments on the macro seemed worthwhile to keep.
Also, the macro is only called three times, and all with the same local variable entry_ptr, so just use the local variable directly,
and rename the macro to entry_field_ptr.
Thereby, we also allow accessing thread::current before main: as the runtime no longer tries to install its own handle, this will no longer trigger an abort. Rather, the name returned from name will only be "main" after the runtime initialization code has run, but I think that is acceptable.
This new approach also requires some changes to the signal handling code, as calling `thread::current` would now allocate when called on the main thread, which is not acceptable. I fixed this by adding a new function (`with_current_name`) that performs all the naming logic without allocation or without initializing the thread ID (which could allocate on some platforms).
use a single large catch_unwind in lang_start
I originally planned to use `abort_unwind` but reading the comment in `thread_cleanup` it seems we are deliberately going for slightly nicer error messages here, so this preserves that. It still seems nice to not repeat `catch_unwind` so often.
uefi: helpers: Introduce OwnedDevicePath
This PR is split off from #135368 to reduce noise.
No real functionality changes, just some quality of life improvements.
Also implement Debug for OwnedDevicePath for some quality of life
improvements.
This PR is split off from #135368 to reduce noise.
Rename DevicePath to OwnedDevicePath. This is to allow a non-owning
version of DevicePath in the future to work with UEFI shell APIs which
provide const pointers to device paths for UEFI shell fs mapping.
Also implement Debug for OwnedDevicePath for some quality of life
improvements.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
path: Move is_absolute check to sys::path
I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [1].
This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not.
I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases.
[0]: https://github.com/rust-lang/rust/pull/135368
[1]: https://github.com/rust-lang/rust/issues/52331#issuecomment-2492796137
I am working on fs support for UEFI [0], which similar to windows has prefix
components, but is not quite same as Windows. It also seems that Prefix
is tied closely to Windows and cannot really be extended [1].
This PR just tries to remove coupling between Prefix and absolute path
checking to allow platforms to provide there own implementation to check
if a path is absolute or not.
I am not sure if any platform other than windows currently uses Prefix,
so I have kept the path.prefix().is_some() check in most cases.
[0]: https://github.com/rust-lang/rust/pull/135368
[1]: https://github.com/rust-lang/rust/issues/52331#issuecomment-2492796137
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Use `NonNull::without_provenance` within the standard library
This API removes the need for several `unsafe` blocks, and leads to clearer code. It uses feature `nonnull_provenance` (#135243).
Close#135343
Initial fs module for uefi
- Just a copy of unsupported fs right now to reduce the noise from future PRs to allow for easier review.
- For the full working version of fs on uefi, see [0]
- This is an effort to break the original PR (#129700) into much smaller chunks for faster upstreaming.
[0]: https://github.com/Ayush1325/rust/tree/uefi-file-full
Update a bunch of library types for MCP807
This greatly reduces the number of places that actually use the `rustc_layout_scalar_valid_range_*` attributes down to just 3:
```
library/core\src\ptr\non_null.rs
68:#[rustc_layout_scalar_valid_range_start(1)]
library/core\src\num\niche_types.rs
19: #[rustc_layout_scalar_valid_range_start($low)]
20: #[rustc_layout_scalar_valid_range_end($high)]
```
Everything else -- PAL Nanoseconds, alloc's `Cap`, niched FDs, etc -- all just wrap those `niche_types` types.
r? ghost
Used pthread name functions returning result for FreeBSD and DragonFly
`pthread_getname_np` and `pthread_setname_np` received a wider adoption in past years and was added to:
* FreeBSD by June 11 2020 via [`2ef84b7da9a6c3e23b4a135e6e863581f16d46e1`](2ef84b7da9),
* DargonFly by March 8 2021 via [`ab5dc9aceb34419d1c4b6006739e61acee8ee999`](https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/ab5dc9aceb34419d1c4b6006739e61acee8ee999).
There's not so much advantage except that the result can be checked in debug builds. Ideally it should be unified with Linux' implementation, but it trims the input.
This greatly reduces the number of places that actually use the `rustc_layout_scalar_valid_range_*` attributes down to just 3:
```
library/core\src\ptr\non_null.rs
68:#[rustc_layout_scalar_valid_range_start(1)]
library/core\src\num\niche_types.rs
19: #[rustc_layout_scalar_valid_range_start($low)]
20: #[rustc_layout_scalar_valid_range_end($high)]
```
Everything else -- PAL Nanoseconds, alloc's `Cap`, niched FDs, etc -- all just wrap those `niche_types` types.
- Just a copy of unsupported fs right now to reduce the noise from
future PRs to allow for easier review.
- For the full working version of fs on uefi, see [0]
[0]: https://github.com/Ayush1325/rust/tree/uefi-file-full
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Condvar: implement wait_timeout for targets without threads
This always falls back to sleeping since there is no way to notify a condvar on a target without threads.
Even on a target that has no threads the following code is a legitimate use case:
```rust
use std::sync::{Condvar, Mutex};
use std::time::Duration;
fn main() {
let cv = Condvar::new();
let mutex = Mutex::new(());
let mut guard = mutex.lock().unwrap();
cv.notify_one();
let res;
(guard, res) = cv.wait_timeout(guard, Duration::from_secs(3)).unwrap();
assert!(res.timed_out());
}
```
This renames variables named `str` to other names, to make sure `str`
always refers to a type.
It's confusing to read code where `str` (or another standard type name)
is used as an identifier. It also produces misleading syntax
highlighting.
Add doc aliases for `libm` and IEEE names
Searching "fma" in the Rust documentation returns results for `intrinsics::fma*`, but does not point to the user-facing `mul_add`. Add aliases for `fma*` and the IEEE operation name `fusedMultiplyAdd`. Add the IEEE name to `sqrt` as well, `squareRoot`.
Add UWP (msvc) target support page
- Added Platform Support page for `x86_64-uwp-windows-msvc`, `i686-uwp-windows-msvc`, `thumbv7a-uwp-windows-msvc` and `aarch64-uwp-windows-msvc`
- Adding myself as a maintainer
- Removing the ticks for `thumbv7a-pc-windows-msvc` and `thumbv7a-uwp-windows-msvc` as they do not currently build due to #134565 and https://github.com/rust-lang/backtrace-rs/pull/685
- Fixed a few minor issues to let most of the UWP targets compile
- Happy new year to all!
r? jieyouxu
Searching "fma" in the Rust documentation returns results for
`intrinsics::fma*`, but does not point to the user-facing `mul_add`. Add
aliases for `fma*` and the IEEE operation name `fusedMultiplyAdd`. Add
the IEEE name to `sqrt` as well, `squareRoot`.
std: sync to dep versions of backtrace
Minor versions from backtrace desynced with std (they still differs in patch numbers, but still better):
4d7906bb24/Cargo.toml (L44-L48)
There is hidden bug here, let's see if CI can find it.
cc `@workingjubilee`
more concrete source url of std docs [V2]
r? jhpratt
since you have reivewed https://github.com/rust-lang/rust/pull/134193
> If someone is looking to contribute, they will want the repository as a whole, not the lib.rs for std.
Now the repository url is reserved, I just add another concrete url as an example, to help people finding target page more quickly&easily.
Move some things to `std::sync::poison` and reexport them in `std::sync`
Tracking issue: #134646
r? `@tgross35`
I've used `sync_poison_mod` feature flag instead, because `sync_poison` had already been used back in 1.2.
try-job: x86_64-msvc
Try to write the panic message with a single `write_all` call
This writes the panic message to a buffer before writing to stderr. This allows it to be printed with a single `write_all` call, preventing it from being interleaved with other outputs. It also adds newlines before and after the message ensuring that only the panic message will have its own lines.
Before:
```
thread 'thread 'thread 'thread 'thread '<unnamed>thread 'thread 'thread 'thread '<unnamed><unnamed>thread '<unnamed>' panicked at ' panicked at <unnamed><unnamed><unnamed><unnamed><unnamed>' panicked at <unnamed>' panicked at src\heap.rssrc\heap.rs'
panicked at ' panicked at ' panicked at ' panicked at ' panicked at src\heap.rs' panicked at src\heap.rs::src\heap.rssrc\heap.rssrc\heap.rssrc\heap.rssrc\heap.rs:src\heap.rs:455455:::::455:455::455455455455455:455:99:::::9:9:
:
999:
999:
assertion failed: size <= (*queue).block_size:
:
assertion failed: size <= (*queue).block_size:
assertion failed: size <= (*queue).block_size:
:
:
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_size
assertion failed: size <= (*queue).block_size
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeerror: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
```
After:
```
thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size
thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size
thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size
error: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
```
---
try-jobs: x86_64-gnu-llvm-18
