various wit-dylib API tweaks
#2362
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I've recently ported `componentize-py` to use `wit-dylib` instead of its own Wasm code generator and found it useful to tweak the `wit-dylib` APIs a bit. The main idea here is to give `componentize-py` (and any similar build tool) access to the metadata generated by `wit-dylib` _before_ the guest runs, as well as match the types in that metadata up with the `wit_parser::TypeId`s from the input world. That allows the build tool to generate high-level binding code ahead of time and later match it up with the metadata at runtime. Specifically, this commit does the following: - Add a `wit_dylib::create_with_metadata` function which returns both the generated module and the `Metadata` object produced for it. - Add `id: TypeId` fields to all the "WIT type types" so that they can be matched up with the corresponding `wit-parser` types - Add `index` methods to the `wit-dylib-ffi` wrapper types, allowing the interpreter to determine where the instance appears in its respective array - Split the metadata `Function` type into separate `ImportFunction` and `ExportFunction` types, each with its own array in the `Wit` structure. Imported and exported functions are used very differently by interpreters; separating them makes them easier to deal with. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
alexcrichton
approved these changes
Oct 23, 2025
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
dicej
added a commit
to dicej/wasm-tools
that referenced
this pull request
Oct 23, 2025
I forgot to do this as part of bytecodealliance#2362 🤦 Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Merged
dicej
added a commit
to dicej/wasm-tools
that referenced
this pull request
Oct 23, 2025
I forgot to do this as part of bytecodealliance#2362 🤦 Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've recently ported
componentize-pyto usewit-dylibinstead of its own Wasm code generator and found it useful to tweak thewit-dylibAPIs a bit.The main idea here is to give
componentize-py(and any similar build tool) access to the metadata generated bywit-dylibbefore the guest runs, as well as match the types in that metadata up with thewit_parser::TypeIds from the input world. That allows the build tool to generate high-level binding code ahead of time and later match it up with the metadata at runtime.Specifically, this commit does the following:
wit_dylib::create_with_metadatafunction which returns both the generated module and theMetadataobject produced for it.id: TypeIdfields to all the "WIT type types" so that they can be matched up with the correspondingwit-parsertypesindexmethods to thewit-dylib-ffiwrapper types, allowing the interpreter to determine where the instance appears in its respective arrayFunctiontype into separateImportFunctionandExportFunctiontypes, each with its own array in theWitstructure. Imported and exported functions are used very differently by interpreters; separating them makes them easier to deal with.