Encode component types in canonical ABI module custom sections #331
Conversation
This file contains 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
pchickey
force-pushed
the
custom_section_smuggling
branch
from
246c777 to
f427d76
Compare
pchickey
force-pushed
the
custom_section_smuggling
branch
3 times, most recently
from
86db399 to
abe43a2
Compare
This commit removes all support for the `resource` and `Handle` types from the AST of `wit-parser` and all related support in all code generators. The motivation for this commit is that `wit-bindgen` is on the cusp of actually being able to work with components: producing a component from guest output and consuming components in host generators. More detail about this is in bytecodealliance#314. With components as an intermediate format, however, there is no way to encode resources since they are not part of the component model proposal yet. All is not lost for handles and resources, though. The official design for handles and resources is being worked on upstream in the component model repository itself at this time and once added all of this support will be re-added to `wit-bindgen`. In the meantime though I personally think that the best way forward is to remove the interim support for a few reasons: * Primarily it unblocks progress at this time towards fully integrating components and the `wit-bindgen` generators. The requirement to run existing tests that use handles would mean that no host generator could actually switch to components and/or modes for today's core-wasm-lookalike would need to be preserved. * Otherwise though the semantics of the current handles are basically invented out of thin air by myself and were never really formally specified, debated, or designed deliberately. I grafted `witx`-style handles into `wit-component` and added features as necessary over time, but it seems highly unlikely that the handles designed as part of the component model will be the ones that `wit-bindgen` currently supports. This inevitably means that a new system would need new code anyway and would likely result in removal regardless. As usual git always has the history of handles and this all may come back in one shape or another if only slightly tweaked. I'm confident in our history spelunking abilities, though, so I don't feel that keeping support in the repository is necessary for this purpose.
so that I can use the Interfaces decoded from the module's custom section
theyre not in wit, but thats a bug we need to fix, because they are in component types
…t they encode as components except for "invalid" and "handles" which are not gonna work
pchickey
force-pushed
the
custom_section_smuggling
branch
from
abe43a2 to
f351601
Compare
pchickey
changed the title
alexcrichton
approved these changes
Oct 5, 2022
alexcrichton
added a commit
to alexcrichton/witx-bindgen
that referenced
this pull request
Oct 5, 2022
This commit is the next step in integrating `wasm32-wasi`, `wit-bindgen`, tests, and components all together. Tests are now again compiled with `wasm32-wasi` and use a repo-specific adapter module (with support from bytecodealliance#338) to support transforming the final module into an actual component. In supporting this feature the support from bytecodealliance#331 is refactored into a new `extract` Rust module so the functionality can be shared between the ingestion of the main module as well as ingestion of adapter modules. Adapter modules now are also supported on the CLI as a standalone file without having to specify other options. Note that the actual `wasi_snapshot_preview1.wasm` adapter is non-functional in this commit and doesn't do anything fancy. The tests in this repository don't really need all that much and I suspect all we'll really need to implement is `fd_write` for fd 1 (as that's stdout).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Based on top of #346
This PR is prototyping a system which is designed to replace Canonical ABI name mangling. See WebAssembly/component-model#106 for more details on why we decided to ditch that idea, and how we started thinking about the replacement
wit-component
Wit-component already had the ability to translate between (a subset of) wit and components using its
InterfaceEncoderandInterfaceDecodertypes.The
ComponentEncodertype is used to take a core module and its relatedInterfaces and encode these as a component. This PR adds behavior that searches for custom sections named in the patterncomponent-type:{import|export}:*in the module, decodes them withInterfaceDecoder, and uses them for encoding the component, just like it would when provided by wit files on the command line.This means command line users will be able to simply run
wit-component module.wasmto translate a custom-section component type bearing canonical ABI module into a component.gen-guest-rust
The Rust guest generator has been updated to provide component type information in the appropriate custom sections. The generator takes a dependency on
wit-componentto use theInterfaceEncoder.This PR needs to be based on top of #346 because the use of handles/resources in a rust Guest will now panic the proc macro, because these concepts don't have a component encoding.
Testing
To test that the Rust guest generator is working with wit-component, the
test-helpers/build.rsscript ensures that all wasms compiled from Rust can be translated to a valid component usingComponentEncoder. An exception is made for theinvalidtest.