fix(no_std)!: respect std feature when target is windows/unix

[salmans]

This PR fixes feature flag handling to properly respect the std feature when targeting Windows/Unix platforms.

Breaking Change: This fix will disable standard library features for dependents that use wasmtime with default-features = false.

Changes:

• Updated feature dependencies in Cargo.toml files to conditionally enable std-dependent features
• Added proper feature gating in runtime modules for no_std compatibility
• Modified VM system module to respect the std feature flag on Windows/Unix targets

The fix ensures that when wasmtime is used without default features, it properly builds in no_std on all supported platforms.

[alexcrichton]

Thanks for the PR! Could you elaborate on the motivation for this change as well? For example I'm not aware of a target that's cfg(unix) or cfg(windows) and doesn't have std.

[salmans]

@alexcrichton I’m experimenting with running Wasmtime (with Pulley) in the Windows kernel. The goal is to use WebAssembly to enable limited changes to kernel logic without requiring a full software update or system restart. I’m exploring Wasm as a potential alternative to eBPF for Windows.

[alexcrichton]

Oh nice! Do you know if there's a #[cfg] specific to the target that you're working with that this could be keyed on instead of feature = "std"? While the breakage here isn't the end of the world and something we could document, I'd prefer to shape the change a bit differently. For example there's no testing on CI that a no_std build works on Linux/Windows so this is something that will likely easily regress over time.

[salmans]

No, I don't think there's any specific target for (windows/unix) kernel. But just to clarify, are you suggesting that turning off std should still pull in standard library to avoid issues like the ones with CI? If so, an alternative solution that I can think of is to guard no_std with a new flag like override-std or force-no-std.

[alexcrichton]

Sorry I can be more clear, my concern was a big vague there. I originally had the gut reaction of "this feels weird" but I'm effectively getting over that gut reaction. There's still changes I'd like to see in this PR, but I can try to be more clear about them. I've left various review comments below.

[salmans]

@alexcrichton after more experimentation on Windows, I realized win.rs in jit-icache-coherence pulls std. I'm happy to explore a no_std implementation for it in a separate PR but for now, I just pushed a new commit to disable icache coherence in Windows no_std. If that change makes sense, I'm going to address the remaining CI issues before finalizing the PR. Thanks again for your help!

[alexcrichton]

For the stack switching issues can you update the stack-switching cargo feature to require std?

[alexcrichton]

For this it's a pretty critical operation here to manage the icache so we'll want to avoid this #[cfg] which makes it difficult to see when it's used and when it isn't. I think the best solution here might be to sidestep the problem entirely and update this line to take the std feature into account. For example that could be (unix || windows) && cfg!(feature = "std") or something like that. A comment there would be good to explain that if std is disabled then it's not supported in Wasmtime right now to interact with the OS which means that it's no longer supported.

[salmans]

I tried that change but it doesn't solve the problem: Wasmtime still pulls std through jit-icache-coherence in no_std Windows.
Another possible solution is to use libc in jit-icache-coherence for no_std Windows at this line. For that, we could add a new std feature flag to jit-icache-coherence and enable it if std in wasmtime is enabled.

[salmans]

I just pushed a new commit that implements the change suggested above but happy to implement a different solution if this is problematic.

[alexcrichton]

Your commit looks reasonable, thanks for doing that! I'll apologize again though about how this is a bit messy. I'd prefer to avoid having the crate be sort of half-std/half-not, so I think I've come up with an idea to sidestep this entirely which is to include the icache crate only if std is enabled in Wasmtime itself. That solves the concerns I have about things getting a bit weird sometimes and the only remaining issue is various CI bits and how well this works out. I've pushed up a commit to this PR which implements what I was thinking of and I'll watch CI to see if my strategy won't work due to something I haven't thought of

[salmans]

Not at all! I appreciate your help and the time you've put into this. Okay, I'll wait for CI and merge the changes into the branch as soon as I see green. Thanks again!