Add cfg Support for Distinguishing WASI Targets

[namse]

WASI supports different features depending on whether it is p1 or p2. Additionally, p1-threads support threads. The problem is that we cannot determine these distinctions using cfg or similar mechanisms. In crates like tokio, it's impossible to create conditional compilation branches with cfg, such as 'this feature is not available in p1 but is supported in p2, so let's create a conditional branch.'

Therefore, I would like to request support for a method to distinguish WASI targets more precisely using cfg or a similar mechanism.

[workingjubilee]

uhhh cc @alexcrichton @sunfishcode @yoshuawuyts

[CryZe]

#[cfg(target_env = "p2")] should work. Though it doesn't seem like p1 was added, unless I'm just not seeing it right now. While negating the condition would work for now, it does seem dangerous whenever there's a p3.

[workingjubilee]

oh. can someone add that to the platform support page? I don't see it on https://doc.rust-lang.org/nightly/rustc/platform-support/wasm32-wasip2.html

[alexcrichton]

I've added target_env = "p1" in #125869. Today you'll have to do not(target_env = "p2") and while that's not great for hypothetical future iterations it's all that's possible today beyond detecting the target in build.rs and setting a cfg key yourself.

For wasm32-wasip1-threads the only way to detect that is with the Nightly-only target_feature = "atomics". That's not the best detection mechanism since it's reasonable that the feature may be enabled by default for all wasm targets in the future (e.g. it's a similar situation where not(target_env = "p2") is not a great detection mechanism. Failing that your only detection mechanism will be build.rs and looking at TARGET (after probably looking at CARGO_CFG_TARGET_FAMILY to check it's wasm.

[workingjubilee]

This seems to have been addressed to our current abilities. Thanks!