1# Wasm Proposals 2 3This document is intended to describe the current status of WebAssembly 4proposals in Wasmtime. For information about implementing a proposal in Wasmtime 5see the [associated 6documentation](./contributing-implementing-wasm-proposals.md). 7 8WebAssembly proposals that want to be [tier 1](./stability-tiers.md) 9are required to check all boxes in this matrix. An explanation of each matrix 10column is below. 11 12The emoji legend is: 13 14* ✅ - fully supported 15* �� - work-in-progress 16* ❌ - not supported yet 17 18## Tier 1 WebAssembly Proposals 19 20| Proposal | Phase 4 | Tests | Finished | Fuzzed | API | C API | 21|--------------------------|---------|-------|----------|--------|-----|-------| 22| [`mutable-globals`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 23| [`sign-extension-ops`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 24| [`nontrapping-fptoint`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 25| [`multi-value`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 26| [`bulk-memory`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 27| [`reference-types`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 28| [`simd`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 29| [`component-model`] | ❌[^1] | ✅ | ✅ | ��[^2] | ✅ | ��[^3]| 30| [`relaxed-simd`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 31| [`multi-memory`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 32| [`tail-call`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 33| [`extended-const`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 34| [`memory64`] | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 35 36[^1]: The `component-model` proposal is not at phase 4 in the standardization 37 process but it is still enabled-by-default in Wasmtime. 38[^2]: Various shapes of components are fuzzed but full-on fuzzing along the 39 lines of `wasm-smith` are not implemented for components. 40[^3]: The component model is mostly supported in the C API but [gaps 41 remain][cm-capi-gaps]. 42 43[cm-capi-gaps]: https://github.com/bytecodealliance/wasmtime/issues?q=is%3Aissue%20state%3Aopen%20label%3Awasm-proposal%3Acomponent-model%20label%3Awasmtime%3Ac-api 44 45## Tier 2 WebAssembly Proposals 46 47| Proposal | Phase 4 | Tests | Finished | Fuzzed | API | C API | 48|--------------------------|---------|-------|----------|--------|-----|--------| 49| [`custom-page-sizes`] | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | 50| [`exception-handling`] | ✅ | ✅ | ✅ | ��[^9] | ✅ | ��[^10]| 51| [`function-references`] | ✅ | ✅ | ✅ | �� | ✅ | ❌ | 52| [`gc`] [^5] | ✅ | ✅ | ��[^6] | ��[^7] | ✅ | ❌ | 53| [`threads`] | ✅ | ✅ | ��[^8] | ❌[^4] | ✅ | ✅ | 54| [`wide-arithmetic`] | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | 55 56[^4]: Fuzzing with threads is an open implementation question that is expected 57 to get fleshed out as the [`shared-everything-threads`] proposal advances. 58[^5]: There is also a [tracking 59 issue](https://github.com/bytecodealliance/wasmtime/issues/5032) for the 60 GC proposal. 61[^6]: The implementation of Wasm GC is feature complete from a specification 62 perspective, however a number of quality-of-implementation tasks 63 [remain](https://github.com/bytecodealliance/wasmtime/issues/5032), notably 64 a tracing collector that can reclaim garbage cycles. 65[^7]: The GC proposal is lightly fuzzed via `wasm-smith` and our usual 66 whole-module fuzz targets like `differential`, but we would like to 67 additionally [extend the `table_ops` fuzz target to exercise more of the GC 68 proposal](https://github.com/bytecodealliance/wasmtime/issues/10327). 69[^8]: There are [known 70 issues](https://github.com/bytecodealliance/wasmtime/issues/4245) with 71 shared memories and the implementation/API in Wasmtime, for example they 72 aren't well integrated with resource-limiting features in `Store`. 73 Additionally `shared` memories aren't supported in the pooling allocator. 74[^9]: The exception-handling proposal is fuzzed by our whole-module fuzzer, 75 but we do not have an exception-specific fuzzer that attempts to create 76 interesting throw/catch patterns or payloads. 77[^10]: The exception-handling proposal can be enabled for exceptions in the guest 78 via the C API, but exception objects have no C API to examine, clone, 79 rethrow, or drop exceptions that propagate to the host. 80 81[cm-capi-gaps]: https://github.com/bytecodealliance/wasmtime/issues?q=is%3Aissue%20state%3Aopen%20label%3Awasm-proposal%3Acomponent-model%20label%3Awasmtime%3Ac-api 82 83## Tier 3 WebAssembly Proposals 84 85| Proposal | Phase 4 | Tests | Finished | Fuzzed | API | C API | 86|-----------------------------|---------|-------|----------|--------|-----|-------| 87| [`stack-switching`] [^11] | ❌ | �� | �� | ❌ | ❌ | ❌ | 88 89[^11]: The stack-switching proposal is a work-in-progress being tracked 90 at [#9465](https://github.com/bytecodealliance/wasmtime/issues/9465). 91 Currently the implementation is only for x86\_64 Linux. 92 93## Unimplemented proposals 94 95| Proposal | Tracking Issue | 96|-------------------------------|----------------| 97| [`branch-hinting`] | [#9463](https://github.com/bytecodealliance/wasmtime/issues/9463) | 98| [`flexible-vectors`] | [#9464](https://github.com/bytecodealliance/wasmtime/issues/9464) | 99| [`memory-control`] | [#9467](https://github.com/bytecodealliance/wasmtime/issues/9467) | 100| [`shared-everything-threads`] | [#9466](https://github.com/bytecodealliance/wasmtime/issues/9466) | 101 102[`mutable-globals`]: https://github.com/WebAssembly/mutable-global/blob/master/proposals/mutable-global/Overview.md 103[`sign-extension-ops`]: https://github.com/WebAssembly/spec/blob/master/proposals/sign-extension-ops/Overview.md 104[`nontrapping-fptoint`]: https://github.com/WebAssembly/spec/blob/master/proposals/nontrapping-float-to-int-conversion/Overview.md 105[`multi-value`]: https://github.com/WebAssembly/spec/blob/master/proposals/multi-value/Overview.md 106[`bulk-memory`]: https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md 107[`reference-types`]: https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md 108[`simd`]: https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md 109[`tail-call`]: https://github.com/WebAssembly/tail-call/blob/main/proposals/tail-call/Overview.md 110[`branch-hinting`]: https://github.com/WebAssembly/branch-hinting 111[`exception-handling`]: https://github.com/WebAssembly/exception-handling 112[`extended-const`]: https://github.com/WebAssembly/extended-const 113[`flexible-vectors`]: https://github.com/WebAssembly/flexible-vectors 114[`memory-control`]: https://github.com/WebAssembly/memory-control 115[`stack-switching`]: https://github.com/WebAssembly/stack-switching 116[`shared-everything-threads`]: https://github.com/WebAssembly/shared-everything-threads 117[`memory64`]: https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md 118[`multi-memory`]: https://github.com/WebAssembly/multi-memory/blob/master/proposals/multi-memory/Overview.md 119[`threads`]: https://github.com/WebAssembly/threads 120[`component-model`]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md 121[`relaxed-simd`]: https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md 122[`function-references`]: https://github.com/WebAssembly/function-references/blob/main/proposals/function-references/Overview.md 123[`wide-arithmetic`]: https://github.com/WebAssembly/wide-arithmetic/blob/main/proposals/wide-arithmetic/Overview.md 124[`gc`]: https://github.com/WebAssembly/gc 125[`custom-page-sizes`]: https://github.com/WebAssembly/custom-page-sizes 126 127## Feature requirements 128 129For each column in the above tables, this is a further explanation of its meaning: 130 131* **Phase 4** - The proposal must be in phase 4, or greater, of [the 132 WebAssembly standardization process][phases]. 133 134* **Tests** - All spec tests must be passing in Wasmtime and where appropriate 135 Wasmtime-specific tests, for example for the API, should be passing. Tests 136 must pass at least for Cranelift on all [tier 1](./stability-tiers.md) 137 platforms, but missing other platforms is otherwise acceptable. 138 139* **Finished** - No open questions, design concerns, or serious known bugs. The 140 implementation should be complete to the extent that is possible. Support 141 must be implemented for all [tier 1](./stability-tiers.md) targets and 142 compiler backends. 143 144* **Fuzzed** - Has been fuzzed for at least a week minimum. We are also 145 confident that the fuzzers are fully exercising the proposal's functionality. 146 The `module_generation_uses_expected_proposals` test in the `wasmtime-fuzzing` 147 crate must be updated to include this proposal. 148 149 > For example, it would *not* have been enough to simply enable reference 150 > types in the `compile` fuzz target to enable that proposal by 151 > default. Compiling a module that uses reference types but not instantiating 152 > it nor running any of its functions doesn't exercise any of the GC 153 > implementation and does not run the inline fast paths for `table` operations 154 > emitted by the JIT. Exercising these things was the motivation for writing 155 > the custom fuzz target for `table.{get,set}` instructions. 156 157 One indication of the status of fuzzing is [this 158 file](https://github.com/bytecodealliance/wasmtime/blob/main/crates/fuzzing/src/generators/module.rs#L16) 159 which controls module configuration during fuzzing. 160 161* **API** - The proposal's functionality is exposed in the `wasmtime` crate's 162 API. At minimum this is `Config::wasm_the_proposal` but proposals such as 163 [`gc`] also add new types to the API. 164 165* **C API** - The proposal's functionality is exposed in the C API. 166 167* **Enabled** - Whether or not this feature is on-by-default. Off-by-default 168 features require an opt-in on the CLI or via the embedding API to use, but 169 on-by-default features require no explicit action to use the feature. 170 171[phases]: https://github.com/WebAssembly/meetings/blob/master/process/phases.md 172