Skip to content
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

Making wast parse results serializable #1428

Open
bakkot opened this issue Feb 28, 2024 · 5 comments
Open

Making wast parse results serializable #1428

bakkot opened this issue Feb 28, 2024 · 5 comments

Comments

@bakkot
Copy link
Contributor

bakkot commented Feb 28, 2024

I'd love to use the parser and encoder from wast in JavaScript. The easiest way for that to work would be for the parsed module to be serializable and deserializable as JSON, so that the string representations can be passed to JS via wasm-bindgen. Could the various AST types be made serializable?

I know adding serde adds some heft, but I think it could be done conditionally with an off-by-default feature.

I tried doing this myself by sprinkling #[derive(Serialize, Deserialize)] everywhere, but got stuck making the lifetimes work inside the instructions macro. I don't have enough experience with rust to figure out how to get that working.

@alexcrichton
Copy link
Member

Thanks for the report! I think this is related to #1395 in that the end result may be similar. I think this would be good to add, but if we could match the preexisting structure that wabt emits I think that'd be neat to avoid having multiple verisons floating around.

@alexcrichton
Copy link
Member

Oh and I should mention that a PR would be most welcome!

Do you need library support for this feature? If not I think it'd be best to just do it in the CLI by transforming the AST to a custom structure with #[derive]. I would hope that you won't need to apply #[derive] to all types in the wast crate but only the top-level ones dealing with *.wast directives, and that'll be easier when it's modeled as a different structure rather than directly #[derive]'d on all types.

@bakkot
Copy link
Contributor Author

bakkot commented Feb 28, 2024

Do you need library support for this feature?

That was my hope - my goal is to use this in a JS package, by making a crate which exposes two functions:

  • one which takes a .wat string and gives back a serialized representation of the parse result from the wast crate, and
  • one which takes such a serialized representation and gives me the compiled wasm binary

and then compiling that crate to wasm and calling it from JS. That would allow me to easily write transforms of wasm programs in a JS library. Doing it in the CLI wouldn't get there as easily. (I guess I could probably compile the CLI to WASI and then use it as a library by using an appropriate virtual filesystem in WASI, but that's a lot more painful.)

I would hope that you won't need to apply #[derive] to all types in the wast crate but only the top-level ones

Not everything, certainly, but you do need to represent instructions, and there's a lot of those.

@bakkot
Copy link
Contributor Author

bakkot commented Feb 28, 2024

Re: using wast2json (assuming that's the preexisting structure that wabt emits you're referring to), is there a way to go back from the JSON to .wat? If not it's not would only accomplish one of the directions, though I guess I could write the other one.

@alexcrichton
Copy link
Member

Ah ok, I'm erroneously conflating these two use cases then. Your use case is quite different where you want a JSON representation of the entire AST of a module. The wast2json command only returns a JSON representation of the testing directives in a *.wast file, the actual wasm files themselves are all represented as binary wasm.

I'd be a little hesitant taknig an entire module through a JSON AST but if it works for your use case it's something we can support. I suspect though that it's going to be a lot of #[derive] and, yes, we'll want them to be conditionally turned on via a feature.

For your use case I don't think the CLI would work well yeah, your use case would want #[derive] on all types for sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants