From e14d6d8314f792bc8a5cf77a6144cbd57b80a717 Mon Sep 17 00:00:00 2001 From: Graydon Hoare Date: Thu, 10 Oct 2024 00:05:16 -0700 Subject: [PATCH 1/4] Add wasm32v1-none target (compiler-team/#791) --- compiler/rustc_target/src/spec/mod.rs | 1 + .../src/spec/targets/wasm32v1_none.rs | 88 +++++++++++++++++++ tests/assembly/targets/targets-elf.rs | 3 + 3 files changed, 92 insertions(+) create mode 100644 compiler/rustc_target/src/spec/targets/wasm32v1_none.rs diff --git a/compiler/rustc_target/src/spec/mod.rs b/compiler/rustc_target/src/spec/mod.rs index 5ca2a339f72c7..f4cbe47e0f352 100644 --- a/compiler/rustc_target/src/spec/mod.rs +++ b/compiler/rustc_target/src/spec/mod.rs @@ -1803,6 +1803,7 @@ supported_targets! { ("wasm32-unknown-emscripten", wasm32_unknown_emscripten), ("wasm32-unknown-unknown", wasm32_unknown_unknown), + ("wasm32v1-none", wasm32v1_none), ("wasm32-wasi", wasm32_wasi), ("wasm32-wasip1", wasm32_wasip1), ("wasm32-wasip2", wasm32_wasip2), diff --git a/compiler/rustc_target/src/spec/targets/wasm32v1_none.rs b/compiler/rustc_target/src/spec/targets/wasm32v1_none.rs new file mode 100644 index 0000000000000..be6f7eae287d2 --- /dev/null +++ b/compiler/rustc_target/src/spec/targets/wasm32v1_none.rs @@ -0,0 +1,88 @@ +//! A "bare wasm" target representing a WebAssembly output that makes zero +//! assumptions about its environment, similar to wasm32-unknown-unknown, but +//! that also specifies an _upper_ bound on the set of wasm proposals that are +//! supported. +//! +//! It is implemented as a variant on LLVM's wasm32-unknown-unknown target, with +//! the additional flags `-Ctarget-cpu=mvp` and `-Ctarget-feature=+mutable-globals`. +//! +//! This target exists to resolve a tension in Rustc's choice of WebAssembly +//! proposals to support. Since most WebAssembly users are in fact _on the web_ +//! and web browsers are frequently updated with support for the latest +//! features, it is reasonable for Rustc to generate wasm code that exploits new +//! WebAssembly proposals as they gain browser support. At least by default. And +//! this is what the wasm32-unknown-unknown target does, which means that the +//! _exact_ WebAssembly features that Rustc generates will change over time. +//! +//! But a different set of users -- smaller but nonetheless worth supporting -- +//! are using WebAssembly in implementations that either don't get updated very +//! often, or need to prioritize stability, implementation simplicity or +//! security over feature support. This target is for them, and it promises that +//! the wasm code it generates will not go beyond the proposals/features of the +//! W3C WebAssembly core 1.0 spec, which (as far as I can tell) is approximately +//! "the wasm MVP plus mutable globals". Mutable globals was proposed in 2018 +//! and made it in. +//! +//! See https://www.w3.org/TR/wasm-core-1/ +//! +//! Notably this feature-set _excludes_: +//! +//! - sign-extension operators +//! - non-trapping / saturating float-to-int conversions +//! - multi-value +//! - reference types +//! - bulk memory operations +//! - SIMD +//! +//! These are all listed as additions in the core 2.0 spec. Also they were all +//! proposed after 2020, and core 1.0 shipped in 2019. It also excludes even +//! later proposals such as: +//! +//! - exception handling +//! - tail calls +//! - extended consts +//! - function references +//! - multi-memory +//! - component model +//! - gc +//! - threads +//! - relaxed SIMD +//! - custom annotations +//! - branch hinting +//! + +use crate::spec::{Cc, LinkerFlavor, Target, base}; + +pub(crate) fn target() -> Target { + let mut options = base::wasm::options(); + options.os = "none".into(); + + options.cpu = "mvp".into(); + options.features = "+mutable-globals".into(); + + options.add_pre_link_args(LinkerFlavor::WasmLld(Cc::No), &[ + // For now this target just never has an entry symbol no matter the output + // type, so unconditionally pass this. + "--no-entry", + ]); + options.add_pre_link_args(LinkerFlavor::WasmLld(Cc::Yes), &[ + // Make sure clang uses LLD as its linker and is configured appropriately + // otherwise + "--target=wasm32-unknown-unknown", + "-Wl,--no-entry", + ]); + + Target { + llvm_target: "wasm32-unknown-unknown".into(), + metadata: crate::spec::TargetMetadata { + description: Some("WebAssembly".into()), + tier: Some(2), + host_tools: Some(false), + std: Some(false), + }, + pointer_width: 32, + data_layout: "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20".into(), + arch: "wasm32".into(), + options, + } +} diff --git a/tests/assembly/targets/targets-elf.rs b/tests/assembly/targets/targets-elf.rs index f26d06a0ecb87..1857633a8bfae 100644 --- a/tests/assembly/targets/targets-elf.rs +++ b/tests/assembly/targets/targets-elf.rs @@ -522,6 +522,9 @@ //@ revisions: wasm32_unknown_unknown //@ [wasm32_unknown_unknown] compile-flags: --target wasm32-unknown-unknown //@ [wasm32_unknown_unknown] needs-llvm-components: webassembly +//@ revisions: wasm32v1_none +//@ [wasm32v1_none] compile-flags: --target wasm32v1-none +//@ [wasm32v1_none] needs-llvm-components: webassembly //@ revisions: wasm32_wasi //@ [wasm32_wasi] compile-flags: --target wasm32-wasi //@ [wasm32_wasi] needs-llvm-components: webassembly From 212d516ab0e06b6227ce6c0a6d23960f047537bd Mon Sep 17 00:00:00 2001 From: Graydon Hoare Date: Wed, 16 Oct 2024 16:48:53 -0700 Subject: [PATCH 2/4] Address review comments on wasm32v1-none target --- .../src/spec/targets/wasm32v1_none.rs | 67 +++-------- .../host-x86_64/dist-various-2/Dockerfile | 1 + src/doc/rustc/src/SUMMARY.md | 1 + src/doc/rustc/src/platform-support.md | 1 + .../src/platform-support/wasm32v1-none.md | 109 ++++++++++++++++++ src/tools/build-manifest/src/main.rs | 1 + 6 files changed, 128 insertions(+), 52 deletions(-) create mode 100644 src/doc/rustc/src/platform-support/wasm32v1-none.md diff --git a/compiler/rustc_target/src/spec/targets/wasm32v1_none.rs b/compiler/rustc_target/src/spec/targets/wasm32v1_none.rs index be6f7eae287d2..bf35ae009c6ef 100644 --- a/compiler/rustc_target/src/spec/targets/wasm32v1_none.rs +++ b/compiler/rustc_target/src/spec/targets/wasm32v1_none.rs @@ -1,55 +1,16 @@ -//! A "bare wasm" target representing a WebAssembly output that makes zero -//! assumptions about its environment, similar to wasm32-unknown-unknown, but -//! that also specifies an _upper_ bound on the set of wasm proposals that are -//! supported. -//! -//! It is implemented as a variant on LLVM's wasm32-unknown-unknown target, with -//! the additional flags `-Ctarget-cpu=mvp` and `-Ctarget-feature=+mutable-globals`. -//! -//! This target exists to resolve a tension in Rustc's choice of WebAssembly -//! proposals to support. Since most WebAssembly users are in fact _on the web_ -//! and web browsers are frequently updated with support for the latest -//! features, it is reasonable for Rustc to generate wasm code that exploits new -//! WebAssembly proposals as they gain browser support. At least by default. And -//! this is what the wasm32-unknown-unknown target does, which means that the -//! _exact_ WebAssembly features that Rustc generates will change over time. -//! -//! But a different set of users -- smaller but nonetheless worth supporting -- -//! are using WebAssembly in implementations that either don't get updated very -//! often, or need to prioritize stability, implementation simplicity or -//! security over feature support. This target is for them, and it promises that -//! the wasm code it generates will not go beyond the proposals/features of the -//! W3C WebAssembly core 1.0 spec, which (as far as I can tell) is approximately -//! "the wasm MVP plus mutable globals". Mutable globals was proposed in 2018 -//! and made it in. -//! -//! See https://www.w3.org/TR/wasm-core-1/ -//! -//! Notably this feature-set _excludes_: -//! -//! - sign-extension operators -//! - non-trapping / saturating float-to-int conversions -//! - multi-value -//! - reference types -//! - bulk memory operations -//! - SIMD -//! -//! These are all listed as additions in the core 2.0 spec. Also they were all -//! proposed after 2020, and core 1.0 shipped in 2019. It also excludes even -//! later proposals such as: -//! -//! - exception handling -//! - tail calls -//! - extended consts -//! - function references -//! - multi-memory -//! - component model -//! - gc -//! - threads -//! - relaxed SIMD -//! - custom annotations -//! - branch hinting -//! +//! A "bare wasm" target representing a WebAssembly output that does not import +//! anything from its environment and also specifies an _upper_ bound on the set +//! of WebAssembly proposals that are supported. +//! +//! It's equivalent to the `wasm32-unknown-unknown` target with the additional +//! flags `-Ctarget-cpu=mvp` and `-Ctarget-feature=+mutable-globals`. This +//! enables just the features specified in +//! +//! This is a _separate target_ because using `wasm32-unknown-unknown` with +//! those target flags doesn't automatically rebuild libcore / liballoc with +//! them, and in order to get those libraries rebuilt you need to use the +//! nightly Rust feature `-Zbuild-std`. This target is for people who want to +//! use stable Rust, and target a stable set pf WebAssembly features. use crate::spec::{Cc, LinkerFlavor, Target, base}; @@ -57,6 +18,8 @@ pub(crate) fn target() -> Target { let mut options = base::wasm::options(); options.os = "none".into(); + // WebAssembly 1.0 shipped in 2019 and included exactly one proposal + // after the initial "MVP" feature set: "mutable-globals". options.cpu = "mvp".into(); options.features = "+mutable-globals".into(); diff --git a/src/ci/docker/host-x86_64/dist-various-2/Dockerfile b/src/ci/docker/host-x86_64/dist-various-2/Dockerfile index 410f0f92e60b6..8aabfaafbabbc 100644 --- a/src/ci/docker/host-x86_64/dist-various-2/Dockerfile +++ b/src/ci/docker/host-x86_64/dist-various-2/Dockerfile @@ -118,6 +118,7 @@ ENV TARGETS=$TARGETS,wasm32-wasi ENV TARGETS=$TARGETS,wasm32-wasip1 ENV TARGETS=$TARGETS,wasm32-wasip1-threads ENV TARGETS=$TARGETS,wasm32-wasip2 +ENV TARGETS=$TARGETS,wasm32v1-none ENV TARGETS=$TARGETS,sparcv9-sun-solaris ENV TARGETS=$TARGETS,x86_64-pc-solaris ENV TARGETS=$TARGETS,x86_64-unknown-linux-gnux32 diff --git a/src/doc/rustc/src/SUMMARY.md b/src/doc/rustc/src/SUMMARY.md index 795908b32c0ba..e05d9a40f00e3 100644 --- a/src/doc/rustc/src/SUMMARY.md +++ b/src/doc/rustc/src/SUMMARY.md @@ -86,6 +86,7 @@ - [wasm32-wasip2](platform-support/wasm32-wasip2.md) - [wasm32-unknown-emscripten](platform-support/wasm32-unknown-emscripten.md) - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) + - [wasm32v1-none](platform-support/wasm32v1-none.md) - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [\*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md) diff --git a/src/doc/rustc/src/platform-support.md b/src/doc/rustc/src/platform-support.md index e9c73ef1c2d83..5da03d26eb41b 100644 --- a/src/doc/rustc/src/platform-support.md +++ b/src/doc/rustc/src/platform-support.md @@ -195,6 +195,7 @@ target | std | notes `wasm32-wasi` | ✓ | WebAssembly with WASI (undergoing a [rename to `wasm32-wasip1`][wasi-rename]) [`wasm32-wasip1`](platform-support/wasm32-wasip1.md) | ✓ | WebAssembly with WASI [`wasm32-wasip1-threads`](platform-support/wasm32-wasip1-threads.md) | ✓ | WebAssembly with WASI Preview 1 and threads +[`wasm32v1-none`](platform-support/wasm32v1-none.md) | * | WebAssembly limited to 1.0 features and no imports [`x86_64-apple-ios`](platform-support/apple-ios.md) | ✓ | 64-bit x86 iOS [`x86_64-apple-ios-macabi`](platform-support/apple-ios-macabi.md) | ✓ | Mac Catalyst on x86_64 [`x86_64-fortanix-unknown-sgx`](platform-support/x86_64-fortanix-unknown-sgx.md) | ✓ | [Fortanix ABI] for 64-bit Intel SGX diff --git a/src/doc/rustc/src/platform-support/wasm32v1-none.md b/src/doc/rustc/src/platform-support/wasm32v1-none.md new file mode 100644 index 0000000000000..666f5e780d148 --- /dev/null +++ b/src/doc/rustc/src/platform-support/wasm32v1-none.md @@ -0,0 +1,109 @@ +# `wasm32v1-none` + +**Tier: 2** + +The `wasm32v1-none` target is a WebAssembly compilation target that: + +- Imports nothing from its host environment +- Enables no proposals / features past the [W3C WebAssembly Core 1.0 spec] + +[W3C WebAssembly Core 1.0 spec]: https://www.w3.org/TR/wasm-core-1/ + +The target is very similar to [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md) and similarly uses LLVM's `wasm32-unknown-unknown` backend target. It contains only three minor differences: + +* Setting the `target-cpu` to `mvp` rather than the default `generic`. Requesting `mvp` disables _all_ WebAssembly proposals / LLVM target feature flags. +* Enabling the [Import/Export of Mutable Globals] proposal (i.e. the `+mutable-globals` LLVM target feature flag) +* Not compiling the `std` library at all, rather than compiling it with stubs. + +[Import/Export of Mutable Globals]: https://github.com/WebAssembly/mutable-global + +## Target maintainers + +- Alex Crichton, https://github.com/alexcrichton +- Graydon Hoare, https://github.com/graydon + +## Requirements + +This target is cross-compiled. It does not support `std`, only `core` and `alloc`. Since it imports nothing from its environment, any `std` parts that use OS facilities would be stubbed out with functions-that-fail anyways, and the experience of working with the stub `std` in the `wasm32-unknown-unknown` target was deemed not something worth repeating here. + +Everything else about this target's requirements, building, usage and testing is the same as what's described in the [`wasm32-unknown-unknown` document](./wasm32-unknown-unknown.md), just using the target string `wasm32v1-none` in place of `wasm32-unknown-unknown`. + +## Conditionally compiling code + +It's recommended to conditionally compile code for this target with: + +```text +#[cfg(all(target_family = "wasm", target_os = "none"))] +``` + +Note that there is no way to tell via `#[cfg]` whether code will be running on +the web or not. + +## Enabled WebAssembly features + +As noted above, _no WebAssembly proposals past 1.0_ are enabled on this target by default. Indeed, the entire point of this target is to have a way to compile for a stable "no post-1.0 proposals" subset of WebAssembly _on stable Rust_. + +The [W3C WebAssembly Core 1.0 spec] was adopted as a W3C recommendation in December 2019, and includes exactly one "post-MVP" proposal: the [Import/Export of Mutable Globals] proposal. + +All subsequent proposals are _disabled_ on this target by default, though they can be individually enabled by passing LLVM target-feature flags. + +For reference sake, the set of proposals that LLVM supports at the time of writing, that this target _does not enable by default_, are listed here along with their LLVM target-feature flags: + +* Post-1.0 proposals (integrated into the WebAssembly core 2.0 spec): + * [Bulk memory] - `+bulk-memory` + * [Sign-extending operations] - `+sign-ext` + * [Non-trapping fp-to-int operations] - `+nontrapping-fptoint` + * [Multi-value] - `+multivalue` + * [Reference Types] - `+reference-types` + * [Fixed-width SIMD] - `+simd128` +* Post-2.0 proposals: + * [Threads] (supported by atomics) - `+atomics` + * [Exception handling] - `+exception-handling` + * [Extended Constant Expressions] - `+extended-const` + * [Half Precision] - `+half-precision` + * [Multiple memories]- `+multimemory` + * [Relaxed SIMD] - `+relaxed-simd` + * [Tail call] - `+tail-call` + +[Bulk memory]: https://github.com/WebAssembly/spec/blob/main/proposals/bulk-memory-operations/Overview.md +[Sign-extending operations]: https://github.com/WebAssembly/spec/blob/main/proposals/sign-extension-ops/Overview.md +[Non-trapping fp-to-int operations]: https://github.com/WebAssembly/spec/blob/main/proposals/nontrapping-float-to-int-conversion/Overview.md +[Multi-value]: https://github.com/WebAssembly/spec/blob/main/proposals/multi-value/Overview.md +[Reference Types]: https://github.com/WebAssembly/spec/blob/main/proposals/reference-types/Overview.md +[Fixed-width SIMD]: https://github.com/WebAssembly/spec/blob/main/proposals/simd/SIMD.md +[Threads]: https://github.com/webassembly/threads +[Exception handling]: https://github.com/WebAssembly/exception-handling +[Extended Constant Expressions]: https://github.com/WebAssembly/extended-const +[Half Precision]: https://github.com/WebAssembly/half-precision +[Multiple memories]: https://github.com/WebAssembly/multi-memory +[Relaxed SIMD]: https://github.com/WebAssembly/relaxed-simd +[Tail call]: https://github.com/WebAssembly/tail-call + +Additional proposals in the future are, of course, also not enabled by default. + +## Rationale relative to wasm32-unknown-unknown + +As noted in the [`wasm32-unknown-unknown` document](./wasm32-unknown-unknown.md), it is possible to compile with `-target wasm32-unknown-unknown` and disable all WebAssembly proposals "by hand", by passing `-Ctarget-cpu=mvp`. Furthermore one can enable proposals one by one by passing LLVM target feature flags, such as `-Ctarget-feature=+mutable-globals`. + +Is it therefore reasonable to wonder what the difference is between building with this: + +```sh +$ rustc -target wasm32-unknown-unknown -Ctarget-cpu=mvp -Ctarget-feature=+mutable-globals +``` + +and building with this: + +```sh +$ rustc -target wasm32v1-none +``` + +The difference is in how the `core` and `alloc` crates are compiled for distribution with the toolchain, and whether it works on _stable_ Rust toolchains or requires _nightly_ ones. Again referring back to the [`wasm32-unknown-unknown` document](./wasm32-unknown-unknown.md), note that to disable all post-MVP proposals on that target one _actually_ has to compile with this: + +```sh +$ export RUSTFLAGS="-Ctarget-cpu=mvp -Ctarget-feature=+mutable-globals" +$ cargo +nightly build -Zbuild-std=panic_abort,std -target wasm32-unknown-unknown +``` + +Which not only rebuilds `std`, `core` and `alloc` (which is somewhat costly and annoying) but more importantly requires the use of nightly Rust toolchains (for the `-Zbuild-std` flag). This is very undesirable for the target audience, which consists of people targeting WebAssembly implementations that prioritize stability, simplicity and/or security over feature support. + +This `wasm32v1-none` target exists as an alternative option that works on stable Rust toolchains, without rebuilding the stdlib. diff --git a/src/tools/build-manifest/src/main.rs b/src/tools/build-manifest/src/main.rs index 62e1695cbe362..925cbfe09a45a 100644 --- a/src/tools/build-manifest/src/main.rs +++ b/src/tools/build-manifest/src/main.rs @@ -161,6 +161,7 @@ static TARGETS: &[&str] = &[ "wasm32-wasip1", "wasm32-wasip1-threads", "wasm32-wasip2", + "wasm32v1-none", "x86_64-apple-darwin", "x86_64-apple-ios", "x86_64-apple-ios-macabi", From 3ba87498fa3349d63f622593ea7d722105059978 Mon Sep 17 00:00:00 2001 From: Graydon Hoare Date: Wed, 16 Oct 2024 18:56:43 -0700 Subject: [PATCH 3/4] Fix rustc_target test: wasmNN-none should support dynamic linking --- compiler/rustc_target/src/spec/tests/tests_impl.rs | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/compiler/rustc_target/src/spec/tests/tests_impl.rs b/compiler/rustc_target/src/spec/tests/tests_impl.rs index 7ed21954fba02..cc5931be860b3 100644 --- a/compiler/rustc_target/src/spec/tests/tests_impl.rs +++ b/compiler/rustc_target/src/spec/tests/tests_impl.rs @@ -121,7 +121,13 @@ impl Target { // Check dynamic linking stuff // BPF: when targeting user space vms (like rbpf), those can load dynamic libraries. // hexagon: when targeting QuRT, that OS can load dynamic libraries. - if self.os == "none" && (self.arch != "bpf" && self.arch != "hexagon") { + // wasm{32,64}: dynamic linking is inherent in the definition of the VM. + if self.os == "none" + && (self.arch != "bpf" + && self.arch != "hexagon" + && self.arch != "wasm32" + && self.arch != "wasm64") + { assert!(!self.dynamic_linking); } if self.only_cdylib From b0f02823fab05e9274131bbcaf9fe87366271888 Mon Sep 17 00:00:00 2001 From: Graydon Hoare Date: Tue, 22 Oct 2024 23:04:20 -0700 Subject: [PATCH 4/4] More review comments on wasm32v1-none target --- .../wasm32-unknown-unknown.md | 24 +++++++++++++------ .../src/platform-support/wasm32v1-none.md | 8 +++---- 2 files changed, 21 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc/src/platform-support/wasm32-unknown-unknown.md b/src/doc/rustc/src/platform-support/wasm32-unknown-unknown.md index 48a8df0c4a866..73264aba85809 100644 --- a/src/doc/rustc/src/platform-support/wasm32-unknown-unknown.md +++ b/src/doc/rustc/src/platform-support/wasm32-unknown-unknown.md @@ -132,10 +132,20 @@ As of the time of this writing the proposals that are enabled by default (the If you're compiling WebAssembly code for an engine that does not support a feature in LLVM's default feature set then the feature must be disabled at -compile time. Note, though, that enabled features may be used in the standard -library or precompiled libraries shipped via rustup. This means that not only -does your own code need to be compiled with the correct set of flags but the -Rust standard library additionally must be recompiled. +compile time. There are two approaches to choose from: + + - If you are targeting a feature set no smaller than the W3C WebAssembly Core + 1.0 recommendation -- which is equivalent to the WebAssembly MVP plus the + `mutable-globals` feature -- and you are building `no_std`, then you can + simply use the [`wasm32v1-none` target](./wasm32v1-none.md) instead of + `wasm32-unknown-unknown`, which uses only those minimal features and + includes a core and alloc library built with only those minimal features. + + - Otherwise -- if you need std, or if you need to target the ultra-minimal + "MVP" feature set, excluding `mutable-globals` -- you will need to manually + specify `-Ctarget-cpu=mvp` and also rebuild the stdlib using that target to + ensure no features are used in the stdlib. This in turn requires use of a + nightly compiler. Compiling all code for the initial release of WebAssembly looks like: @@ -150,9 +160,9 @@ then used to recompile the standard library in addition to your own code. This will produce a binary that uses only the original WebAssembly features by default and no proposals since its inception. -To enable individual features it can be done with `-Ctarget-feature=+foo`. -Available features for Rust code itself are documented in the [reference] and -can also be found through: +To enable individual features on either this target or `wasm32v1-none`, pass +arguments of the form `-Ctarget-feature=+foo`. Available features for Rust code +itself are documented in the [reference] and can also be found through: ```sh $ rustc -Ctarget-feature=help --target wasm32-unknown-unknown diff --git a/src/doc/rustc/src/platform-support/wasm32v1-none.md b/src/doc/rustc/src/platform-support/wasm32v1-none.md index 666f5e780d148..46f89c2011302 100644 --- a/src/doc/rustc/src/platform-support/wasm32v1-none.md +++ b/src/doc/rustc/src/platform-support/wasm32v1-none.md @@ -83,25 +83,25 @@ Additional proposals in the future are, of course, also not enabled by default. ## Rationale relative to wasm32-unknown-unknown -As noted in the [`wasm32-unknown-unknown` document](./wasm32-unknown-unknown.md), it is possible to compile with `-target wasm32-unknown-unknown` and disable all WebAssembly proposals "by hand", by passing `-Ctarget-cpu=mvp`. Furthermore one can enable proposals one by one by passing LLVM target feature flags, such as `-Ctarget-feature=+mutable-globals`. +As noted in the [`wasm32-unknown-unknown` document](./wasm32-unknown-unknown.md), it is possible to compile with `--target wasm32-unknown-unknown` and disable all WebAssembly proposals "by hand", by passing `-Ctarget-cpu=mvp`. Furthermore one can enable proposals one by one by passing LLVM target feature flags, such as `-Ctarget-feature=+mutable-globals`. Is it therefore reasonable to wonder what the difference is between building with this: ```sh -$ rustc -target wasm32-unknown-unknown -Ctarget-cpu=mvp -Ctarget-feature=+mutable-globals +$ rustc --target wasm32-unknown-unknown -Ctarget-cpu=mvp -Ctarget-feature=+mutable-globals ``` and building with this: ```sh -$ rustc -target wasm32v1-none +$ rustc --target wasm32v1-none ``` The difference is in how the `core` and `alloc` crates are compiled for distribution with the toolchain, and whether it works on _stable_ Rust toolchains or requires _nightly_ ones. Again referring back to the [`wasm32-unknown-unknown` document](./wasm32-unknown-unknown.md), note that to disable all post-MVP proposals on that target one _actually_ has to compile with this: ```sh $ export RUSTFLAGS="-Ctarget-cpu=mvp -Ctarget-feature=+mutable-globals" -$ cargo +nightly build -Zbuild-std=panic_abort,std -target wasm32-unknown-unknown +$ cargo +nightly build -Zbuild-std=panic_abort,std --target wasm32-unknown-unknown ``` Which not only rebuilds `std`, `core` and `alloc` (which is somewhat costly and annoying) but more importantly requires the use of nightly Rust toolchains (for the `-Zbuild-std` flag). This is very undesirable for the target audience, which consists of people targeting WebAssembly implementations that prioritize stability, simplicity and/or security over feature support.