added initial parsing for resources and shared handles #1053
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
sunfishcode
reviewed
May 30, 2023
There was a problem hiding this comment.
The parsing and syntax looks good to me!
My instinct here is that resources would be better off not being a TypeDefKind, because it's my understanding they'll never be first-class. The only place they can ever appear is as the referent of handles, and also, handles don't refer to anything other than resources.
Yes that makes sense. I was unsure if we wanted to support types other than resources in the future. If that's not the case then I will change resources to not be |
|
Looks good! |
sunfishcode
approved these changes
Jun 1, 2023
|
Thanks for working on this! @silesmo are you able to fill work on filling out the remaining Additionally would you be up for updating |
@alexcrichton Yes, my plan is to start working on that this weekend! Yes I agree, I will make sure to update the documentation as well :) |
alexcrichton
added a commit
to alexcrichton/wasm-tools
that referenced
this pull request
Jun 14, 2023
This commit changes the representation of resources and their methods in the `wit-parser` crate as implemented originally in bytecodealliance#1053. Previously methods related to a resource were strung as a separate list of methods from each `Resource` type which provided a nested view of functions for bindings generators to interpret. This representation, however, does not allow for methods or constructors to actually refer to the resource type itself because the resource type can't be created until the method list is created, a cyclic dependency. To handle this problem this commit removes the nested list of functions and instead places all resource methods and functions and such within the normal single list of functions within an interface. This represents a "flattened" version of all functions available within an interface or world and aligns with the WebAssembly representation of how these will work. The names of these functions are not valid identifiers and have the component-model mangling along the lines of `[method]foo.bar` for example. My hope is that in the future as bindings generators are worked on various helper methods can be added to automatically group functions based on their kind to avoid any issues. Otherwise though this will likely "break" all existing code generators when resources are introduced because the names aren't valid identifiers in any language. I think this is a good thing, however, as that way it can't be forgotten to handle the resources case and failures will be "loud" in theory. This commit changes a number of other miscellaneous details such as: * Type resolution no longer needs to consider types referenced by methods of resources as dependencies which reflects how this will all look in a wasm binary format where resources are declared before their member functions are declared. * Parsing has been updated to address some minor issues here and there and additionally has some new names to remove the old "value" concept which is no longer a thing.
alexcrichton
added a commit
to alexcrichton/wasm-tools
that referenced
this pull request
Jun 14, 2023
This commit changes the representation of resources and their methods in the `wit-parser` crate as implemented originally in bytecodealliance#1053. Previously methods related to a resource were strung as a separate list of methods from each `Resource` type which provided a nested view of functions for bindings generators to interpret. This representation, however, does not allow for methods or constructors to actually refer to the resource type itself because the resource type can't be created until the method list is created, a cyclic dependency. To handle this problem this commit removes the nested list of functions and instead places all resource methods and functions and such within the normal single list of functions within an interface. This represents a "flattened" version of all functions available within an interface or world and aligns with the WebAssembly representation of how these will work. The names of these functions are not valid identifiers and have the component-model mangling along the lines of `[method]foo.bar` for example. My hope is that in the future as bindings generators are worked on various helper methods can be added to automatically group functions based on their kind to avoid any issues. Otherwise though this will likely "break" all existing code generators when resources are introduced because the names aren't valid identifiers in any language. I think this is a good thing, however, as that way it can't be forgotten to handle the resources case and failures will be "loud" in theory. This commit changes a number of other miscellaneous details such as: * Type resolution no longer needs to consider types referenced by methods of resources as dependencies which reflects how this will all look in a wasm binary format where resources are declared before their member functions are declared. * Parsing has been updated to address some minor issues here and there and additionally has some new names to remove the old "value" concept which is no longer a thing.
alexcrichton
added a commit
to alexcrichton/wasm-tools
that referenced
this pull request
Jun 16, 2023
This commit changes the representation of resources and their methods in the `wit-parser` crate as implemented originally in bytecodealliance#1053. Previously methods related to a resource were strung as a separate list of methods from each `Resource` type which provided a nested view of functions for bindings generators to interpret. This representation, however, does not allow for methods or constructors to actually refer to the resource type itself because the resource type can't be created until the method list is created, a cyclic dependency. To handle this problem this commit removes the nested list of functions and instead places all resource methods and functions and such within the normal single list of functions within an interface. This represents a "flattened" version of all functions available within an interface or world and aligns with the WebAssembly representation of how these will work. The names of these functions are not valid identifiers and have the component-model mangling along the lines of `[method]foo.bar` for example. My hope is that in the future as bindings generators are worked on various helper methods can be added to automatically group functions based on their kind to avoid any issues. Otherwise though this will likely "break" all existing code generators when resources are introduced because the names aren't valid identifiers in any language. I think this is a good thing, however, as that way it can't be forgotten to handle the resources case and failures will be "loud" in theory. This commit changes a number of other miscellaneous details such as: * Type resolution no longer needs to consider types referenced by methods of resources as dependencies which reflects how this will all look in a wasm binary format where resources are declared before their member functions are declared. * Parsing has been updated to address some minor issues here and there and additionally has some new names to remove the old "value" concept which is no longer a thing.
alexcrichton
added a commit
that referenced
this pull request
Jun 16, 2023
* Change data representation of resource methods This commit changes the representation of resources and their methods in the `wit-parser` crate as implemented originally in #1053. Previously methods related to a resource were strung as a separate list of methods from each `Resource` type which provided a nested view of functions for bindings generators to interpret. This representation, however, does not allow for methods or constructors to actually refer to the resource type itself because the resource type can't be created until the method list is created, a cyclic dependency. To handle this problem this commit removes the nested list of functions and instead places all resource methods and functions and such within the normal single list of functions within an interface. This represents a "flattened" version of all functions available within an interface or world and aligns with the WebAssembly representation of how these will work. The names of these functions are not valid identifiers and have the component-model mangling along the lines of `[method]foo.bar` for example. My hope is that in the future as bindings generators are worked on various helper methods can be added to automatically group functions based on their kind to avoid any issues. Otherwise though this will likely "break" all existing code generators when resources are introduced because the names aren't valid identifiers in any language. I think this is a good thing, however, as that way it can't be forgotten to handle the resources case and failures will be "loud" in theory. This commit changes a number of other miscellaneous details such as: * Type resolution no longer needs to consider types referenced by methods of resources as dependencies which reflects how this will all look in a wasm binary format where resources are declared before their member functions are declared. * Parsing has been updated to address some minor issues here and there and additionally has some new names to remove the old "value" concept which is no longer a thing. * Fix resources-in-worlds with methods Additionally be sure to update ids listed in `FunctionKind` during merging.
alexcrichton
added a commit
to alexcrichton/wasm-tools
that referenced
this pull request
Jul 11, 2023
Releases recent changes such as: * More support for the gc proposal. bytecodealliance#1045 bytecodealliance#1059 * Support for resources throughout most tooling. bytecodealliance#1053 bytecodealliance#1068 bytecodealliance#1070 bytecodealliance#1082 bytecodealliance#1079 bytecodealliance#1083 bytecodealliance#1084 bytecodealliance#1105 bytecodealliance#1113 bytecodealliance#1116 * Support for `include` in WIT files. bytecodealliance#1054 bytecodealliance#1085 bytecodealliance#1088 * WIT worlds may now be rejected if the same interface can be "reached" as both an import and an export simultaneously. bytecodealliance#1081 bytecodealliance#1107 * Support for registry metadata in `wasm-tools metadata`. bytecodealliance#1060 * A new subcommand `wasm-tools component targets`. bytecodealliance#1089 * An `--out-dir` argument is supported on `wasm-tools component wit` to print the entire `Resolve` instead of just one package. bytecodealliance#1108 * Miscellaneous bug fixes and improvements. bytecodealliance#1061 bytecodealliance#1065 bytecodealliance#1074 bytecodealliance#1073 bytecodealliance#1078 bytecodealliance#1077 bytecodealliance#1072 bytecodealliance#1086 bytecodealliance#1091 bytecodealliance#1094 bytecodealliance#1114 bytecodealliance#1106
alexcrichton
added a commit
to alexcrichton/wasm-tools
that referenced
this pull request
Jul 11, 2023
Releases recent changes such as: * More support for the gc proposal. [bytecodealliance#1045](bytecodealliance#1045) [bytecodealliance#1059](bytecodealliance#1059) * Support for resources throughout most tooling. [bytecodealliance#1053](bytecodealliance#1053) [bytecodealliance#1068](bytecodealliance#1068) [bytecodealliance#1070](bytecodealliance#1070) [bytecodealliance#1082](bytecodealliance#1082) [bytecodealliance#1079](bytecodealliance#1079) [bytecodealliance#1083](bytecodealliance#1083) [bytecodealliance#1084](bytecodealliance#1084) [bytecodealliance#1105](bytecodealliance#1105) [bytecodealliance#1113](bytecodealliance#1113) [bytecodealliance#1116](bytecodealliance#1116) * Support for `include` in WIT files. [bytecodealliance#1054](bytecodealliance#1054) [bytecodealliance#1085](bytecodealliance#1085) [bytecodealliance#1088](bytecodealliance#1088) * WIT worlds may now be rejected if the same interface can be "reached" as both an import and an export simultaneously. [bytecodealliance#1081](bytecodealliance#1081) [bytecodealliance#1107](bytecodealliance#1107) * Support for registry metadata in `wasm-tools metadata`. [bytecodealliance#1060](bytecodealliance#1060) * A new subcommand `wasm-tools component targets`. [bytecodealliance#1089](bytecodealliance#1089) * An `--out-dir` argument is supported on `wasm-tools component wit` to print the entire `Resolve` instead of just one package. [bytecodealliance#1108](bytecodealliance#1108) * Miscellaneous bug fixes and improvements. [bytecodealliance#1061](bytecodealliance#1061) [bytecodealliance#1065](bytecodealliance#1065) [bytecodealliance#1074](bytecodealliance#1074) [bytecodealliance#1073](bytecodealliance#1073) [bytecodealliance#1078](bytecodealliance#1078) [bytecodealliance#1077](bytecodealliance#1077) [bytecodealliance#1072](bytecodealliance#1072) [bytecodealliance#1086](bytecodealliance#1086) [bytecodealliance#1091](bytecodealliance#1091) [bytecodealliance#1094](bytecodealliance#1094) [bytecodealliance#1114](bytecodealliance#1114) [bytecodealliance#1106](bytecodealliance#1106)
Merged
alexcrichton
added a commit
that referenced
this pull request
Jul 11, 2023
Releases recent changes such as: * More support for the gc proposal. [#1045](#1045) [#1059](#1059) * Support for resources throughout most tooling. [#1053](#1053) [#1068](#1068) [#1070](#1070) [#1082](#1082) [#1079](#1079) [#1083](#1083) [#1084](#1084) [#1105](#1105) [#1113](#1113) [#1116](#1116) * Support for `include` in WIT files. [#1054](#1054) [#1085](#1085) [#1088](#1088) * WIT worlds may now be rejected if the same interface can be "reached" as both an import and an export simultaneously. [#1081](#1081) [#1107](#1107) * Support for registry metadata in `wasm-tools metadata`. [#1060](#1060) * A new subcommand `wasm-tools component targets`. [#1089](#1089) * An `--out-dir` argument is supported on `wasm-tools component wit` to print the entire `Resolve` instead of just one package. [#1108](#1108) * Miscellaneous bug fixes and improvements. [#1061](#1061) [#1065](#1065) [#1074](#1074) [#1073](#1073) [#1078](#1078) [#1077](#1077) [#1072](#1072) [#1086](#1086) [#1091](#1091) [#1094](#1094) [#1114](#1114) [#1106](#1106)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
Adds the initial pass for the parsing of resources and shared handles.
Do we want to store resources as a
TypeDefKind? I assume we might want to move this to an indexmap of resources and just store a resource id in handles?@sunfishcode