You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The wasm-tools parse command doesn't validate that resulting module is correct. This is nice for writing tests, but is difficult for teaching beginners wasm. They're able to get text examples parsing correctly, but then they have to separately validate the binary and if that fails, all they are given is a terse error with a binary offset.
It'd be nice if wasm-tools parse had a mode which would also validate the result and display errors in terms of the original text.
I think the best way to do this would be if:
wast could emit a offset -> text span table
wasm-tools parse would optionally validate the resulting binary
Any errors are formatted to show the original source using the offset table
I didn't see any support in wast for this sort of source information. There is DWARF support, but I'm not sure if that could be hooked up for this.
One way to achieve half of this (sort of) is the -g (--generate-dwarf lines) flag on wasm-tools validate:
$ cat foo.wat
(module
(import "" "" (func $g))
(func $f (export "f")
ref.func $g
drop
)
)
$ wasm-tools validate -g foo.wat
error: ./foo.wat:4:5 function `f` failed to validate
Caused by:
0: func 1 failed to validate
1: undeclared function reference (at offset 0x25)
where validate doesn't actually emit the binary *.wasm anywhere, but with -g the text-to-binary transform inserts DWARF debugging information pointing back to the original source so the final error message has a filename/line number/column/etc.
Now that being said the error messages still aren't great. While it's got a filename that's sort of it and it's still sort of manual figuring things out. Additionally this only works for errors in the code section, any error anywhere else doesn't have DWARF information so and invalid type, for example, wouldn't have any filename/line number printed.
Otherwise though you're right that the spans don't have any means of making their way into the final binary except for DWARF. I think it'd be reasonable to extend that to get more errors in more places though
Activity
alexcrichton commentedon Feb 6, 2026
One way to achieve half of this (sort of) is the
-g(--generate-dwarf lines) flag onwasm-tools validate:where
validatedoesn't actually emit the binary*.wasmanywhere, but with-gthe text-to-binary transform inserts DWARF debugging information pointing back to the original source so the final error message has a filename/line number/column/etc.Now that being said the error messages still aren't great. While it's got a filename that's sort of it and it's still sort of manual figuring things out. Additionally this only works for errors in the code section, any error anywhere else doesn't have DWARF information so and invalid type, for example, wouldn't have any filename/line number printed.
Otherwise though you're right that the spans don't have any means of making their way into the final binary except for DWARF. I think it'd be reasonable to extend that to get more errors in more places though