Panic printing if with folded instructions where parameter is from block param

[alexcrichton]

The fuzzer today discovered that this input:

(module
  (func
    i32.const 0
    try_table (param i32)
      if
      end
    end
  )
)

will panic wasm-tools:

$ cargo run print -f test1.wat
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/wasm-tools print -f test1.wat`
(module
  (type (;0;) (func))
  (type (;1;) (func (param i32)))
thread 'main' panicked at crates/wasmprinter/src/operator.rs:1708:14:
no predicate
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@keithw would you be interested in looking into this? If you're otherwise busy I'm also happy to dig in further.

[keithw]

Glad it's catching things like that! I think #1840 will fix the panic.

It could be interesting to start testing and fuzzing that every well-formed Wasm module (valid or not) successfully roundtrips through wasmprinter -> wasmparser (with or without folding and/or name-unnamed). This would probably require fixing #1671; I'm not sure if it would be worth the effort and churn given that invalid (but well-formed) Wasm modules probably aren't very important in practice.

[alexcrichton]

Agreed! In #1839 I've updated the print fuzzer to frob configuration knobs (folding/name-unnamed/etc) and it just has random bytes thrown at it. In the same PR the validate fuzzer, which has a "mostly valid" module but functions may have random bytes, also tests printing with all the knobs. In #1831 I updated the validate_valid_module to ensure that print-then-parse for both folded/non-folded produces the same binary out the other end.

Our coverage for "mostly valid" modules isn't that great though, we're relying relatively heavily on the fuzzer doing a good job for that (aka running for a long time).

For #1671 I think we should be good though? That one's just a difference with the spec interpreter for when an error shows up, not that it shows up at all I think.