Wasm Proposals

This document is intended to describe the current status of WebAssembly proposals in Wasmtime. For information about implementing a proposal in Wasmtime see the associated documentation.

WebAssembly proposals that want to be tier 2 or above are required to check all boxes in this matrix. An explanation of each matrix column is below.

On-by-default proposals

Proposal	Phase 4	Tests	Finished	Fuzzed	API	C API
`mutable-globals`	✅	✅	✅	✅	✅	✅
`sign-extension-ops`	✅	✅	✅	✅	✅	✅
`nontrapping-fptoint`	✅	✅	✅	✅	✅	✅
`multi-value`	✅	✅	✅	✅	✅	✅
`bulk-memory`	✅	✅	✅	✅	✅	✅
`reference-types`	✅	✅	✅	✅	✅	✅
`simd`	✅	✅	✅	✅	✅	✅
`component-model`	❌¹	✅	✅	⚠️²	✅	❌³
`relaxed-simd`	✅	✅	✅	✅	✅	✅
`multi-memory`	✅	✅	✅	✅	✅	✅
`threads`	✅	✅	✅⁴	❌⁵	✅	✅
`tail-call`	✅	✅	✅	✅	✅	✅
`extended-const`	✅	✅	✅	✅	✅	✅

The component-model proposal is not at phase 4 in the standardization process but it is still enabled-by-default in Wasmtime.

Various shapes of components are fuzzed but full-on fuzzing along the lines of wasm-smith are not implemented for components.

⁵

Fuzzing with threads is an open implementation question that is expected to get fleshed out as the shared-everything-threads proposal advances.

Support for the C API for components is desired by many embedders but does not currently have anyone lined up to implement it.

⁴

There are known issues with shared memories and the implementation/API in Wasmtime, for example they aren't well integrated with resource-limiting features in Store. Additionally shared memories aren't supported in the pooling allocator.

Off-by-default proposals

Proposal	Phase 4	Tests	Finished	Fuzzed	API	C API
`memory64`	❌	✅	✅	✅	✅	✅
`function-references`	✅	✅	❌	❌	✅	❌
`gc` ⁶	✅	✅	❌⁷	❌	✅	❌
`wide-arithmetic`	❌	✅	✅	✅	✅	✅
`custom-page-sizes`	❌	✅	✅	✅	✅	❌

⁶

There is also a tracking issue for the GC proposal.

⁷

The implementation of GC has known performance issues which can affect non-GC code when the GC proposal is enabled.

Unimplemented proposals

Proposal	Tracking Issue
`branch-hinting`	#9463
`exception-handling`	#3427
`flexible-vectors`	#9464
`memory-control`	#9467
`stack-switching`	#9465
`shared-everything-threads`	#9466

Feature requirements

For each column in the above tables, this is a further explanation of its meaning:

Phase 4 - The proposal must be in phase 4, or greater, of the WebAssembly standardization process.
Tests - All spec tests must be passing in Wasmtime and where appropriate Wasmtime-specific tests, for example for the API, should be passing. Tests must pass at least for Cranelift on all tier 1 platforms, but missing other platforms is otherwise acceptable.
Finished - No open questions, design concerns, or serious known bugs. The implementation should be complete to the extent that is possible. Support must be implemented for all tier 1 targets and compiler backends.
Fuzzed - Has been fuzzed for at least a week minimum. We are also confident that the fuzzers are fully exercising the proposal's functionality. The module_generation_uses_expected_proposals test in the wasmtime-fuzzing crate must be updated to include this proposal.

For example, it would not have been enough to simply enable reference types in the compile fuzz target to enable that proposal by default. Compiling a module that uses reference types but not instantiating it nor running any of its functions doesn't exercise any of the GC implementation and does not run the inline fast paths for table operations emitted by the JIT. Exercising these things was the motivation for writing the custom fuzz target for table.{get,set} instructions.

One indication of the status of fuzzing is this file which controls module configuration during fuzzing.
API - The proposal's functionality is exposed in the wasmtime crate's API. At minimum this is Config::wasm_the_proposal but proposals such as gc also add new types to the API.
C API - The proposal's functionality is exposed in the C API.