[NFC][wasm-reduce] Introduce TestCaseHandler and WasmTestCaseHandler

[tlively]

Parameterize Reducer, pre-flight checks, and reduceModule with a TestCaseHandler interface and WasmTestCaseHandler implementation to prepare for reducing embedded Wasm modules in JS files. TestCaseHandler abstracts how module bytes are read from and written to the test and working files. The next PR will add an alternative implementation that reads the bytes from byte arrays embedded in JS files and splices reduced module bytes back into the same JS files.

[kripken]

Why not extract the wasm files from the JS into normal files on disk, then issue a few calls to the main reducer on those files? I.e. without adding a new abstraction interface.

[tlively]

Running the test command in --js mode will require the candidate module to be spliced back into the JS file. It will also be useful to maintain the invariant that the working file is always the JS file with the working module spliced in so it remains usable with the test command if the reduction is interrupted.

An alternative approach would be to write .wasm files directly, as you suggest, and splice a loadbuffer('tmp.wasm') into the JS file in place of the byte array. But I think it's safer and simpler if we don't make the JS files depend on new files, even in intermediate states.

[stevenfontanella]

Mostly looks good. Can we see another example of a TestCaseHandler implementation in another PR? I looked through the stack quickly and didn't see it.

[kripken]

@tlively

Running the test command in --js mode will require the candidate module to be spliced back into the JS file.

But we need that logic anyhow, to splice in the final version? So we might as well splice it in as we work (or, splice in a readbuffer() call once, as you suggested - either can work).

But I think it's safer and simpler if we don't make the JS files depend on new files, even in intermediate states.

I am curious what you mean by "safer" here?

It seems significantly simpler to me to build in a modular way on the normal wasm reduction. Basically we can add some logic on top of that. This could even be done by a separate tool (python script or binary), which I'd prefer even more, to keep wasm-reduce simple?

[tlively]

#9121 is now up, and I hope you agree that it is very simple, even considering that it is built on top of this refactoring. My worry about depending on scripts is that most engineers who frequently want to reduce JS files won't want to use anything more complex than a single reduction tool on top of the reproduction commands they already have.

But I think it's safer and simpler if we don't make the JS files depend on new files, even in intermediate states.

I am curious what you mean by "safer" here?

Safer in the sense that if reduction is interrupted (by a crash or manually by the user), the latest working file is more likely to continue reproducing the bug as expected if it contains the same kind of literal embedded module as the original input. If it has been modified to depend on separate files, then the reproduction will become sensitive to e.g. the working directory and any other mechanism involved in locating the additional file.

[tlively]

It seems significantly simpler to me to build in a modular way on the normal wasm reduction. Basically we can add some logic on top of that.

Totally agree. I hope you agree #9121 accomplishes that without the downsides of juggling multiple other scripts.