-
Notifications
You must be signed in to change notification settings - Fork 242
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
Allow parsing rectypes
in components
#1764
Conversation
5c73263
to
cd6bae3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For added context this is an implementation of WebAssembly/component-model#392 but will wait on the exact path forward there to be settled on before landing here to avoid conflicting implementation/spec.
9a3d6ab
to
7171f4c
Compare
Oh oops apologies but this as of now has a merge conflict in |
This change supports [bytecodealliance#392], which adds a way to use GC's `rectypes` as type definitions in components. Previously, only function types were supported and there was no way express array and struct types. This keeps the previous function decoding support based on peeking the function type `0x60` prefix but adds support for encoding `rectypes` with a new `0x00` prefix. [bytecodealliance#392]: WebAssembly/component-model#392 Co-authored-by: Alex Crichton <[email protected]>
This follows along with the most recent discussion in the component model PR ([bytecodealliance#392]). [bytecodealliance#392]: WebAssembly/component-model#392 Co-authored-by: Alex Crichton <[email protected]>
c35d184
to
e6be634
Compare
This commit builds on the work of bytecodealliance#1764 to support the text format for GC types in components more than before. This notably bring support for: * `(sub ...)` types in components and module types * `(rec ...)` groups in components and module types * types can refer to themselves like with core wasm The main consequence of this work is that unlike most other `$foo` identifiers in the component model the identifiers found in types will not automatically inject outer aliases to refer to outer types. For example this will not parse: (component $C (type $t (struct)) (component (type (array (ref $t))) ) ) The reason for this is that automatic injection of an outer alias requires that types are resolved and then their names are registered. The resolution process queues up aliases to inject which are accounted for during registration when indices are assigned. Here though because types can refer to themselves (or future types in `rec` groups) the registration process has to happen first before resolution. This means that if resolution were to inject more type indices then that would mess up the indexes already assigned. This is hopefully relatively minor in terms of how often this'll bite someone. For now various changes have been made to the name resolution pass of components to handle this and some tests have been added too for both positive and negative situations.
This commit builds on the work of #1764 to support the text format for GC types in components more than before. This notably bring support for: * `(sub ...)` types in components and module types * `(rec ...)` groups in components and module types * types can refer to themselves like with core wasm The main consequence of this work is that unlike most other `$foo` identifiers in the component model the identifiers found in types will not automatically inject outer aliases to refer to outer types. For example this will not parse: (component $C (type $t (struct)) (component (type (array (ref $t))) ) ) The reason for this is that automatic injection of an outer alias requires that types are resolved and then their names are registered. The resolution process queues up aliases to inject which are accounted for during registration when indices are assigned. Here though because types can refer to themselves (or future types in `rec` groups) the registration process has to happen first before resolution. This means that if resolution were to inject more type indices then that would mess up the indexes already assigned. This is hopefully relatively minor in terms of how often this'll bite someone. For now various changes have been made to the name resolution pass of components to handle this and some tests have been added too for both positive and negative situations.
This change supports #392, which adds a way to use GC's
rectypes
as type definitions in components. Previously, only function types were supported and there was no way express array and struct types. This keeps the previous function decoding support based on peeking the function type0x60
prefix but adds support for encodingrectypes
with a new0x00
prefix.