std: reorganize the UNIX-internal `weak` module
This moves the `dlsym`-based and weak-linkage versions of the `weak!` macro into separate files, both of which include a common test file. As a result, both versions will be tested on all the platforms where they are used.
Since the `#[link_name]` arm of the `dlsym` version was unused, I've removed it. I've also removed the unused `raw_syscall!` and non-Linux `syscall!` macros and gated the `#[allow(dead_code, unused_macros)]` to only apply on non-Linux platforms, so compilation will fail if `weak` turns out to be unused on all platforms.
The last change concerns the use of `dlsym!` on FreeBSD: it is only used once, to link against `sysctlbyname`. But that symbol is always available, so there is no need for weak linkage.
os_str: Make platform docs more consistent
- Port `Buf::as_slice`/`as_mut_slice` wording from wtf8 to bytes
- Make `Buf::extend_from_slice_unchecked` docs more platform-independent
- wtf8 `Buf` was missing `#[repr(transparent)]`
- Port `Buf::as_slice`/`as_mut_slice` wording from wtf8 to bytes
- Make `Buf::extend_from_slice_unchecked` docs more platform-independent
- wtf8 `Buf` was missing `#[repr(transparent)]`
move `once` module out of `poison`
From https://github.com/rust-lang/rust/issues/134645#issuecomment-3324577500, since `Once` will not have a non-poisoning variant, we remove it from the `poison` module.
Additionally:
1. Renames `once::ExclusiveState` to `OnceExclusiveState` since it was a bit confusing reading just `ExclusiveState` where it is used.
2. Reorders a few module definitions and re-exports in `library/std/src/sync/mod.rs` for clarity.
Also, once this is merged, I think that we can begin the process of stabilizing [`sync_poison_mod`](https://github.com/rust-lang/rust/issues/134646)
std::thread spawn: Docs: Link to Builder::spawn; Make same.
Replace "use this API instead" with a link to Builder::spawn. Edit the paragraph to make it slightly clearer.
The Scope::spawn method already included a link to `Builder::spawn_scoped`. Make the docs for `Scope::spawn` and `thread::spawn` nearly the same.
Implement `Debug` for `EncodeWide`
Since `std::os::windows::ffi::EncodeWide` was reexported from `std::sys_common::wtf8::EncodeWide`, which has `#![allow(missing_debug_implementations)]` in the parent module, it did not implement `Debug`. When it was moved to `core`, a placeholder impl was added; fill it in.
This becomes insta-stable.
r? libs-api
It is a bit confusing when reading code that uses this type since it is
not immediately obvious that it is specific to `Once`.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
`is_ascii` on an empty string or slice returns true
Update the description of the [`is_ascii`](https://doc.rust-lang.org/std/primitive.str.html#method.is_ascii) functions - an empty string or slice also returns `true`.
This follows the pattern of [`all()`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.all). Clippy currently suggests to change `string.chars().all(|c| c.is_ascii())` into `string.is_ascii()`. This suggestion therefore seems fitting.
I've already questioned the behavior for this multiple times. I've always had to check the internals to conclude how it works. That's why I'm opening this PR to add it directly in the documentation.
std: Add Motor OS std library port
Motor OS was added as a no-std Tier-3 target in
[PR 146848](https://github.com/rust-lang/rust/pull/146848) as x86_64-unknown-motor.
This PR adds the std library for Motor OS.
While the PR may seem large, all it does is proxy
std pal calls to [moto-rt](https://crates.io/crates/moto-rt). Where there is some non-trivial
code (e.g. thread::spawn), it is quite similar, often
identical, to what other platforms do.
Stabilize `rwlock_downgrade` library feature
Tracking Issue: https://github.com/rust-lang/rust/issues/128203
Method to be stabilized:
```rust
impl<'a, T: ?Sized> RwLockWriteGuard<'a, T> {
pub fn downgrade(s: Self) -> RwLockReadGuard<'a, T> {}
}
```
~~I would like to point out that my documentation comment is longer than ideal, but at the same time I don't really know how else to show why `downgrade` is actually necessary (instead of just unlocking and relocking). If anyone has ideas for making this more concise that would be great!~~ I have made the documentation a bit more clear.
Stabilization report: https://github.com/rust-lang/rust/issues/128203#issuecomment-3016682463
Move computation of allocator shim contents to cg_ssa
In the future this should make it easier to use weak symbols for the allocator shim on platforms that properly support weak symbols. And it would allow reusing the allocator shim code for handling default implementations of the upcoming externally implementable items feature on platforms that don't properly support weak symbols.
In addition to make this possible, the alloc error handler is now handled in a way such that it is possible to avoid using the allocator shim when liballoc is compiled without `no_global_oom_handling` if you use `#[alloc_error_handler]`. Previously this was only possible if you avoided liballoc entirely or compiled it with `no_global_oom_handling`. You still need to avoid libstd and to define the symbol that indicates that avoiding the allocator shim is unstable.
std: improve handling of timed condition variable waits on macOS
Fixesrust-lang/rust#37440 (for good).
This fixes two issues with `Condvar::wait_timeout` on macOS:
Apple's implementation of `pthread_cond_timedwait` internally converts the absolute timeout to a relative one, measured in nanoseconds, but fails to consider overflow when doing so. This results in `wait_timeout` returning much earlier than anticipated when passed a duration that is slightly longer than `u64::MAX` nanoseconds (around 584 years). The existing clamping introduced by rust-lang/rust#42604 to address rust-lang/rust#37440 unfortunately used a maximum duration of 1000 years and thus still runs into the bug when run on older macOS versions (or with `PTHREAD_MUTEX_USE_ULOCK` set to a value other than "1"). See https://github.com/rust-lang/rust/issues/37440#issuecomment-3285958326 for context.
Reducing the maximum duration alone however would not be enough to make the implementation completely correct. As macOS does not support `pthread_condattr_setclock`, the deadline passed to `pthread_cond_timedwait` is measured against the wall-time clock. `std` currently calculates the deadline by retrieving the current time and adding the duration to that, only for macOS to convert the deadline back to a relative duration by [retrieving the current time itself](1ebf56b3a7/src/pthread_cond.c (L802-L819)) (this conversion is performed before the aforementioned problematic one). Thus, if the wall-time clock is adjusted between the `std` lookup and the system lookup, the relative duration could have changed, possibly even to a value larger than $2^{64}\ \textrm{ns}$. Luckily however, macOS supports the non-standard, tongue-twisting `pthread_cond_timedwait_relative_np` function which avoids the wall-clock-time roundtrip by taking a relative timeout. Even apart from that, this function is perfectly suited for `std`'s purposes: it is public (albeit badly-documented) API, [available since macOS 10.4](1ebf56b3a7/include/pthread/pthread.h (L555-L559)) (that's way below our minimum of 10.12) and completely resilient against wall-time changes as all timeouts are [measured against the monotonic clock](e3723e1f17/bsd/kern/sys_ulock.c (L741)) inside the kernel.
Thus, this PR switches `Condvar::wait_timeout` to `pthread_cond_timedwait_relative_np`, making sure to clamp the duration to a maximum of $2^{64} - 1 \ \textrm{ns}$. I've added a miri shim as well, so the only thing missing is a definition of `pthread_cond_timedwait_relative_np` inside `libc`.
std: implement `pal::os::exit` for VEXos
This PR provides a more "proper" implementation of process exiting in VEXos programs by going through `vexSystemExitRequest` rather than calling `intrinsics::abort`, which exits using an undefined instruction trap. This matches the existing implementation of `rt::abort_internal` and therefore makes `std::process::exit` have the same behavior as returning from main on VEXos targets.
Perform unused assignment and unused variables lints on MIR.
Rebase of https://github.com/rust-lang/rust/pull/101500
Fixes https://github.com/rust-lang/rust/issues/51003.
The first commit moves detection of uninhabited types from the current liveness pass to MIR building.
In order to keep the same level of diagnostics, I had to instrument MIR a little more:
- keep for which original local a guard local is created;
- store in the `VarBindingForm` the list of introducer places and whether this was a shorthand pattern.
I am not very proud of the handling of self-assignments. The proposed scheme is in two parts: first detect probable self-assignments, by pattern matching on MIR, and second treat them specially during dataflow analysis. I welcome ideas.
Please review carefully the changes in tests. There are many small changes to behaviour, and I'm not sure all of them are desirable.
Currently it is possible to avoid linking the allocator shim when
__rust_no_alloc_shim_is_unstable_v2 is defined when linking rlibs
directly as some build systems need. However this requires liballoc to
be compiled with --cfg no_global_oom_handling, which places huge
restrictions on what functions you can call and makes it impossible to
use libstd. Or alternatively you have to define
__rust_alloc_error_handler and (when using libstd)
__rust_alloc_error_handler_should_panic
using #[rustc_std_internal_symbol]. With this commit you can either use
libstd and define __rust_alloc_error_handler_should_panic or not use
libstd and use #[alloc_error_handler] instead. Both options are still
unstable though.
Eventually the alloc_error_handler may either be removed entirely
(though the PR for that has been stale for years now) or we may start
using weak symbols for it instead. For the latter case this commit is a
prerequisite anyway.
give a better example why `std` modules named like primitives are needed
A small update to the `std` `lib.rs` introduction to replace mentions of `std::i32` (never needed) with `std::char` (sometimes needed).
Related to rust-lang/rust#146882.
