Skip to content

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

Merged
merged 8 commits into from
Jun 6, 2025
Merged

Add component bindgen macros #376

merged 8 commits into from
Jun 6, 2025

Conversation

syntactically
Copy link
Member

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).

@syntactically syntactically force-pushed the hyperlight-component-macro branch 2 times, most recently from e3d98fa to 7f21888 Compare March 24, 2025 19:10
@syntactically syntactically added the kind/enhancement For PRs adding features, improving functionality, docs, tests, etc. label Mar 24, 2025
@syntactically syntactically force-pushed the hyperlight-component-macro branch 15 times, most recently from c11ec7a to 5387278 Compare March 25, 2025 19:12
Copy link
Contributor

@simongdavies simongdavies left a 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?

@jsturtevant jsturtevant mentioned this pull request Jun 4, 2025
@syntactically syntactically force-pushed the hyperlight-component-macro branch from 1f40391 to 39a4a7c Compare June 4, 2025 19:52
Copy link
Contributor

@ludfjig ludfjig left a 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?

@syntactically syntactically force-pushed the hyperlight-component-macro branch 2 times, most recently from c0983ed to d786e39 Compare June 5, 2025 13:23
@syntactically
Copy link
Member Author

Btw, I'm curious what the reason is for useing wasm-parser instead of wit-parser, and not read the wit directly?

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.

@syntactically syntactically force-pushed the hyperlight-component-macro branch from d786e39 to 945d7e6 Compare June 5, 2025 13:29
ludfjig
ludfjig previously approved these changes Jun 5, 2025
Copy link
Contributor

@danbugs danbugs left a 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.

dblnz
dblnz previously approved these changes Jun 5, 2025
Copy link
Contributor

@dblnz dblnz left a 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 .

@simongdavies
Copy link
Contributor

Btw, I'm curious what the reason is for useing wasm-parser instead of wit-parser, and not read the wit directly?

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.

  1. Can we get an issue for that?
  2. Is there a point in the future where we will be able to move to using a wit-parser instead?

Copy link
Contributor

@simongdavies simongdavies left a 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.

@syntactically
Copy link
Member Author

syntactically commented Jun 6, 2025

  1. Can we get an issue for that?

For adding support for doing the wit desugaring in one go? Sure: #575.

  1. Is there a point in the future where we will be able to move to using a wit-parser instead?

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.

@syntactically syntactically dismissed stale reviews from dblnz and ludfjig via 82bd8f1 June 6, 2025 11:44
@syntactically syntactically force-pushed the hyperlight-component-macro branch 2 times, most recently from 82bd8f1 to 8619213 Compare June 6, 2025 14:03
@danbugs danbugs dismissed simongdavies’s stale review June 6, 2025 15:47

Issue was created to track the request

@syntactically syntactically force-pushed the hyperlight-component-macro branch from 8619213 to 6c48fd8 Compare June 6, 2025 17:45
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]>
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]>
@syntactically syntactically force-pushed the hyperlight-component-macro branch from 6c48fd8 to 3143032 Compare June 6, 2025 19:01
@danbugs danbugs merged commit 3143032 into main Jun 6, 2025
44 of 56 checks passed
@danbugs danbugs deleted the hyperlight-component-macro branch June 6, 2025 22:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement For PRs adding features, improving functionality, docs, tests, etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants