rustbot
commented
1 month ago This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:
@rustbot concern reason-for-concern
<description of the concern> Concerns can be lifted with:
@rustbot resolve reason-for-concern See documentation at https://forge.rust-lang.org
cc @rust-lang/compiler @rust-lang/compiler-contributors
jieyouxu
apiraino
Proposal
To define a new target that is a variant of
wasm32v1-nonethat specifies a small and fixed set of wasm proposals rather than the open-ended (and growing) set currently implied.Currently the evolution of the wasm32-* target(s) is favouring the audience of users who want ever-expanding sets of software to run on wasm. So as wasm features become widely supported, the default set of features enabled in rustc expands. This is understandable given that main audience but it neglects the interests of a different audience, who are aiming to develop minimal, stable, and security-focused implementations. Each new feature that gets enabled in rust's default wasm targets imposes an implementation burden on wasm engines as well as requiring field upgrades of software embedding them in order to keep consuming code produced by stable rustc.
Implementations targeting small / embedded environments, or with limited implementation resources, currently have to resort to getting their target software built with
+nightly -Ctarget-cpu=mvp -Ctarget-features=+mutable-globals -Zbuild-stdin order to get a minimal profile of wasm. It would be nice not to require that: build-std adds overhead to every build, and more significantly nightly requires users to sacrifice the stability guarantees of rust's stable channel, when stability is exactly what this audience desires.If a new target is agreeable, I think there are three main details to hash out:
mutable-globalsmade it into 1.0, andbulk-memory,nontrapping-fptointandsign-extmade it into 2.0. LLVM recognizes "mvp" as a CPU string as well as "bleeding-edge" and "generic". The latter includessign-extandmutable-globalsand does not, I think, correspond precisely to any spec. So I think if we're targeting v1, that makes "-Ctarget-cpu=mvp -Ctarget-features=+mutable-globals".wasm32v1-none(as an abbreviation of the more-formally-correct but annoyingly-verbosewasm32v1-unknown-none-- assuming nobody's ever going to identify a specific wasm target vendor).std, given thatstdis almost entirely non-functional stubs on wasm32-unknown-unknown (no wasi). Zulip consensus seems to be "don't build std". Hence "none" for the -sys component.Since this is a fairly trivial change, I just went ahead and sketched it. It seems to work: https://github.com/rust-lang/rust/pull/131487
Mentors or Reviewers
I suspect @alexcrichton is most likely interested in review, but I could be wrong!
Process
The main points of the Major Change Process are as follows:
@rustbot second.-C flag, then full team check-off is required.@rfcbot fcp mergeon either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.