Skip to content

Parse and validate text format together #2438

Open

Description

@eqrion

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:

  1. wast could emit a offset -> text span table
  2. wasm-tools parse would optionally validate the resulting binary
  3. 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.

Activity

  1. alexcrichton commented on Feb 6, 2026

    @alexcrichton
    Member

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions