Skip to content

Conversation

@sjamesr
Copy link
Contributor

@sjamesr sjamesr commented Nov 11, 2025

WASM v3 spec tests added the '(module definition ...)' construct to WAST. This tells the test runner that the module should not be instantiated immediately. The '(module instance ...)' construct (not yet supported in wabt) instructs the test runner to instantiate the module.

This change adds an is_definition field to ScriptModule. The field reflects whether the definition keyword was encountered after the module keyword.

When WastParser encounters a TextModule in a script command, it now returns a ScriptModule with the corresponding ScriptTextModule if the module is definition-only.

This change allows wabt to parse WASM v3 spec tests that use the (module definition ...) construct (specifically, memory.wast), so that test runners built on wabt can support WASM v3 spec tests.

@sjamesr sjamesr force-pushed the module_definition_support branch from 121d68d to 4c1f42a Compare November 11, 2025 18:50
@sbc100
Copy link
Member

sbc100 commented Nov 11, 2025

@zherczeg, have you run into this in any of your recent wasm-3.0 work on wabt? Is it part of one of you in-flight PRs maybe?

@sbc100
Copy link
Member

sbc100 commented Nov 11, 2025

Is (module instance ...) the default behaviour? i.e. if you don't specify either instance or definition?

@sjamesr
Copy link
Contributor Author

sjamesr commented Nov 11, 2025

As far as I know, (module instance $x) instructs the test runner to instantiate a module that was defined like (module definition $x ...).

(module instance ...) is not allowed to have the actual definition.

@zherczeg
Copy link
Contributor

No, this is not used by the GC proposal. I plan to continue working on WASM 3.0 later.

@sbc100
Copy link
Member

sbc100 commented Nov 11, 2025

@sjamesr have you verified this fix works for your external use case? If so then landing this now (even though we don't need to locally) does not seem unreasonable.

@sbc100
Copy link
Member

sbc100 commented Nov 11, 2025

Could you perhaps update the PR description mentioning why this is useful to you even though wabt itself doesn't currently use this?

WASM v3 spec tests added the '(module definition ...)' construct to
WAST. This tells the test runner that the module should not be
instantiated immediately. The '(module instance ...)' construct (not yet
supported in wabt) instructs the test runner to instantiate the module.

This change adds an `is_definition` field to ScriptModule. The field
reflects whether the `definition` keyword was encountered after the
`module` keyword.

When WastParser encounters a TextModule in a script command, it now
returns a ScriptModule with the corresponding ScriptTextModule if the
module is definition-only.

This change allows wabt to parse WASM v3 spec tests that use the
`(module definition ...)` construct (specifically, `memory.wast`), so
that test runners built on wabt can support WASM v3 spec tests.
@sjamesr sjamesr force-pushed the module_definition_support branch from 4c1f42a to f645678 Compare November 11, 2025 19:22
@sjamesr
Copy link
Contributor Author

sjamesr commented Nov 11, 2025

I added a paragraph to the commit and PR descriptions.

I haven't actually tried it out against the v3 spec yet, so perhaps we can hold off on merging the request. I'll continue working on the assumption that we'll merge it or something like it. Just knowing that it's generally acceptable is useful, thanks!

@sbc100
Copy link
Member

sbc100 commented Nov 11, 2025

The patch LGTM. If you are OK with waiting for our own wasm-3.0 update (not sue how long that might be sadly) that might be best, since then it will get a some real testing.

If you need the landed earlier thats probably fine too, just let us know,

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.

3 participants