`url` crate and "use of unstable library feature 'wasip2'" · general

Is there a crate feature, toolchain, nightly, etc combo that allows a crate to use toolchain wasm32-wasip2 even if crate dependencies are using std::os::wasi::prelude::OsStrExt?

Does wasip2 actually require nightly? It seemed to work before adding a dep on a dep on url.

I've tried following the comments on several posts about wasi2 and it seemed like there are workarounds. I understand the problem, but I don't understand if there's a fix if you have deps using that API.

wasip2 target should not conditionally feature gate stdlib APIs · Issue #130323 · rust-lang/rust

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...

fix: enable wasip2 feature for wasm32-wasip2 target by cdmurph32 · Pull Request #305 · Stebalien/tempfile

wasip2 will require +nightly until wasip2 target should not conditionally feature gate stdlib APIs rust-lang/rust#130323 is resolved and/or std::os::wasip2 is available in stable. Support was added...

adam (Dec 16 2024 at 20:59):

Does unstable in "unstable library feature" mean I need a different toolchain or component? How does compiling Url which uses os wasi but doesn't have a feature called wasip2 throw this error?

Alex Crichton (Dec 16 2024 at 21:17):

The std::os::wasi module in Rust is unstable on the wasip2 target, and std::os::wasip2 will get filled out in the future with extensions as necessary. It's recommended to not use it for now. The wasip2 target does not require nightly, you can use it from stable.

If you have deps that require nightly there's unfortunately nothing you can do other than helping get the deps off nightly.

adam (Dec 17 2024 at 04:04):

So libraries updated to use a std API that worked for an initial wasi target (I'm assuming wasm32-wasi) but those std APIs don't work for subsequent WASI versions. What is it about the WASI implementation that makes those three WASI targets not backwards compatible? I thought the preview versions were additive of new system APIs and not incompatible.

Seems like there isn't a workaround for a dependency depending on URL. There's only two uses of os::wasi::prelude in Url and 5 uses of Url in the intermediary crate. So close, yet not really an available path forward? Not sure I'd be able to contribute or help if there was a way to get either crate working on wasip2.

Alex Crichton (Dec 17 2024 at 15:19):

wasm32-wasip2 is a new target, and like all targets it has its own implementation of std::os. The std::os::wasi module was WASIp1 specific and no one has put in the effort yet to make it WASIp2 specific. It can't automatically inherit wrong legacy bindings by default.

For url it needs OsStrExt IIRC and that can be replaced with .to_str().unwrap().as_bytes(), no need for OsStrExt on WASI.

Stream: general

Topic: `url` crate and "use of unstable library feature 'wasip2'"

adam (Dec 16 2024 at 20:51):

adam (Dec 16 2024 at 20:59):

Alex Crichton (Dec 16 2024 at 21:17):

adam (Dec 17 2024 at 04:04):

Alex Crichton (Dec 17 2024 at 15:19):