Repository navigation
wasip2 target should not conditionally feature gate stdlib APIs #130323
Description
This was introduced in #119616 (cc @rylev)
Currently, any crate using std::os::wasi stuff needs to add a #![feature(wasip2)] if it is to be compiled with --target=wasm32-wasip2. This is due to this line:
rust/library/std/src/os/wasi/mod.rs
Line 32 in 0307e40
This puts library authors targeting stable wasm stuff in an annoying situation of needing to add a feature gate to support downstream users who wish to use unstable wasm stuff (see servo/rust-url#960). This isn't really how feature gates should work: the entity using the feature should be the one opting in. I don't think any of the benefits of feature gates apply if every wasi-using dep in the ecosystem just slaps on a #![cfg_attr(all(target_os = "wasi", target_env = "p2"), feature(wasip2))], which seems likely here.
A somewhat legitimate reason I could see for having such a feature is if the wasip2 target is stable, but certain stdlib things are unstable under that target. It still has the same problems, and I'd argue a target with specially unstable stdlib APIs should not be considered stable, but at least there appears to be a meaningful thing that the stdlib feature gate is gating.
However, it appears to me that wasip2 is just unstable: what's the purpose of gating the stdlib API? If the goal is to gate the target, why not require -Zunstable-options as we do for other CLI-level unstable things?
Activity
Noratrieb commentedon Sep 13, 2024
@alexcrichton
alexcrichton commentedon Sep 13, 2024
Thanks for the cc here, and thanks for the issue! This is an intentional de-stabilization because the bindings in
std::os::wasiare tailored to exactly WASIp1, not WASIp2. I recommended @rylev make this module unstable on the p2 target to provide freedom for the standard library to change its implementation over time. The module will likely be removed and/or entirely changed on the WASIp2 target, notably usingstd::os::wasip2instead ofstd::os::wasi.It's worth noting though that this is a very coarse de-stabilization. It looks like rust-url is using
std::os::wasi::prelude::OsStrExtwhich is indeed the same on wasip2 and wasip1. In such a situation it would make sense to make that stable on the p2 target. (this is the sort of thing though where I wanted to make sure stabilization was explicitly opted-in-to instead of accidentally happening)I'll try to work on a PR to flag some bits that make sense as stable.
@Manishearth do you know of other crates that are adding this feature? If so could you point me to them so I can review what bits are being used?
Manishearth commentedon Sep 13, 2024
@alexcrichton I believe @brooksmtownsend has been going around makiing this work across reqwest deps. I appreciate the work to stabilize some of those bits!
Honestly, I suspect a cleaner path forward would be to make
std::os::wasi_unreachable) in wasip2 and instead expose an unstablestd::os::wasip2that's actually just reexports for now. This is similar to how support for other new platforms works for ecosystem crates, at the moment it feels like it's just elbowing in on the existing wasm code in a way that's confusing.alexcrichton commentedon Sep 13, 2024
Yeah I'm thinking similarly. For rust-url in the meantime I might recommend using
.to_str()on WASI platforms instead of.as_bytes()since it's practically infallible as all WASI paths are valid utf-8.brooksmtownsend commentedon Nov 4, 2024
Thanks @alexcrichton , that's the path I took in the above mentioned PR and that worked pretty well.
fix: enable wasip2 feature for wasm32-wasip2 target (#305)
Support compiling to wasm32-wasip2
Support compiling to wasm32-wasip2
8 remaining items
fix: compilation on wasip2
fix: compilation on wasip2
fix: compilation on wasip2
feat(path): enable Path and friends on wasip2 without the feature
fix: compilation on wasip2 (#5368)
fix: compilation on wasip2 (#5368)
fix: compilation on wasip2 (PyO3#5368)
feat(path): enable Path and friends on wasip2 without the feature
Make it possible to use Path and friends on wasip2 without the so nam…
feat: Wasm32 wasi 0.41.0 (#888)
fix: enable wasip2 feature for wasm32-wasip2 target (Stebalien#305)