Draft: Planning for merging some important parts of my fork upstream

[cpetig]

My fork has aggregated several potentially separable parts over the past years.

I would like to come up with a plan to incrementally merge in interest order, so I would love to get feed-back about which features are most wanted/urgent to separate them in the most efficient way. Perhaps we want to merge Joel's work first to minimize friction on his work/merge.

• C++ guest support C++ language support #826
  • symmetric C++ API (I think the old one is horrible to understand, because move semantic for arguments is alien to C++)
  • planned: C++ WASI 0.3 async (painful because concurrency TS (continuation) isn't standard and shared everything threads are too far off)
• C++ host support (WAMR, stale)
• (outdated?) Canonical ABI compiled to native (mesh, see https://wasmcon24.sched.com/event/1qvIG slide 40)
• shared everything symmetric ABI Symmetrical ABI for component fusion and shared everything WebAssembly/component-model#386
  • 64bit compatible code generation (offset + alignment)
  • wasm2c bridging support, see wasmcon slide 55
• Joel's work on async (WASI 0.3), identical to Add support for async/streams/futures to Rust generator #1082
  • planned: async WASI 0.3 with symmetric ABI (PoC exists)
• planned: Caller provided buffers Caller provided buffers question WebAssembly/component-model#369

Some of these features are unfinished but given enough interest I clearly want to make them upstreamable.

[gkgoat1]

My fork has aggregated several potentially separable parts over the past years.

I would like to come up with a plan to incrementally merge in interest order, so I would love to get feed-back about which features are most wanted/urgent to separate them in the most efficient way. Perhaps we want to merge Joel's work first to minimize friction on his work/merge.

• C++ guest support C++ language support #826

  • symmetric C++ API (I think the old one is horrible to understand, because move semantic for arguments is alien to C++)
  • planned: C++ WASI 0.3 async (painful because concurrency TS (continuation) isn't standard and shared everything threads are too far off)

• C++ host support (WAMR, stale)

• (outdated?) Canonical ABI compiled to native (mesh, see https://wasmcon24.sched.com/event/1qvIG slide 40)

• shared everything symmetric ABI Symmetrical ABI for component fusion and shared everything WebAssembly/component-model#386

  • 64bit compatible code generation (offset + alignment)
  • wasm2c bridging support, see wasmcon slide 55

That sort of tool, a component compiler, is a blocker for component model support in my projects, which could support WIT-using core modules but cannot handle the intracies of the component model's format. I have, given existing tools, created many issues for using them to compile components, though their methods also turn out just as compilcated.

• Joel's work on async (WASI 0.3), identical to Add support for async/streams/futures to Rust generator #1082

  • planned: async WASI 0.3 with symmetric ABI (PoC exists)

• planned: Caller provided buffers Caller provided buffers question WebAssembly/component-model#369

Some of these features are unfinished but given enough interest I clearly want to make them upstreamable.