This is a really interesting project. The ability to inspect and manipulate Wasm modules at runtime opens up a lot of possibilities for debugging and tooling. Curious whether you've benchmarked the overhead of the toolkit itself on larger Go-compiled Wasm binaries?
I followed the same testing approach when writing a Wasm binary parser (technically, a decoder)[0].
It was pretty helpful having the official spec suite available and a major boost of confidence that your parser is compliant.
Nevertheless, it was my own tests that found a regression in the latest published version of the spec[1], which shows how important it is to have a variety of implementations.
This looks really useful for pre-runtime inspection of WASM modules. Are you using it for any security or sandboxing use cases?
I need to check their harness, compare it to wazero's and my own (wasm2go)
Btw, if Eli reads this: thanks for the WAT samples, they were very helpful working on wasm2go!
You're welcome :)
The harnesses are documented here: https://github.com/eliben/watgo/tree/main/tests
Note that I had to switch the harness from wazero to Node (unfortunately!) when it turned out wazero doesn't support gc and other new proposals (e.g. your comment here https://github.com/wazero/wazero/issues/2483)
Thank you very much for maintaining wazero - I love that project, and am looking forward to being able to use it for this in the future.
I'm working on EH right now! Slowly walking towards GC!!
You're welcome :)
evacchi does most of the maintaining these days, but I'll keep helping as best as I can.
Your harness looks interesting to replace wast2json with watgo in wasm2go. Though my current problem is that I should be using the JSON to decide which tests to run (manual process so far), and to generate the more complicated test files (e.g. the ones that link modules together).