Add cfgs to distinguish WASIp3 and WASIp2 targets - #142
Conversation
|
Still investigating the test failure, but I was able to reproduce it on |
|
Fix for the test here: #143 |
170b21b to
ea32edf
Compare
| fn main() { | ||
| cfg_aliases! { | ||
| // TODO https://github.com/bytecodealliance/wstd/issues/147: Swap these | ||
| // to use `target_env` instead. | ||
| p2: { feature = "p2" }, | ||
| p3: { feature = "p3" }, | ||
| } | ||
| } |
There was a problem hiding this comment.
Saw this handy aliasing in #127 which can let us switch to using the target without a big diff. Not sure what our general philosophy is about pulling in entire crates for such little things though. I left it as a separate commit so it's easy to revert if we don't want it.
| rustup default "${{ steps.select.outputs.version }}" | ||
| # `rustup default` gets overwritten by rust-toolchain.toml, `rustup | ||
| # override` has higher precedence though. | ||
| rustup override set "${{ steps.select.outputs.version }}" |
There was a problem hiding this comment.
Note: it looks like our previous setup was actually running the stable toolchain for the msrv and nightly jobs because the included rust-toolchain.toml file was overriding the default set here.
| rust-version = "1.91.1" | ||
| rust-version = "1.92.0" |
There was a problem hiding this comment.
Had to bump the msrv because 1.91.1 doesn't have the p3 target_env and using it will throw a warning.
adamrk
changed the title
cfgs to distinguish WASIp3 and WASIp2 targets
2 participants
Gate WASIp2 specific features behind
cfg(all(target_os = "was", target_env = "p2"))to set up WASIp3 implementation.Addresses #144