bytecodealliance
Import stubs for native targets
Currently, rust bindgen inserts stubs for Wasm imports on native targets, which simply panic.
I'd like to discuss possibilities for making this configurable or perhaps define a convention of some sorts?
My exact use case is as follows:
At wasmCloud we've developed https://github.com/wasmCloud/wadge, which lets components be tested as native applications - for Go, it works by replacing each function with a wasmimport directive, generated by upstream bindgen, by an implementation, which calls an export on a component running in an embedded Wasmtime instance. E.g. https://github.com/wasmCloud/wadge/blob/c21abaf5487ad79dd17660858127b3232c2623f4/bindings/bindings.go#L22-L36 for wasi:clocks/[email protected]#now
This works by using canonical ABI-ish to read and write data, which is essentially just canonical ABI for native targets.
I'd like to be able to follow a similar approach for Rust components and in future - other languages, but Rust is the current focus.
A straightforward way to handle this could be configuring the stub generation for imports on native targets.
Perhaps wit-bindgen macro could take in a NativeGenerator or something similar as an optional argument, which would allow users to configure how these imports are generated?
Perhaps the API could look similar to https://github.com/bytecodealliance/wit-bindgen/blob/66bfda38bee488df27692311e364d79a3cd301a7/crates/rust/src/interface.rs#L457:
trait NativeGenerator {
fn generate_import(&mut self, func: &Function)
}
The trait could have a default implementation generating the unreachable! stub.
Of course there would need to be some API to facilitate the printing, perhaps self could expose the src, or the function might return a String
I'm happy to work on contributing this feature myself if there's an interest for getting it merged.
I think having a trait or similar to configure makes sense yeah. Wouldn't really be accessible through the CLI or the procedural macro but that seems ok too
