Generated guest export bindings are insufficient to call concurrent functions

[rvolosatovs]

Since #11238 has been merged, calling an async export requires an Accessor, however, the only way to get an Accessor is to use an Instance.

Users relying uniquely on generated instantiate_async bindings do not have access to one and so can never call the async export.

Steps to Reproduce

• checkout feat: begin wasip3 implementation #11221
• cargo doc -p wasmtime-wasi --features p3 --open --document-private-items
• take a look at docs generated for target/doc/wasmtime_wasi/p3/bindings/struct.Command.html

Expected Results

Either a way to run an export without manual instantiation or removal of these bindings

Actual Results

"dead end" from user's perspective with seemingly no way of constructing an Accessor using the public API

Versions and Environment

Wasmtime version or commit: 326795f (latest main)

Operating system: MacOS

Architecture: aarch64-darwin

Extra Info

Without changing wasmtime API, there seem to be two ways to fix this issue:

• return a tuple from instantiate_async e.g. (Command, Instance) (and similar for other worlds)
• simply remove the instantiate_async generated functions and require users to always instantiate manually and rely on Command::new (and similar for other worlds)

[alexcrichton]

In the limit this will be resolved by #11226 because you won't need an instance to acquire an accessor, you can instead acquire that from the store. Until that point though is it ok to use the instance and less-nice auto-generated bindings as a workaround?

[rvolosatovs]

In the limit this will be resolved by #11226 because you won't need an instance to acquire an accessor, you can instead acquire that from the store. Until that point though is it ok to use the instance and less-nice auto-generated bindings as a workaround?

Sounds good to me!