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/monotonic-clock@0.2.1#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

[BjornTheProgrammer]

Is there any work being done on this currently? This would be really useful for something like a plugin system that supports both native and wasm plugins. One for speed, the other for security.

[alexcrichton]

I don't know of anyone working on this if you'd like to give it a go.

[BjornTheProgrammer]

Alright, I've embarked on implementing this. I've thought of a couple of different solutions, but they all have their pitfalls.

Weak links would be ideal, but either require nigthly until rust-lang/rust#29603 is implemented, or for the end user to have a c compiler on their machine, which I've read in the github action code isn't ideal.

I then thought to just emit a trait that has every function that then can be defined, but this has limitations on using codegen to implement all of the native functions with a default implementation.

This left me with an admittedly more complex solution then I'd like of passing in a macro to bindgen that then can generate the implementations.

It is not great code, but I'll open up a draft PR. Please feel free to give me feedback on the approach that I'm taking, and whether there should be any changes.