I64ToI32Lowering: return_call_indirect gets a (func (result unreachable)) type, binary writer hits UNREACHABLE #9244

--i64-to-i32-lowering rewrites the type of a return_call_indirect to (func (result unreachable)), even in a module with no i64 at all, so writing a binary aborts and writing text produces a module that does not parse.

(module (type $t (func)) (table 1 funcref) (func $a (return_call_indirect (type $t) (i32.const 0))))

wasm-opt -all input.wat --i64-to-i32-lowering -o /dev/null

unexpected type
UNREACHABLE executed at src/wasm/wasm-binary.cpp:2104!
    #1 wasm::handle_unreachable(char const*, char const*, unsigned int) src/support/utilities.cpp:39
    #2 wasm::WasmBinaryWriter::writeType(wasm::Type) src/wasm/wasm-binary.cpp:2104
    #3 wasm::WasmBinaryWriter::writeTypes() src/wasm/wasm-binary.cpp:307
    #4 wasm::WasmBinaryWriter::write() src/wasm/wasm-binary.cpp:63
    #5 wasm::ModuleWriter::writeBinary(wasm::Module&, wasm::BufferWithRandomAccess&) src/wasm/wasm-io.cpp:164

With -S -o out.wat instead, wasm-opt exits 0 and writes this, which the same wasm-opt then rejects with out.wat:3:24: error: expected valtype:

(module
 (type $t (func))
 (type $1 (func (result unreachable)))
 (global $i64toi32_i32$HIGH_BITS (mut i32) (i32.const 0))
 (table $0 1 funcref)
 (func $a (type $t)
  (return_call_indirect $0 (type $1)
   (i32.const 0)
  )
 )
)

I expected the call to keep (type $t): the input is valid (wasm-opt without the pass accepts it), there is nothing to lower, and the pass only rejects return calls with i64 results (with a clean Fatal), so other return calls look meant to be supported.

Found at commit 93d6e9d and still reproduces at 207bbae. A release build aborts the same way (SIGABRT) on binary output; with text output it exits 0 and writes the invalid module above. The validator does not report anything before writing.

Looks like visitGenericCall in src/passes/I64ToI32Lowering.cpp passes curr->type as the results when the call does not return i64, and for a return call that is unreachable, so visitCallIndirect builds Signature(Type(params), unreachable) as the new heap type; using the lowered curr->heapType.getSignature().results would avoid it.

Found with an LLM-based testing tool; I used Claude to reduce it and look for the cause.