Uses the latest wasmparser integration with cranelift-wasm, which performs validation of function bodies as they are consumed. This means we can remove the up-front wasmparser validation of the entire module, and rely entirely on cranelift-wasm for validation!
These changes to cranelift-wasm meant we had to change the way function bodies (& their new associated validator) were owned by lucetc::Compiler. This was mostly code motion.
We had a test for lucetc that it rejected an invalid wasm module, but the sources were lost to time[1] . This test has been rewritten based on call.wat to introduce a type error at a specific opcode, and test that we get a validation error at that opcode.
[1]: The comments had this to say about invalid.wasm, which I derived from the spec tests a very long time ago:
// I used the `wast2json` tool to produce the file invalid.wasm from an assert_invalid part
// of a spectest (call.wast)
let wasmfile = PathBuf::from("tests/wasm/invalid.wasm");
Contains fixes for cranelift-module API: https://github.com/bytecodealliance/wasmtime/pull/2249
Uses the latest
wasmparser
integration withcranelift-wasm
, which performs validation of function bodies as they are consumed. This means we can remove the up-frontwasmparser
validation of the entire module, and rely entirely oncranelift-wasm
for validation!These changes to
cranelift-wasm
meant we had to change the way function bodies (& their new associated validator) were owned bylucetc::Compiler
. This was mostly code motion.We had a test for
lucetc
that it rejected an invalid wasm module, but the sources were lost to time[1] . This test has been rewritten based oncall.wat
to introduce a type error at a specific opcode, and test that we get a validation error at that opcode.[1]: The comments had this to say about
invalid.wasm
, which I derived from the spec tests a very long time ago: