Add support for WASI

[Timmmm]

Add the magic feature() code to allow compiling under wasip2, and expose ino and DirEntryExt.

Tested with cargo +nightly build --target wasm32-wasip2.

[BurntSushi]

I generally don't accept nightly-only stuff in crates I maintain. I've done it in the past for other crates, and I've generally regretted it due to it causing headaches in one form or another.

[Timmmm]

I don't really understand why this is nightly only tbh. Neither this page nor this one mention nightly once.

Is it possible to use WASI without nightly somehow?

Btw if you're curious about my motivation: I got fed up with pre-commit being hella janky due to Python so I'm working on an alternative that uses WASI for all of its linters. First one I've tried to get working is Ruff, which depends on ignore, which depends on walkdir. I actually managed to get it working though with these PRs and some other minor changes!

[BurntSushi]

@Timmmm That first link talks about it: https://blog.rust-lang.org/2024/11/26/wasip2-tier-2.html#standard-library-support

The WASI 0.2 Rust target reaching tier 2 platform support is in a way just the beginning. means it's supported and stable. While the platform itself is now stable, support in the stdlib for WASI 0.2 APIs is still limited. While the WASI 0.2 specification specifies APIs for example for timers, files, and sockets - if you try and use the stdlib APIs for these today, you'll find they don't yet work.

We expect to gradually extend the Rust stdlib with support for WASI 0.2 APIs throughout the remainder of this year into the next. That work has already started, with rust-lang/rust#129638 adding native support for std::net in Rust 1.83. We expect more of these PRs to land through the remainder of the year.

It will take time for these things to stabilize.

[Timmmm]

It doesn't say that nightly is required for wasip2 though... But yeah, anyway feel free to close this if you want. Using a fork is not too bad for my purposes. Ditto the ignore PR.

[BurntSushi]

That's how APIs get added to std. They land as unstable first. Then we stabilize them at some point in the future. (Stabilization is effectively the process of saying, "we promise to support this API ~forever.")

[BurntSushi]

But yeah I'll close this out for now. Happy to have this re-submitted once the APIs stabilize!