Stream: git-wasmtime

Topic: wasmtime / issue #6690 Export component::bindgen! macro a...


view this post on Zulip Wasmtime GitHub notifications bot (Jul 05 2023 at 17:17):

kajacx opened issue #6690:

Export component::bindgen! macro as a normal function

The wasm_bridge::component::bindgen! macro works well for it's intended purpose, but I need to modify it's output as a TokenStream.

Benefit

In wasm-bridge, I need to call the wasm_bridge::component::bindgen! macro and modify the import paths to use wasm_bridge:: instead of wasmtime::, for example.

This can be done by modifying the TokenStream (I hope), but I cannot call the macro as a normal function to modify the output. See this post to get a better understanding.

Implementation

Proc macro crates cannot export "normal" functions, so I guess the only option would be to split the wasmtime_component_macro crate into two crates:

Alternatives

The "use wasm_bridge:: instead of wasmtime:: path" issue can be solved by using a wasmtime mod like this:

mod wasmtime {
    pub use wasm_bridge::*;
}

but there are other changes to the TokenStream that I will need to make.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 05 2023 at 23:17):

alexcrichton commented on issue #6690:

Thanks for the report! I'm not sure that this is something we want to "official" support though. Technically it's possible for you to depend on wasmtime-wit-bindgen and run that as a code generator, but the output is intertwined with the details of Wasmtime's embedding API which includes some public-but-shouldn't-be-touched portions used by derive (e.g. the hidden methods in Lift and Lower). While it's possible for you to export all these types in a different crate (such as wasm_bridge) there's no stability guarantees or any sort of compatibility guarantees we can reasonably provide. This means that your best bet may be to pin to a specific version of wasmtime-wit-bindgen if you'd like to use the source.

Otherwise though the "guts" of wasmtime-wit-bindgen are intended to be somewhat simple. The main logic is all in the wit-parser crate which takes care of much of the implementation details of WIT and things like that, so you may also want to either copy Wasmtime's implementation and start editing it or start from scratch.

In general though this is not something we can commit on our end to helping to maintain, so in that sense I'm not sure there's going to be a great way for us to satisfy this feature request.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 05 2023 at 23:17):

alexcrichton closed issue #6690:

Export component::bindgen! macro as a normal function

The wasm_bridge::component::bindgen! macro works well for it's intended purpose, but I need to modify it's output as a TokenStream.

Benefit

In wasm-bridge, I need to call the wasm_bridge::component::bindgen! macro and modify the import paths to use wasm_bridge:: instead of wasmtime::, for example.

This can be done by modifying the TokenStream (I hope), but I cannot call the macro as a normal function to modify the output. See this post to get a better understanding.

Implementation

Proc macro crates cannot export "normal" functions, so I guess the only option would be to split the wasmtime_component_macro crate into two crates:

Alternatives

The "use wasm_bridge:: instead of wasmtime:: path" issue can be solved by using a wasmtime mod like this:

mod wasmtime {
    pub use wasm_bridge::*;
}

but there are other changes to the TokenStream that I will need to make.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 06 2023 at 10:02):

kajacx commented on issue #6690:

Thanks for the reply @alexcrichton

Technically it's possible for you to depend on wasmtime-wit-bindgen and run that as a code generator

I can invoke the bindgen! macro with a world definition like this:

wasmtime_component_macro::bindgen!({
    path: "../protocol.wit",
    world: "test-world",
});

but that is not what I want. What I want is to manipulate the TokenStream coming from that macro. It is my understanding that this is currently impossible in Rust, but there is a workaround to separate the code into two crates, like I described in the original post.

there's no stability guarantees or any sort of compatibility guarantees we can reasonably provide

That's fine, I can pin a specific version like you said.

so you may also want to either copy Wasmtime's implementation and start editing it or start from scratch.

That's another option: copy the entire code of wasmtime_bindgen_macro and just remove the [proc_macro] from the bindgen function, so I can call it with a TokenStream and get a TokenStream back. This would work, but would be even more unstable with regards to changes in wasmtime, because I would need to manually update the entire crate every time a new version is released.

But this would open new doors, where, as you said, I could change the code directly inside this "clone" instead of relying on manipulation the TokenStream, which might be better moving forward.

This is not something I need right now, so I guess I will cross that bridge when I get there.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 06 2023 at 17:37):

alexcrichton commented on issue #6690:

Yes I understand invoking the macro doesn't work for you, I mean to depend on the internals of the macro or, as you've put it, copying the wasmtime_bindgen_macro crate/module.

Manual updates are expected for something like this as it's not something we can reasonably "officially" support, which is where pinning comes in where you could be compatible with a historical version if you'd like.


Last updated: Dec 23 2024 at 12:05 UTC