rust/library/std/Cargo.toml, branch try-perf

Rollup merge of #145973 - vexide:vex-std, r=tgross35

2025-09-25T10:31:53+00:00

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](https://github.com/vexide/vexide/blob/c6c5bad11e035cf4e51d429dca7e427210185ed4/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.

std: add support for armv7a-vex-v5 target

2025-09-24T17:10:15+00:00

Co-authored-by: Lewis McClelland

Add panic=immediate-abort

2025-09-21T17:12:18+00:00

std: Update `wasi` crate dependency

2025-09-06T00:01:07+00:00

The recent work on the WASIp2 target being integrated into the standard library ended up causing a bug in nightly on the target. This has now been fixed in the `wasi` crate so this commit pulls in the updated version to ensure bindings work correctly.

std: Start supporting WASIp2 natively

2025-08-28T22:07:15+00:00

This commit is the start of an effort to support WASIp2 natively in the standard library. Before this commit the `wasm32-wasip2` target behaved exactly like `wasm32-wasip1` target by importing APIs from the core wasm module `wasi_snapshot_preview1`. These APIs are satisfied by the `wasm-component-ld` target by using an [adapter] which implements WASIp1 in terms of WASIp2. This adapter comes at a cost, however, in terms of runtime indirection and instantiation cost, so ideally the adapter would be removed entirely. The purpose of this adapter was to provide a smoother on-ramp from WASIp1 to WASIp2 when it was originally created. The `wasm32-wasip2` target has been around for long enough now that it's much more established. Additionally the only thing historically blocking using WASIp2 directly was implementation effort. Work is now underway to migrate wasi-libc itself to using WASIp2 directly and now seems as good a time as any to migrate the Rust standard library too. Implementation-wise the milestones here are: * The `wasm32-wasip2` target now also depends on the `wasi` crate at version 0.14.* in addition to the preexisting dependency of 0.11.*. The 0.14.* release series binds WASIp2 APIs instead of WASIp1 APIs. * Some preexisting naming around `mod wasi` or `wasi.rs` was renamed to `wasip1` where appropriate. For example `std::sys::pal::wasi` is now called `std::sys::pal::wasip1`. * More platform-specific WASI modules are now split between WASIp1 and WASIp2. For example getting the current time, randomness, and process arguments now use WASIp2 APIs directly instead of using WASIp1 APIs that require an adapter. It's worth pointing out that this PR does not migrate the entire standard library away from using WASIp1 APIs on the `wasm32-wasip2` target. Everything related to file descriptors and filesystem APIs is still using WASIp1. Migrating that is left for a future PR. In the meantime the goal of this change is to lay the groundwork necessary for migrating in the future. Eventually the goal is to drop the `wasi` 0.11.* dependency on the `wasm32-wasip2` target (the `wasm32-wasip1` target will continue to retain this dependency). [adapter]: https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-preview1-component-adapter/README.md

library: Migrate from `cfg_if` to `cfg_select`

2025-08-16T12:28:31+00:00

Migrate the standard library from using the external `cfg_if` crate to using the now-built-in `cfg_select` macro. This does not yet eliminate the dependency from `library/std/Cargo.toml`, because while the standard library itself no longer uses `cfg_if`, it also incorporates the `backtrace` crate, which does. Migration assisted by the following vim command (after selecting the full `cfg_if!` invocation): ``` '<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e ``` This is imperfect, but substantially accelerated the process. This prompts for confirmation on the `} else {` since that can also appear inside one of the arms. This also requires manual intervention to handle any multi-line conditions.

Remove `std`'s dependency on `compiler-builtins`

2025-07-31T22:47:24+00:00

`compiler-builtins` is already in the crate graph via `alloc`, and all features related to `compiler-builtins` goes through `alloc`. There isn't any reason that `std` needs this direct dependency, so remove it.

Rollup merge of #144471 - tgross35:compiler-builtins-asm, r=Amanieu

2025-07-27T23:16:38+00:00

Remove `compiler-builtins-{no-asm,mangled-names}` Remove `compiler-builtins-no-asm` This feature used to be for when Cranelift didn't support inline assembly, but its last uses were removed in 52933e0bd200 ("Don't disable inline asm usage in compiler-builtins when the cranelift backend is enabled"). and cba05a7a14b3 ("Support naked functions"). This doesn't remove the feature from the `compiler-builtins` crate, that will be done separately in the subtree repo. --- Remove `compiler-builtins-mangled-names` This config was added in 207de019dc67 ("libary: Forward compiler-builtins "asm" and "mangled-names" feature") but it does not appear this has ever been used. The PR adding it (rust-lang/rust#78472) says that this was exposed to help with configuration and points at the [Hermit Cargo config], but as far as I can tell, this feature name has never been mentioned in that repository's git history. Thus, clean up a seemingly unneeded feature. [Hermit Cargo config]: https://github.com/hermit-os/hermit-rs/blob/ab2b830930e6a9a98c8294997a8183feeabeda4a/.cargo/config

Auto merge of #144490 - tgross35:rollup-ps0utme, r=tgross35

2025-07-26T10:12:14+00:00

Rollup of 9 pull requests Successful merges: - rust-lang/rust#140871 (Don't lint against named labels in `naked_asm!`) - rust-lang/rust#141663 (rustdoc: add ways of collapsing all impl blocks) - rust-lang/rust#143272 (Upgrade the `fortanix-sgx-abi` dependency) - rust-lang/rust#143585 (`loop_match`: suggest extracting to a `const` item) - rust-lang/rust#143698 (Fix unused_parens false positive) - rust-lang/rust#143859 (Guarantee 8 bytes of alignment in Thread::into_raw) - rust-lang/rust#144160 (tests: debuginfo: Work around or disable broken tests on powerpc) - rust-lang/rust#144412 (Small cleanup: Use LocalKey methods more) - rust-lang/rust#144431 (Disable has_reliable_f128_math on musl targets) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #143272 - tgross35:bump-fortanix, r=jhpratt,jethrogb

2025-07-26T07:19:27+00:00

Upgrade the `fortanix-sgx-abi` dependency 0.6.1 removes the `compiler-builtins` dependency, part of RUST-142265. The breaking change from 0.5 to 0.6 is for an update to the `insecure_time` API [1]. I validated that `./x c library --target x86_64-fortanix-unknown-sgx` completes successfully with this change. Link: https://github.com/fortanix/rust-sgx/commit/a34e9767f37d6585c18bdbd31cddcadc56670d57 [1]