libcore float tests: replace macro shadowing by const-compatible macro
This lets us avoid https://github.com/rust-lang/rust/issues/153478.
However this means we generate 3 function items per assertion -- or rather, 3*8, since every assertion gets duplicated 8 times (4 float types, each in a const and a non-const variant). That's a lot; is it enough to be concerned about?
coretest already takes forever to build. In a quick test, build time increased from 29.8s to 30.8s, but that may also entirely be noise.
r? @tgross35
std: add wasm64 to sync::Once and thread_parking atomics cfg guards
When targeting `wasm64-unknown-unknown` with atomics enabled, `std::sync::Once` and `thread_parking` fall through to the `no_threads`/`unsupported` implementations because the cfg guards only check for `wasm32`. This causes worker threads to panic with `unreachable` at runtime. The underlying futex implementations already handle both wasm32 and wasm64 correctly, only the cfg guards were missing wasm64.
I tested this manually with a multithreaded wasm64 application ([o1js](https://github.com/o1-labs/o1js/)) compiled with `-Z build-std=panic_abort,std` and `-C target-feature=+atomics,+bulk-memory,+mutable-globals`
Related: rust-lang/rust#83879rust-lang/rust#77839
Happy to adjust anything based on feedback
library/test: always enable unstable features for miri
The unstable features of the `test` crate used to be default-enabled,
and manually disabled when building the beta and stable channels. Commit
dae8ea92a7 flipped that to default-disabled, only enabled for nightly
and dev channels.
However, this broke miri testing on the beta/stable channels, because it
also uses unstable features -- which should be fine to enable just for
its own sysroot build. Now the `test` build script makes that happen by
noticing the `MIRI_CALLED_FROM_SETUP` environment variable.
Update path separators to be available in const context
Tracking issue: rust-lang/rust#153106
This makes platform-dependent secondary path separators available in const context (ie. at compile time). The platform definitions have also been consolidated behind a common macro to prevent transcription errors, whereas previously they were defined 3-4 times per platform.
### Questions
I've manually verified that this compiles against each platform. It seems like no unit tests should be required for this change; is that correct?
* consolidate various representations of separators in std::sys::path
into a single macro_rules invocation per platform to save
transcription errors
* make `std::path::is_separator()` const
* new constants `std::path::{SEPARATORS, SEPARATORS_STR}`
std: refactor Xous startup code
To facilitate rust-lang/rust#117276 I'm moving all non-path-related code out of `sys::pal::os` (see also rust-lang/rust#153130). This is particularly involved for Xous as `pal::os` also contains the `_start` entry function and the parameter block handling. This PR moves both out into the main `sys::pal` module and also simplifies the parameter block initialisation code slightly.
CC @xobs
update panicking() docs for panic=abort
fixesrust-lang/rust#151458
The documentation for `std::thread::panicking()` has not been changed since v1.0, even though panic hooks were added in v1.10.
Current documentation is misleading for `panic=abort`
`panicking()` can return `true` in 2 different cases:
1. Thread unwinds due to panic
2. Panic hook is executing with `panic=abort`
r? @SpriteOvO
The unstable features of the `test` crate used to be default-enabled,
and manually disabled when building the beta and stable channels. Commit
dae8ea92a7 flipped that to default-disabled, only enabled for nightly
and dev channels.
However, this broke miri testing on the beta/stable channels, because it
also uses unstable features -- which should be fine to enable just for
its own sysroot build. Now the `test` build script makes that happen by
noticing the `MIRI_CALLED_FROM_SETUP` environment variable.
Add a convenience method Path::absolute() that delegates to the
existing free function std::path::absolute(), mirroring the pattern of
Path::canonicalize() delegating to fs::canonicalize().
Tracking issue: https://github.com/rust-lang/rust/issues/153328
Update the name of the Hermit operating system
The HermitCore name was dropped a while ago, the project is now simply called "Hermit". See for example [the website](https://hermit-os.org/).
cc @stlankes @mkroening
Clarified doc comments + added tests confirming current behavior for intersperse/intersperse_with
This PR builds on top of rust-lang/rust#152855. I just added clarifying comments to `intersperse`/`intersperse_with` about its guarantees for fused iterators (and how behavior for non-fused iterators are subject to change). I also added in tests for non-fused iterators demonstrating its current behavior; fused iterators are already tested for in existing tests for `intersperse`/`intersperse_with`.
core: make atomic primitives type aliases of `Atomic<T>`
Tracking issue: https://github.com/rust-lang/rust/issues/130539
This makes `AtomicI32` and friends type aliases of `Atomic<T>` by encoding their alignment requirements via the use of an internal `Storage` associated type. This is also used to encode that `AtomicBool` store a `u8` internally.
Modulo the `Send`/`Sync` implementations, this PR does not move any trait implementations, methods or associated functions – I'll leave that for another PR.
Fix compile error in std::fs impl on VEXos target
This PR fixes a compile error in the standard library on the `armv7a-vex-v5` target that was caused by there not being a version of the `Dir` struct exported from `std::sys::fs::vexos`. Reading from directories isn't supported on this platform, so the module now re-exports the unsupported version of `Dir`.
std: move `getpid` to `sys::process`
Part of rust-lang/rust#117276.
Availability of process IDs is highly correlated with availability of processes, so moving the `getpid` implementations to `sys::process` makes a lot of sense (and removes quite some code duplication). The only notable change here is on Hermit, which doesn't have processes but does have `getpid`. But that [always returns 0](https://github.com/hermit-os/kernel/blob/ef27b798856b50d562a42c4ffd2edcb7493c5b5f/src/syscalls/tasks.rs#L21), so I doubt it is useful. If the change to a panic is problematic we could always copy the stub implementation and return zero ourselves (this also applies to the other single-process platforms).
CC @stlankes @mkroening
Jonathan Brouwer