resources.wast test failing in sync mode with cooperative multithreading

[alexcrichton]

Fuzzing overnight plus some bisection locally shows that after #11751 and with #11953 applied the following fails locally

$ cargo run wast tests/misc_testsuite/component-model/resources.wast --async=false
   Compiling wasmtime-cli v39.0.0 (/Users/alex/code/wasmtime)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.18s
     Running `target/debug/wasmtime wast tests/misc_testsuite/component-model/resources.wast --async=false`
Error: failed to run script file 'tests/misc_testsuite/component-model/resources.wast'

Caused by:
    0: failed directive on tests/misc_testsuite/component-model/resources.wast:28
    1: error while executing at wasm backtrace:
           0:     0x5d - m!<wasm function 1>
       note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information
    2: wasm trap: wasm `unreachable` instruction executed

cc @TartanLlama would you be up for investigating this?

[TartanLlama]

Will do!

[TartanLlama]

Ah, so this is a case where disabling async changes the handle values of the resources because there's no longer an implicit thread created upon the export call. The test relies upon the resource handle being 2, with the implicit thread filling in the 1 slot.

[TartanLlama]

I guess the spec-consistent behaviour would be to add an entry into the table on sync export calls that will never be used. What do you think?

[alexcrichton]

Oof that's tricky! Your intuition matches mine though where a dummy handle feels the way to go here for when threading is disabled in Wasmtime.