Fuzz bug on type emitting

[kripken]

$ v8 a.wasm.js --wasm-staging --experimental-wasm-eh --experimental-wasm-compilation-hints \
   --experimental-wasm-gc --experimental-wasm-typed-funcref --experimental-wasm-memory64 \
  --experimental-wasm-extended-const -- w.wasm

$ wasm-opt w.wasm -o z.wasm -all --disable-gc --nominal
warning: no passes specified, not doing any work

$ v8 a.wasm.js --wasm-staging --experimental-wasm-eh --experimental-wasm-compilation-hints \
   --experimental-wasm-gc --experimental-wasm-typed-funcref --experimental-wasm-memory64 \
  --experimental-wasm-extended-const -- z.wasm
a.wasm.js:38: CompileError: WebAssembly.Module(): Type index 1 is out of bounds @+14
var instance = new WebAssembly.Instance(new WebAssembly.Module(binary), {
                                        ^
CompileError: WebAssembly.Module(): Type index 1 is out of bounds @+14
    at a.wasm.js:38:41

That is, round-tripping the wasm using -all --disable-gc --nominal results in a binary that v8 cannot read.
bug.zip

cc @tlively - this sounds like a recent issue we had that also related to nominal mode without GC enabled?

[kripken]

I was thinking of #4738

[tlively]

Will take a look!

[kripken]

I did a quick check - that PR regressed this testcase. A commit before still works.

[tlively]

The basic problem here is that the types are not ordered so that uses come before definitions. In this particular example, we could fix it by topologically sorting the types, but in general there might be recursive types that prevent that from working. Basically it is not meaningful to use --nominal without GC enabled since --nominal allows recursive types that cannot possibly be supported without GC.

The simplest solution here might be to just disallow the use of --nominal when GC is not enabled. WDYT, @kripken?

[kripken]

If that's easy to do then sgtm. The fuzzer may require some changes but I'm not sure how many offhand.