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)
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>
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.
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`.
Motor OS was added as a no-std Tier-3 target in
https://github.com/rust-lang/rust/pull/146848
as x86_64-unknown-motor.
This patch/PR adds the std library for Motor OS.
While the patch may seem large, all it does is proxy
std pal calls to moto-rt. When there is some non-trivial
code (e.g. thread::spawn), it is quite similar, and often
identical, to what other platforms do.
Add a new `wasm32-wasip3` target to Rust
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group.
As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably:
* The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup.
* Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use.
* Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target.
These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change.
[`wasip3` crate]: https://crates.io/crates/wasip3
std: `sys::net` cleanups
This PR contains three improvements to the socket-based networking implementation (aa1263e768 is just to add the now missing `unsafe`). Best reviewed commit-by-commit.
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This
follows in the footsteps of the previous `wasm32-wasip2` target and is
used to represent binding to the WASIp3 set of APIs managed by the WASI
subgroup to the WebAssembly Community Group.
As of now the WASIp3 set of APIs are not finalized nor standardized.
They're in the process of doing so and the current trajectory is to have
the APIs published in December of this year. The goal here is to get the
wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the `wasm32-wasip3` target looks exactly the same as
`wasm32-wasip2` except that `target_env = "p3"` is specified. This
indicates to crates in the ecosystem that WASIp3 APIs should be used,
such as the [`wasip3` crate]. Over time this target will evolve as
implementation in guest toolchains progress, notably:
* The standard library will use WASIp3 APIs natively once they're
finalized in the WASI subgroup.
* Support through `wasi-libc` will be updated to use WASIp3 natively
which Rust will then transitively use.
* Longer-term, features such as cooperative multithreading will be added
to the WASIp3-track of targets to enable using `std::thread`, for
example, on this target.
These changes are all expected to be non-breaking changes for users of
this target. Runtimes supporting WASIp3, currently Wasmtime and Jco,
support WASIp2 APIs as well and will work with components whether or not
they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This
means that changing the internal implementation details of libstd over
time is expected to be a non-breaking change.
[`wasip3` crate]: https://crates.io/crates/wasip3
Support `#[rustc_align_static]` inside `thread_local!`
Tracking issue: rust-lang/rust#146177
```rust
thread_local! {
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = const { 0 };
}
```
This increases the amount of recursion the macro performs (once per attribute in addition to the previous once per item), making it easier to hit the recursion limit. I’ve added workarounds to limit the impact in the case of long doc comments, but this still needs a crater run just in case.
r? libs
``@rustbot`` label A-attributes A-macros A-thread-locals F-static_align T-libs
std: implement `hostname`
Resolves https://github.com/rust-lang/libs-team/issues/330
Tracking issue: https://github.com/rust-lang/rust/issues/135142
This is based on rust-lang/rust#135141, but I've reimplemented the UNIX version, which now:
* uses `sysconf(_SC_HOST_NAME_MAX)` as an initial buffer length
* returns `OutOfMemory` if the `Vec` allocation fails
* retries the operation if it detects that the name returned by `gethostname` was truncated
Additionally, as part of the rebase, I had to move some WinSock abstractions (initialisation and error access) to `sys::pal` so that they can be accessed from `sys::net::hostname`.
CC ``@orowith2os`` (and thank you for your work!)
Skip stack overflow handler for panic=immediate-abort
std installs guard pages and a signal handler to ensure that stackoverflows 1) terminate abruptly and 2) print an nice message. Even for panic=immediate-abort, 1) is desirable, we don't want silent data corruption there. But 2) is completely unnecessary, as users deliberately *don't* want nice messages, they want minimum binary size.
Therefore, skip the entire guard signal handler setup, which saves a lot of bytes.
I tested this with a hello world binary using fat LTO, build-std, panic=immediate-abort, opt-level=s, strip=debuginfo.
`size` reports significant savings:
```
text data bss dec hex filename
15252 1032 104 16388 4004 tiny-before
6881 964 48 7893 1ed5 tiny-after2
```
`nm -U` goes from 71 to 56, getting rid of a bunch of stack overflow related symbols. The disk size goes from `31k` to `24k`.
The impact on the error message is minimal, as the message was already
missing.
before:
```
fish: Job 1, './tiny-so-before' terminated by signal SIGABRT (Abort)
```
after:
```
fish: Job 1, './tiny-so-after' terminated by signal SIGSEGV (Address boundary error)
```
I didn't test the Windows part, but it likely also has savings.
std installs guard pages and a signal handler to ensure that stackoverflows 1) terminate abruptly and 2) print an nice message. Even for panic=immediate-abort, 1) is desirable, we don't want silent data corruption there. But 2) is completely unnecessary, as users deliberately *don't* want nice messages, they want minimum binary size.
Therefore, skip the entire guard signal handler setup, which saves a lot of bytes.
I tested this with a hello world binary using fat LTO, build-std, panic=immediate-abort, opt-level=s, strip=debuginfo.
`size` reports significant savings:
```
text data bss dec hex filename
15252 1032 104 16388 4004 tiny-before
6881 964 48 7893 1ed5 tiny-after2
```
`nm -U` goes from 71 to 56, getting rid of a bunch of stack overflow related symbols. The disk size goes from `31k` to `24k`.
The impact on the error message is minimal, as the message was already
missing.
before:
```
fish: Job 1, './tiny-so-before' terminated by signal SIGABRT (Abort)
```
after:
```
fish: Job 1, './tiny-so-after' terminated by signal SIGSEGV (Address boundary error)
```
std: fix warning in VEXos stdio module
Fixes building `std` on the `armv7a-vex-v5` target due to an unnecessarily mutable argument in `Stdin`.
This was a stupid oversight on my part towards the end of rust-lang/rust#145973's review process. Missed a warning and had a bad bootstrap config that didn't tell me about it when testing changes.
Add `std` support for `armv7a-vex-v5`
This PR adds standard library support for the VEX V5 Brain (`armv7a-vex-v5` target). It is more-or-less an updated version of the library-side work done in rust-lang/rust#131530.
This was a joint effort between me, `@lewisfm,` `@max-niederman,` `@Gavin-Niederman` and several other members of the [`vexide` project](https://github.com/vexide/).
## Background
VEXos is a fairly unconventional operating system, with user code running in a restricted enviornment with regards to I/O capabilities and whatnot. As such, several OS-dependent APIs are unsupported or have partial support (such as `std::net`, `std::process`, and most of `std::thread`). A more comprehensive list of what does or doesn't work is outlined in the [updated target documentation](https://github.com/vexide/rust/blob/vex-std/src/doc/rustc/src/platform-support/armv7a-vex-v5.md). Despite these limitations, we believe that `libstd` support on this target still has value to users, especially given the popular use of this hardware for educational purposes. For some previous discussion on this matter, see [this comment](https://github.com/rust-lang/rust/pull/131530#issuecomment-2432856841).
## SDK Linkage
VEXos doesn't really ship with an official `libc` or POSIX-style platform API (and though it does port newlib, these are stubbed on top of the underlying SDK). Instead, VEX provides their own SDK for calling platform APIs. Their official SDK is kept proprietary (with public headers), though open-source implementations exist. Following the precedent of the `armv6k-nintendo-3ds` team's work in rust-lang/rust#95897, we've opted not to directly link `libstd` to any SDK with the expectation that users will provide their own with one of the following options:
- [`vex-sdk-download`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-download), which downloads an official proprietary SDK from VEX using a build script.
- [`vex-sdk-jumptable`](https://crates.io/crates/vex-sdk-jumptable), which is a compatible, open-source reimplementation of the SDK using firmware jumps.
- [`vex-sdk-pros`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-pros), which uses the [PROS kernel](https://github.com/purduesigbots/pros) as a provider for SDK functions.
- Linking their own implementation or stubbing the functions required by libstd.
The `vex-sdk` crate used in the VEXos PAL provides `libc`-style FFI bindings for any compatible system library, so any of these options *should* work fine. A functional demo project using `vex-sdk-download` can be found [here](https://github.com/vexide/armv7a-vex-v5-demo/tree/main).
## Future Work
This PR implements virtually everything we are currently able to implement given the current capabilities of the platform. The exception to this is file directory enumeration, though the implementation of that is sufficiently [gross enough](c6c5bad11e/packages/vexide-core/src/fs/mod.rs (L987)) to drive us away from supporting this officially.
Additionally, I have a working branch implementing the `panic_unwind` runtime for this target, which is something that would be nice to see in the future, though given the volume of compiler changes i've deemed it out-of-scope for this PR.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146556 (Fix duration_since panic on unix when std is built with integer overflow checks)
- rust-lang/rust#146679 (Clarify Display for error should not include source)
- rust-lang/rust#146753 (Improve the pretty print of UnstableFeature clause)
- rust-lang/rust#146894 (Improve derive suggestion of const param)
- rust-lang/rust#146950 (core: simplify `CStr::default()`)
- rust-lang/rust#146958 (Fix infinite recursion in Path::eq with String)
- rust-lang/rust#146971 (fix ICE in writeback due to bound regions)
r? `@ghost`
`@rustbot` modify labels: rollup
