Add support for async/streams/futures to Rust generator

[dicej]

This adds support for generating bindings which use the Async ABI along with the stream, future, and
error-context types.

By default, normal synchronous bindings are generated, but the user may opt-in to async bindings for all or some of the imported and/or exported functions in the target world and interfaces -- provided the default-enabled async feature is enabled.

In addition, we generate StreamPayload and/or FuturePayload trait implementations for any types appearing as the T in stream<T> or future<T> in the WIT files, respectively. That enables user code to call new_stream or new_future to create streams or futures with those payload types, then write to them, read from them, and/or pass the readable end as a parameter to a component import or return value of a component export.

Note that I've added new core::abi::Instruction enum variants to handle async lifting and lowering, but they're currently tailored to the Rust generator and will probably change somewhat as we add support for other languages.

This does not include any new tests; I'll add those in a follow-up commit.

This is ready for review, but I'll leave it in draft mode until the following are complete:

• Codegen test coverage for new features in the Rust generator
• Switch to upstream wasm-tools once Add support for async ABI, futures, streams, and errors wasm-tools#1895 is merged and released
• Runtime test coverage for new features in the Rust generator. I've opened Add runtime tests for Rust generator for async/futures/streams #1093 to track this separately.

[alexcrichton]

Thanks again for this! I didn't dive too too deep into the implementation guts since I think that'll be best to shake out over time, but I left some comments about higher-level structure and where this touches other parts. Overall looks grat to me 👍

[dicej]

Thanks for the review, @alexcrichton. I believe I've addressed everything so far with either explanations or code changes.

[cpetig]

One thing which keeps me wondering is the asymmetry between argument passing of imported vs exported async functions. Imported functions pass a pointer to an argument buffer in memory, freed by the callee (host) while exported functions receive all arguments in line (on the argument stack).

Historically both directions used a buffer, but I wonder whether there is a good enough reason for the import still passing via a buffer - the host should have enough resources to remember all arguments in case of back-pressure and this could optimize the imported function call for few arguments (or e.g. a string/list) considerably.

[dicej]

One thing which keeps me wondering is the asymmetry between argument passing of imported vs exported async functions.

As you mentioned, I think the main motivation is backpressure.

the host should have enough resources to remember all arguments in case of back-pressure

I don't know if that's necessarily true; we could be dealing with arbitrarily large and arbitrarily nested lists, for example, which the host would need to copy into its own memory, hold there indefinitely, and then copy to the callee once the backpressure clears. Generating fused adapters for that scenario sounds tough, and if we don't generate adapters then we'll need to fall back to the slow dynamic path in the host since we can't use the static lift and lower APIs for component->component calls in general. EDIT: or not; see my next comment.

In any case, https://github.com/WebAssembly/component-model is probably a better place to discuss this kind of thing.

[dicej]

I don't know if that's necessarily true; we could be dealing with arbitrarily large and arbitrarily nested lists, for example, which the host would need to copy into its own memory, hold there indefinitely, and then copy to the callee once the backpressure clears.

Responding to myself: I suppose we wouldn't need to copy everything -- just up to MAX_FLAT_PARAMS -- assuming the caller knows not to free any allocated memory those params point to until it receives a STARTED event for the call.

[cpetig]

I don't know if that's necessarily true; we could be dealing with arbitrarily large and arbitrarily nested lists, for example, which the host would need to copy into its own memory, hold there indefinitely, and then copy to the callee once the backpressure clears.

Responding to myself: I suppose we wouldn't need to copy everything -- just up to MAX_FLAT_PARAMS -- assuming the caller knows not to free any allocated memory those params point to until it receives a STARTED event for the call.

But the extra arguments would likely be passed on the linear stack, and thus returning from the function doing the call would destroy this data.

Your answer clearly indicated that this has been discussed in depth before and isn't an oversight. So I will close this thread. Edit: Not necessary on github it seems.

[dicej]

Your answer clearly indicated that this has been discussed in depth before and isn't an oversight. So I will close this thread.

Correct that it's not an oversight, but there may also be room for improvement, so definitely consider opening an issue on the component-model repo if you think there might be more to discuss.

FWIW, when Luke and I last discussed this, the vision was to make deferring tasks based on backpressure as efficient as possible in the host, e.g. O(1), without any allocations or copies at all, simply by (re)connecting tasks together in a linked list configuration. Any overhead we add to that would need to be justified, but it's not out of the question -- especially if it helps us optimize other, more common scenarios.

[alexcrichton]

👍 looks great to me!