-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[rust-macro] generate! should allow defering handling exports to dependent crates #674
Comments
Yeah this is one I'd love to see solved but I don't see a path forward myself unfortunately. I'm hoping others can have better ideas though! The crux of the problem is that previously it was possible to generated exported types ahead-of-time and then use that from the exports macro later. This breaks down with resources, however, because as the implementor of the exports you likely want to define resources in addition to exports. This ends up meaning we can't define the types until the implementor is in-scope which means One possible fix is to split generation of imports and exports, e.g. Wasmtime's Other possible solutions might entail redoing how exported resources are represented, and I haven't gone too far down that path myself yet. |
Theres a similar issue in the Adding in my use case here. I have a need to make a library that wraps some |
See discussion here: https://bytecodealliance.zulipchat.com/#narrow/stream/327223-wit-bindgen/topic/external.20export.20implementations/near/387677837
I also want this feature. It kind of used to exist with the old export macro approach that was replaced when resource type support was added. You used to be able to have one library crate that called
generate!
and exported the "export" macro to any dependent crates who could then bind the exports of the world. When resource types were added the API changed to force the invoker ofgenerate!
to specify what interfaces it was exporting and implement them right then and there (at least that's my understanding).As @alexcrichton mentioned wastime's
bindgen!
macro lets you do something like this already with more sophisticated macro parameters. Perhaps this approach could be applied here too.The text was updated successfully, but these errors were encountered: