Import stubs for native targets

[rvolosatovs]

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

wit-bindgen/crates/rust/src/interface.rs

Line 457 in 66bfda3

fn generate_guest_import(&mut self, func: &Function) {

:

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.

[alexcrichton]

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