Tracking issue for implementing the component model

[alexcrichton]

This is intended to be a tracking issue for the implementation of the component model proposal of WebAssembly. I'm in the progress of implementing this with work in Wasmtime starting at https://github.com/bytecodealliance/wasmtime/pull/4005 and continuing in further PRs. I hope to leave checkbox items here to ensure I don't forget about them and to also track the progress of implementing the component model.

Items to be implemented

• [x] Text format parsing
• [x] Validation in wasmparser
• [x] Basic infrastructure in the component submodule of the wasmtime crate
• [x] Basic instantiation with zero imports
• [x] Extracting a function and calling it with a static signature
• [x] Importing host functions into a component
• [x] Importing host instances (bundles of host functions) into a component
• [x] Importing a wasm module into a component
• [x] Exporting a module from a component
• [x] Nested component compilation
• [x] Nested component instantiation
• [x] Outer component aliases
• [x] Exporting a component from a component
• [x] Confirm lowered-then-lifted interpretation of "always trap" is correct
• [x] Split ComponentValue into lifting and lowering traits
• [x] Implement may_enter and may_leave flags
• [x] Post-return functions
• [x] Validate alignment and enable &[u64] views and similar
• [x] Figure out what to do with lowering a lifted function
• [x] ~~Double-check behavior of traps with respect to validating in-bounds pointers and intermediate writes of params/results when lifting/lowering~~ given the "trap lock" I don't think that this matters
• [x] Figure out what to do with a lifting a lowered function
• [x] Figure out what to do with reexporting an imported function
• [x] Implement a "lock" for instances for when a trap happens (https://github.com/WebAssembly/component-model/issues/55)
• [x] Exporting a component instance from the root of a component
• [x] Fill out unimplemented! for outer core aliases
• [x] Component-to-component adapters (this is a huge work item implying an entire compiler for adapter trampolines)
• [x] Fix support for zero-sized flags.
• [x] Fix support for zero-sized lists/strings/types
• [x] Update support for multi-return, unit, etc.
• [x] Implement embedder support for multi-return (in the wasmtime crate API)
• [ ] Implement new reentrance rules

Separate work items

I'm starting to separate off work items from this issue to separate tracking issues with more detail. These will all need completion to finish the component model work but these issues are suitable to be picked up by anyone in theory.

• [x] Support for record, variant, enum, union, flags
• [x] Calling a function with a dynamic signature
• [x] Fuzzing for round-tripping component values
• [x] String support for utf16+latin1 (omitted from #4039)
• [x] Deduplicate size/align calculations
• [x] Support AOT compilation of components
• [ ] Support creation of function types
• [ ] Implement type reflection for imports/exports
• [ ] Support 64-bit memories for components
• [ ] Audit adapter trampolines to ensure that out-of-bounds pointers have correct semantics, especially when calling helper functions for translations of types in memory.
• [ ] Change how components interact with the pooling instance allocator

Unsure how to implement so far

• Everything with value ranging from imports to exports to the start function
• Type imports
• Unsure how to rationalize performance concerns with validating indirect values like lists from wasm coming to the host when balanced with spec-desired behavior of validating everything.

Open questions

• How to optimize passing &[u8] to WebAssembly to a memcpy?
• ~~How to handle validation of Value<T> coming out of wasm?~~

Not planned at this time

• Importing component-defined functions into a component without any extra copies to the host
• Importing component instances directly into other components
• Importing a component or exporting a component at the root level
• Reexporting an imported function from a component and expecting it to work.

[Jeffwan]

Hi, do we have a rough estimate on the component-model release? I am trying to understand even there's some pending items, is it working now? Is there a quickstart guidance on the usage?

[alexcrichton]

There's no esimate at this time. Some parts work but not all, the un-finished issues above should give an idea of how much is left to do. No documentation on usage yet.

[pannous]

Once all the boxes are checked don't forget a 'hello component' minimal example.

[bobby]

Hey @alexcrichton, what's the relationship of this issue with #6370? Are you still actively tracking issues here, or is the state of landing WASI preview 2 support a better proxy for component model progress in wasmtime?

[pchickey]

It depends on why you need to know.

If you are trying to contribute to the component model or WASI design and implementation, they are separate standards where WASI builds on the component model, but only using the pieces that are complete in this list. For example, now that component model resources are complete here in wasmtime and are nearing completion out in wit-bindgen and other tools, we'll be swapping out our u32 placeholders for proper resources in WASI shortly.

If you are just looking to write or embed components, you want both the component model and WASI to be stable: right now their definitions are still in flux, and wasmtime's implementations may not even match the spec definitions. We intend to stabilize both of those, in both spec and implementation, as Preview 2 later this year. The full set of implementation work required to finish Preview 2 isn't captured anywhere right now, but we do have a rough plan on the spec side: https://github.com/WebAssembly/WASI/pull/550

[alexcrichton]

I'll add to what @pchickey said already and note that this issue has I think outlived its usefulness. At this time all major efforts for implementing the component model have finished except for the never-ending continued polish in addition to the preview2 implementation (which involves shaping and stabilizing preview2 as well).

In light of that I'm going to go ahead and close this as the component model implementation in Wasmtime is more-or-less complete (with usefulness coming with other preview2-related things). Any follow-ups and remaining items should be opened as separate issues at this point for separate discussion.