Closed titzer closed 2 years ago
Cool! This all looks about right to me. And our wasm-tools implementation passes the new tests!
Currently the test suite is (mostly) structured around individual constructs, i.e., one file for each instruction family or declaration form, which this would break with. I'm not necessarily opposed, but I'd at least be curious to know the motivation for this split.
This separates the only flow-sensitive validation rules into their own test, making it easier to adjust in the future. IMO that logic is not really inherent to local.get
, it's just a consequence of local.get
being the only instruction that reads a local.
I understand the motivation for the current test organization, but splitting some larger test files up has some practical benefits, like more parallelization and easier debugging for engines that don't (yet) have their own tests. E.g. I've spent hundreds of hours with spec tests over the years keeping up with proposals, and smaller is better; when tests stretch into the hundreds or thousands of lines, productivity drops precipitously. When I write my own, smaller tests, they just get out of date with proposals.
This PR pulls out initialization-related tests for locals into their own file and adds some additional cases; e.g. that
if-then-else
is handled properly, as well aslocal.tee
.