Skip to content

Bring json-from-wast output closer to wast2json#2542

Open
eyupcanakman wants to merge 1 commit into
bytecodealliance:mainfrom
eyupcanakman:fix/json-from-wast-wabt-output
Open

Bring json-from-wast output closer to wast2json#2542
eyupcanakman wants to merge 1 commit into
bytecodealliance:mainfrom
eyupcanakman:fix/json-from-wast-wabt-output

Conversation

@eyupcanakman

Copy link
Copy Markdown
Contributor

json-from-wast differed from wast2json in a few ways. Module names dropped the $ prefix, integer constants printed signed (-1 rather than 4294967295), and the emitted wasm files used the source wast filename stem instead of the -o output stem. All three now match. The expected results for commands like assert_trap are still not emitted. Added a cli test and regenerated the spec snapshots.

Closes #1471.

`json-from-wast` differed from `wast2json` in a few ways. Module names dropped the `$` prefix, integer constants printed signed (-1 rather than 4294967295), and the emitted wasm files used the source wast filename stem instead of the `-o` output stem. All three now match. The expected results for commands like `assert_trap` are still not emitted. Added a cli test and regenerated the spec snapshots.

Closes bytecodealliance#1471.
@eyupcanakman eyupcanakman requested a review from a team as a code owner June 19, 2026 20:32
@eyupcanakman eyupcanakman requested review from alexcrichton and removed request for a team June 19, 2026 20:32
@alexcrichton

Copy link
Copy Markdown
Member

Thanks! The CI failure might be some CRLF thing, but I'm not entirely sure.

Out of curiosity though, could you explain a bit more why you want an exact match? Naively it seems good to strip the leading $ and it seems better to render "-1" instead of u32::MAX. I'm not opposed to these changes necessarily, but for future-selves I think it'd be good to have written down motivation. (even if it's "just because it's nice to byte-for-byte match" if that's the case)

@eyupcanakman

Copy link
Copy Markdown
Contributor Author

It was just to match wast2json more closely, but your question made me check who consumes this, and chicory (which runs json-from-wast) parses the i32/i64 values as signed, so the unsigned change would break their Integer.parseInt (and probably the $-prefix). I'd lean toward trimming this to just the filename fix and dropping the int and name changes, unless you'd rather keep the full match. The Windows fail was a path-separator thing in the test, not CRLF, and I'll fix that.

@alexcrichton

Copy link
Copy Markdown
Member

That sounds reasonable to me, yeah 👍

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

json-from-wast: differences to wabt's wast2json

2 participants