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 aTokenStream
.Benefit
In
wasm-bridge
, I need to call thewasm_bridge::component::bindgen!
macro and modify the import paths to usewasm_bridge::
instead ofwasmtime::
, 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:
wasmtime_component_macro_impl
- Implement thebindgen
macro as a normal function that takes and returns aTokenStream
.wasmtime_component_macro
- Export abindgen
proc macro, that would just call the impl crate's code.Alternatives
The "use
wasm_bridge::
instead ofwasmtime::
path" issue can be solved by using awasmtime
mod like this:mod wasmtime { pub use wasm_bridge::*; }
but there are other changes to the
TokenStream
that I will need to make.
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 inLift
andLower
). While it's possible for you to export all these types in a different crate (such aswasm_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 ofwasmtime-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 thewit-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.
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 aTokenStream
.Benefit
In
wasm-bridge
, I need to call thewasm_bridge::component::bindgen!
macro and modify the import paths to usewasm_bridge::
instead ofwasmtime::
, 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:
wasmtime_component_macro_impl
- Implement thebindgen
macro as a normal function that takes and returns aTokenStream
.wasmtime_component_macro
- Export abindgen
proc macro, that would just call the impl crate's code.Alternatives
The "use
wasm_bridge::
instead ofwasmtime::
path" issue can be solved by using awasmtime
mod like this:mod wasmtime { pub use wasm_bridge::*; }
but there are other changes to the
TokenStream
that I will need to make.
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 generatorI 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 thebindgen
function, so I can call it with aTokenStream
and get aTokenStream
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.
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: Nov 22 2024 at 16:03 UTC