fix: enable wasip2 feature for wasm32-wasip2 target

[cdmurph32]

• 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 to rustix for version 0.38.39 fix: enable wasip2 feature for wasm32-wasip2 target bytecodealliance/rustix#1205

[Stebalien]

From my reading of that issue, this isn't the correct fix. See servo/rust-url#983.

Am I missing something?

[cdmurph32]

In that particular case, @brooksmtownsend was able to get around the use of std::os::wasi::prelude::OsStrExt.

This PR allows for the use of rustix for the wasm32-wasip2 target. There probably isn't a way to have this crate work for that target without rustix for the numerous uses of std::os::wasi without reinventing the wheel.

[brooksmtownsend]

Yeah just to add a bit of context, my original PR to "url" was to enable compilation when wasm32-wasip2 was only on the nightly channel, then my follow up PR was to remove the use of those unstable APIs by using essentially equivalent APIs.

Put another way, this crate currently does not compile to wasm32-wasip2. This PR would enable compilation on the nightly channel, and then enabling compilation on stable would either require a Rust change in the feature gating or to replace the use of those unstable APIs

[Stebalien]

I see... Let's put this behind a new unstable feature flag in tempfile. It sounds like this is liable to break at any time and I don't want users to be surprised.

[Stebalien]

I forgot all about the existing "nightly" feature. I've pushed a change that merges "unstable" into "nightly", does this work for you?

[cdmurph32]

Looks good. Builds on my machine. 😄

[Stebalien]

Hm. It looks like cargo-wasi was just broken by rust-lang/compiler-team#607.

[cdmurph32]

cargo wasi is deprecated. Just use cargo build --target wasm32-wasip2 for this change.

[Stebalien]

3.14 published