New tier-2 target for wasm32-wasi-preview2

[yoshuawuyts]

Proposal

In 2019 the first version of the WASI spec was released (what we now call "WASI Preview 1"), and support was added to rustc as the tier-2 wasm32-wasi target. The folks working on WASI have iterated a lot on it since, resulting in major changes to the spec. Among other things, there is now a separate notion of "the component model", the way different WASI components bind to each other has changed, and WASI APIs are now defined in a new IDL language called wit ¹. This new version of the spec is called "WASI Preview 2", and is expected to be finalized later this year. It's also largely incompatible with the existing WASI Preview 1 spec.

Together with @sunfishcode and @alexcrichton I've been working to chart a path to support WASI Preview 2 in Rust. We believe the time for this is right, since the Preview 2 spec is nearly finalized, support in runtimes has begun (e.g. wasmtime), and there is industry demand for this (e.g. Fastly, Microsoft - our respective employers).

We want to be careful not to break existing users of Preview 1, so we believe the best way to add Preview 2 support is to introduce a new target triple: wasm32-wasi-preview2. By introducing a new triple we can gradually implement support for Preview 2, and we provide users of Preview 1 the opportunity to upgrade to Preview 2 at their own pace. The implementation of Preview 2 in rust-lang/rust should mostly touch the stdlib APIs. Packaging the compiler's output into WASI Preview 2-compatible components is something which we expect for the time being to remain handled through external tools such as cargo-component.

After the Preview 2 spec has been ratified, the plan by the WASI spec authors is to begin work on a Preview 3 version of the spec with first-class support for async primitives ². And once that's done, they expect to work towards a stable "WASI 1.0" release (presentation). To support WASI Preview 3 in Rust, we'll likely want to repeat the process for Preview 2: introduce a wasm32-wasi-preview3 triple, and then work to support that in the compiler and stdlib. To add WASI 1.0 support however, we'll likely want to reuse the existing wasm32-wasi target which is currently in use by WASI Preview 1. But that's at least several years out, and worth discussing in its own dedicated change proposal.

WASI Preview Target Sunset Policy

The WASI targets are currently in preview, and are intended to be deprecated once new preview targets are released. In order to facilitate transitioning from an older target to a newer target, we want there to be a transition window where both versions are available. The intent is that eventually a stable wasm32-wasi target will be introduced, which will replace the final WASI preview target.

When a replacement target is introduced, it will overlap with the previous target for 3 releases. After which the previous target can be removed by the compiler team. Exceptional circumstances may apply though, and there may be reasons why an older target may want to be kept for longer. But this needs to be raised by process of objection. The default expectation for the compiler team is, however, that once the period has elapsed the previous target can be deprecated.

The main exception to this will be the wasm32-wasi-preview1 target (née: wasm32-wasi). This target has been around for nearly four years at the time of writing, and will require an explicit decision by the compiler team to deprecate. The expectation, however, is that by this target will be deprecated by the time a potential wasm32-wasi-preview3 target is brought up for consideration.

Mentors or Reviewers

[tbd]

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.

Footnotes

1. For anyone interested in understanding these changes in more depth, see Luke Wagner's talk on the component model (YouTube) ↩

2. In terms of deltas, the difference between "Preview 1" and "Preview 2" is quite big because most of the primitives have been redesigned. In comparison: the difference between "Preview 2" and "Preview 3" should be relatively small; it adds support for "real" futures and streams on top of the Preview 2 model. And finally the difference between "Preview 3" and "1.0" should be even smaller than that; mostly serving as one last opportunity to fix whatever papercuts remain in Preview 3. ↩

[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.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[orangeC23]

Is preview2 still described using wit？

[jeffparsons]

Is preview2 still described using wit?

Yep. The component model, on top of which WASI builds, uses the wit format to describe interfaces. (I.e. no more witx, and wit is now on a standards track.)

[yoshuawuyts]

Based on feedback from Zulip I've added a "WASI Preview Target Sunset Policy" section to the issue text.

[wesleywiser]

@rustbot second

[apiraino]

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