-
Notifications
You must be signed in to change notification settings - Fork 138
Add component bindgen macros #376
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
Conversation
e3d98fa
to
7f21888
Compare
c11ec7a
to
5387278
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.
I left a couple of minor nits.
This definitely needs a couple of other folks to review but generally I think that this needs two things:
More comments (especially at the method/function level in th hyperlight_comppnent_util crate)
Unit tests
I also have a general question about the parsing of Wasm in order to generate code , why do we do this rather than parse WIT?
5387278
to
1f40391
Compare
1f40391
to
39a4a7c
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.
I really appreciate your commitment to documenting all of this so very thoroughly. This is some fantastic work! I'm also wondering what exact component model spec you are referencing throughout the code.
I'm not going to pretend to understand it all but looks reasonable on an initial read-through. Btw, I'm curious what the reason is for useing wasm-parser instead of wit-parser, and not read the wit directly?
c0983ed
to
d786e39
Compare
WIT is in even more a state of flux than the rest of the specification, and is a bit of a pain to work with, being arbitrarily limited in a bunch of ways. We are trying to extend it to be a bit more in line with the actual core language of component types, but that's not done. The component type language is a bit more general and a lot easier to parse/elaborate/deal with and better specified at the moment, so I just used it directly. From a devux perspective, we could probably pretty easily add a dependency on wit-parser to be able to desugar wit files provided by the user without asking them to do it first, but I think that's better left for a follow-up. |
d786e39
to
945d7e6
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.
Mostly LGTM. Just some minor comments.
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.
There are a lot of changes to review but overall it looks good to me.
Awesome work, @syntactically .
|
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.
The new abstractions are great.
For adding support for doing the wit desugaring in one go? Sure: #575.
I don't see any reason we would want to, as long as the desugaring is implemented reasonably correctly somewhere else. As I mentioned before, I would love to move more of the generic component-y code out of this crate and into something reusable (or replace it entirely with a component built from the reference implementation), so I don't see it making sense to add more of that kind of generic thing here. |
82bd8f1
to
8619213
Compare
Issue was created to track the request
8619213
to
6c48fd8
Compare
This is useful to allow host-side code to work on both core Hyperlight sandboxes and wrapped sandboxes like Hyperlight Wasm. Signed-off-by: Lucy Menon <[email protected]>
This is useful to allow host-side code to work on both core Hyperlight sandboxes and wrapped sandboxes like Hyperlight Wasm. Signed-off-by: Lucy Menon <[email protected]>
Signed-off-by: Lucy Menon <[email protected]>
This commit adds a general implementation of WebAssembly Component Model type elaboration, closely derived from the formal specification. It also adds a number of functions which can generate Rust binding code from appropriately-structured (roughly: WIT-like) component types. Signed-off-by: Lucy Menon <[email protected]>
This adds a proc-macro crate that exposes the bindings code generation from hyperlight_component_util as macros suitable for using WIT to define a hyperlight host<->guest interface. Signed-off-by: Lucy Menon <[email protected]>
Add tests that ensure that all value types can be round-trip'd through a WIT guest, as well as some basic tests on host resources. Together, these are a pretty decent test of the WIT functionality, especially the hyperlight-specific serialization, which is the bit most likely to cause problems. Signed-off-by: Lucy Menon <[email protected]>
Signed-off-by: Lucy Menon <[email protected]>
Signed-off-by: Lucy Menon <[email protected]>
6c48fd8
to
3143032
Compare
This adds a macro that allows generating a host-side interface to a Hyperlight sandbox based on a WebAssembly Component Type (roughly equivalent to a WIT file).