Use differential fuzzing tool to keep parity with trusted interpreted

[mfornet]

This is the differential tool I've been using — cleaned it up a bit and put it out as its own thing, separate from Talos (it drives any runtime through a CLI shim and diffs against V8 / wasmtime / the spec interpreter): https://github.com/jasisz/miscast

One heads-up so the output doesn't surprise you: it also flags a few f64 literal mismatches — every one I traced is Lean stdlib rounding (Float.ofScientific / Float.ofNat), i.e. upstream, not Talos's own logic.

Originally posted by @jasisz in #95

[Kayvan-Zahiri]

Happy to take this on as the in-repo integration of @jasisz's miscast (crediting it, not rebuilding): a just differential recipe that drives the runner exe as the SUT, a small seed corpus, and a CI gate that fails only on a real soundness divergence — with the known f64 Float.ofScientific / Float.ofNat rounding mismatches @jasisz flagged filtered out as upstream noise. Differential oracles / eval harnesses are what I worked on at Outlier, so this is in my lane.

@jasisz — would you rather miscast stay an external dep I pin/vendor, or have a thin driver mirrored in-repo? Happy to coordinate on Telegram first. I'll keep it to one focused PR (adapter + seeds, then CI separately).

[Kayvan-Zahiri]

Quick prototype update — wired @jasisz's miscast to the talos runner locally via a thin adapter (maps miscast's {wat} {wasm} {export} to runner <file> <method> [args]). Two useful findings:

• V8 works as an oracle out of the box via node — no wasmtime install needed for a first CI lane.
• --mode recgroup --sut custom surfaces 300 soundness reproducers, and they all share one signature — spec/V8 TRAP, talos returns a value for an ill-typed call_indirect across reordered rec groups — i.e. they minimize to the same root cause as call_indirect runs an ill-typed call across reordered recursion groups #108. Direct check, no miscast in the loop: runner module.wat go returns 932 where V8 traps. So the harness already pins a real, known bug at scale; the 300→1 clustering (and filtering the f64 Float.ofScientific/Float.ofNat rounding noise you flagged) is exactly the triage I'd wire in.

I'll keep the first PR to one logical change — a just differential recipe + the adapter + a small seed set — with the CI gate as a follow-up.

@jasisz before I open it: do you want miscast pinned/vendored as an external dep, or a thin driver mirrored in-repo? Happy to hash it out on Telegram.

[jasisz]

Either way works for me — whatever's easiest on your end.

One correction to set expectations, though: reduce dedupes mutation-variants by base+shape, but it won't auto-collapse the 300 recgroup cases (those are distinct generated modules, not labels over one seed), and there's no f64 noise filter in miscast yet — I traced those rounding mismatches by hand. So the clustering + the f64 filtering really is talos-side logic you'd be adding, not something already in the pin.

If you'd rather not carry that in talos CI, a known-noise allowlist is a clean thing to upstream into miscast so the gate stays honest — happy to take that.

[Kayvan-Zahiri]

Thanks, that's a useful correction. I'll keep the clustering and f64 handling talos-side rather than assume miscast does it.

Plan I'd go with:

• Pin miscast as an external dep (it's yours, no reason to vendor it in).
• First PR is just the runnable harness: a just differential recipe, the runner adapter, and a small seed set. No CI gate yet.
• CI gate as a follow-up, with a baseline of known divergences so it only fails on new ones. The f64 rounding and the 300 recgroup cases (all call_indirect runs an ill-typed call across reordered recursion groups #108) go in that baseline until they're fixed, not flagged as fresh failures.

On your offer: upstreaming the f64 known-noise into miscast makes sense, keeps the gate honest and reusable. The #108 set I'll baseline talos-side since those are real bugs, not noise. That work for you?

[mfornet]

@Kayvan-Zahiri your plan sounds good, do plan on pushing this task further?

[Kayvan-Zahiri]

Yes. I'll open the first PR shortly with the core harness (differential recipe, runner adapter, and initial seed corpus). After that, I'll follow up with the CI gate and any additional refinements. Thanks.