Milestone plan for implementing the Wasm GC specification.
(borrowed from https://docs.wasmtime.dev/contributing-implementing-wasm-proposals.html)
The following checkboxes enumerate the steps required to add support for a new WebAssembly proposal to Wasmtime. They can be completed over the course of multiple pull requests.
wat
and wast
crates: it's already there!wasmparser
crate.wasmprinter
crate.wasm-encoder
crate.wasm-smith
crate (this can be done in parallel with adding code to wasmtime
).wasmtime::Config::enable_gc
method to the wasmtime
crate.--enable-gc
command line flag to the wasmtime
binary.build.rs
but mark them as ignored for now.The
wast2json
tool from [WABT] is useful for this.
For example, we wrote a custom generator, oracle, and fuzz target for exercising
table.{get,set}
instructions and their interaction with GC while implementing the reference types proposal.
wasmtime
crate's API.
For example, the bulk memory operations proposal introduced a
table.copy
instruction, and we exposed its functionality as thewasmtime::Table::copy
method.
This may require extensions to the standard C API, and if so, should be defined in
wasmtime.h
and prefixed withwasmtime_
.
wasmtime/docs/stability-wasm-proposals-support.md
.These are the standards that must be met to enable support for a proposal by default in Wasmtime, and can be used as a review checklist.
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 fortable
operations emitted by the JIT. Exercising these things was the motivation for writing the custom fuzz target fortable.{get,set}
instructions.
wasmtime
crate's API.