[lunadogbot]

Summary

Bumps deno_graph from =0.108.1 to =0.108.2, which picks up
denoland/deno_graph#644
("fix: support wasm multi-value types").

Without this fix, importing a WebAssembly function whose signature has multiple
return values (e.g. (result i32 i32)) generates a TypeScript declaration whose
return type collapses to a single number instead of the expected tuple
[number, number], so deno check reports an incorrect type.

Changes

• Cargo.toml: deno_graph = { version = "=0.108.2", default-features = false }
• Cargo.lock: refreshed via cargo update -p deno_graph

No other workspace crate pins deno_graph directly. The 0.108.1 to 0.108.2 diff
is a one-file fix to src/source/wasm.rs plus test fixture updates and does not
change the public API, so no source changes are needed in this repo. The wasm
multi-value behavior is already covered by tests in deno_graph itself.

Verification

cargo check --bin deno passes cleanly against the new release.

Reproduction from the upstream issue:

mkdir /tmp/wasm-multi-value && cd /tmp/wasm-multi-value
deno run --allow-read --allow-write --allow-env - <<'JS'
import wabtMod from "npm:wabt@1.0.36";
const wabt = await wabtMod();
const wat = `(module
  (func $add_and_sub (param $a i32) (param $b i32) (result i32 i32)
    local.get $a local.get $b i32.add
    local.get $a local.get $b i32.sub)
  (export "add_and_sub" (func $add_and_sub)))`;
const mod = wabt.parseWat("t.wat", wat, { multi_value: true });
await Deno.writeFile("test.wasm", mod.toBinary({}).buffer);
JS

cat > test.ts <<'TS'
import { add_and_sub } from "./test.wasm";
const r: "expected-tuple" = add_and_sub(1, 2);
TS

./target/debug/deno check test.ts

With this PR, the inferred return type is now [number, number] rather than number.

Fixes #34065

Closes bartlomieju/orchid-inbox#81

[bartlomieju]

@lunadogbot can you add a test for this wasm feature? Place it next to other wasm import tests

[lunadogbot]

Added a spec test in tests/specs/check/wasm_multi_value/. It type-checks a TS file that imports a wasm function with signature (i32, i32) -> (i32, i32) and assigns the result to string, asserting that the reported actual type is [number, number]. Without this PR's deno_graph bump the same test reports the type as number, so it would fail.