Wasm minimal features target

[graydon]

Proposal

To define a new target that is a variant of wasm32v1-none that 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-std in 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:

1. Which features to enable. In discussion with @alexcrichton and @fitzgen both suggested targeting 1.0 rather than mvp, mostly because 1.0 is more-explicitly specified. The differences are minimal, though it's a little tricky to tell which is which. From what I can tell only mutable-globals made it into 1.0, and bulk-memory, nontrapping-fptoint and sign-ext made it into 2.0. LLVM recognizes "mvp" as a CPU string as well as "bleeding-edge" and "generic". The latter includes sign-ext and mutable-globals and 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".
2. What to call it. We discussed in Zulip and came up with wasm32v1-none (as an abbreviation of the more-formally-correct but annoyingly-verbose wasm32v1-unknown-none -- assuming nobody's ever going to identify a specific wasm target vendor).
3. What to do about std, given that std is 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: rust-lang/rust#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:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

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.

[rustbot]

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]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted