Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
) The `wast` crate is responsible for turning textual WebAssembly into binary WebAssembly. This crate predates the existence of `wasm-encoder` and as such had its own implementation of converting the textual AST to binary. This works by effectively having a method for most AST nodes which says "put yourself into this list of bytes" and then making sure to carefully call everything in the correct order to ensure that the final bytes are indeed valid. Since `wast` was originally created, however, the `wasm-encoder` crate was created. This crate provides a static API and guarantee that the created module will be at least syntactically valid if not semantically valid. This makes emission less error prone and additionally deduplicates the encoding details between `wast` and the `wasm-encoder` crate. For quite some time now the `component` support in the `wast` crate has already been using the `wasm-encoder` crate to encode components. This is done by implementing conversions of AST fragments in `wast` to equivalent fragments in `wasm-encoder`. These conversions are then used to feed data into the right sections to produce the final binary. The purpose of this commit is to start moving in the same direction for core wasm. This commit itself doesn't update all of `binary.rs` but instead only replaces the top-level module with `wasm_encoder::Module`. This updates a few other minor locations too but the bulk of the work is left for a future commit. This is done to ensure there's support for this direction first before completing this work. One downside to this approach is that it might mean that the `wast` crate's binary size grows a bit since the `wasm-encoder` crate isn't quite as "tight" as the encoding in `wast` today. That being said the binary size of `wast` itself has not so far been a concern for anyone and this concern is mostly theoretical and can hopefully be worked around with alternative API design in `wasm-encoder` if needed. Another downside of this approach is that it's coupling `wast` to `wasm-encoder` more tightly, meaning change is harder. That is a good thing in that it reduces duplication but it's a bad thing where if you're only interested in text parsing then it means that adding new features would also require adding features to `wasm-encoder`. This downside is somewhat inescapable though and the only mitigating factor I'd have to offer is that so far most minor wasm extensions have already been coupled with sibling changes to the parser/validator/printer/encoder/etc. This does mean that it's less likely that a new contributor could implement a major proposal like Wasm GC which required large refactorings in all crates (whereas GC was initially implemented in `wast` by an external contributor as it was relatively localized). Overall I personally at least feel that the benefit of not having a duplicate encoder is the worth the tradeoffs here. All other crates in this repository are already deeply intertwined in terms of testing and feature support, and this is continuing that trend for the `wast` crate as well.
- Loading branch information