Skip to content

Conversation

kripken
Copy link
Member

@kripken kripken commented Aug 27, 2025

I saw a failure where the second module hit a VM limit, so it should be
ignored, but we weren't, and ended up thinking it behaved differently
after merge.

@kripken kripken requested a review from tlively August 27, 2025 14:59
Copy link
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, we could check that the merged output is ignored whenever either of the original modules' output is ignored (or even check more specifically for matching errors).

LGTM if you prefer to keep this simpler, though.

@kripken
Copy link
Member Author

kripken commented Aug 27, 2025

Hmm, I think that isn't guaranteed. We may ignore due to a host limitation, and wasm-merge does some cleanups in the merged module (remove-unused-module-elements). That might make it just pass under a host limit that existed in one of the inputs.

@tlively
Copy link
Member

tlively commented Aug 27, 2025

Makes sense.

@kripken kripken merged commit 5593b32 into WebAssembly:main Aug 27, 2025
15 of 16 checks passed
@kripken kripken deleted the fuzz.merge.ignore branch August 27, 2025 17:18
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.

2 participants