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.

[alexcrichton]

Thanks for this! Personally though I'd probably leave it mostly up to you as to how best to chunk up this work and land it. The 0.3 bits may take a bit to land so if you can avoid depending on that it might make sense, although if it is likely to heavily conflict with @dicej's work we might want to strategize in the near term.

Otherwise though I find it difficult to predict how to split up "unknown code" in the sense that I haven't reviewed this yet so having an opinion on how best to chunk it up would need a review/understanding on my behalf first, so this is also why I'll trust to you break it up since that makes the review load easier too :)

[sunfishcode]

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)

Is "symmetric C++ API" related to the symmmetric ABI? If so, then see my comments below about the symmetric ABI. And for the async parts, see my comments below about async :-).

C++ host support (WAMR, stale)

As discussed in #395, host support no longer lives in the wit-bindgen repository, so this would make sense to split out, either into wamr itself or a separate repo somewhere. See this section for a discussion of what other hosts are doing.

(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

What would you think about factoring these changes out to live in their own repository? Native ABI interfaces sound like they have some similar needs to cool projects like wRPC, wasm-http-tools, and hopefully more such tools coming, which live in separate repositories, sharing factored-out building blocks like wit-parser.

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)

I think the main thing to do here rhg tnow is to just avoid creating more work for Joel, which I expect means waiting on any changes that would depend on these parts for now.

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

This would be useful to a lot of people, so if you're looking for pieces to prioritize here, this is my suggestion :-).