You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit fully integrates resource types in the component model with
the `wit-component` crate, implementing features such as:
* A WIT package using `resource` types can now be round-tripped through
its WebAssembly encoding. This enables use cases such as `wit-bindgen`
which embed type information in custom sections of core wasm binaries
produced by native compilers.
* Core modules can be lifted into components and the component can use
resources. This provides a target for `wit-bindgen` and other code
generators to use when generating guest code. Resource intrinsics and
destructors are all available to the core wasm as desired.
* WIT can be inferred from components using resources, where functions
are represented as `resource`-related functions in WIT.
* The `roundtrip-wit` fuzzer is extended with resources support meaning
all of the above support will be fuzzed on OSS-Fuzz.
This required a number of refactorings in `wit-component` especially
around how type information was handled. Previous processing was a bit
fast-and-loose because where exactly a type was defined didn't really
matter since everything was nominal. With resource types, however,
definition locations are significant and this required some fixes to
previous processing. One example of this is that
WebAssembly/component-model#208 was discovered through this work and the
fixes required were implemented previously and further handled here in
`wit-component`.
Overall this PR has been almost exclusively fuzz-driven in its
development. I started out with the bare bones of getting simple
components working with resources being imported and exported, then
added fuzzing support to `wit-smith`, then let the fuzzer go wild. Quite
a few issues were discovered which led to all of the refactorings and
processing here in this PR. I definitely won't claim that this is a
simplification at all to `wit-component` by any measure. Rather it's
taking a complicated codebase and making it more complicated. In my
mind though the "saving grace" is that I'm pretty confident in the
testing/fuzzing story here. It's relatively easy to isolate issues and
add test cases for the various things that can crop up and the fuzzer
has quite good coverage of all the various paths through
`wit-component`. All that's to say that this is surely not the "best" or
easiest to understand implementation of resources, but it's intended to
be sufficient for now.
0 commit comments