Skip to content

Add compact import generation in wasm-smith - #2627

Open
chacailline wants to merge 2 commits into
bytecodealliance:mainfrom
chacailline:compact-imports
Open

Add compact import generation in wasm-smith#2627
chacailline wants to merge 2 commits into
bytecodealliance:mainfrom
chacailline:compact-imports

Conversation

@chacailline

@chacailline chacailline commented Aug 27, 2026

Copy link
Copy Markdown

Updates wasm-smith to generate compact import sections.

Allows wasmtime fuzzing of compact import sections for bytecodealliance/wasmtime#14108.

Module::imports_exports_from_module_shape and Module::arbitrary_imports_from_available are also updated to accept compact imports and to generate them when it's enabled in the config.

I enabled the proposal by default. config.rs has a comment saying "Proposals that are not stage4+ are disabled by default." By that logic, we may want to enable wide arithmetic by default too.

Outside of #[cfg(feature = "component-model")], DuplicateImportsBehavior::Disallowed was only ever created in an if-test in Module::arbitrary_imports, so I had to add a #[cfg] gate to pass CI.

The binary format supports empty compact import statements, but it's not clear whether the text format will support them. See WebAssembly/compact-import-section#22. Currently, wasmparser doesn't accept them, but wasmprinter outputs them if given a binary with empty statements.

For now, I don't generate empty statements. If they're not allowed, we should update wasmprinter not to generate them. If they are allowed, we should update wasmparser to accept them, and probably generate them in wasm-smith.

@chacailline
chacailline requested a review from a team as a code owner August 27, 2026 03:27
@chacailline
chacailline requested review from alexcrichton and removed request for a team August 27, 2026 03:27
@chacailline

Copy link
Copy Markdown
Author

Module::arbitrary_imports gained some complexity because we have to check constraints in the nested loops too. We also can't use arbitrary_loop for the outer loop. We could for the inner loops, but I didn't think it would be any cleaner.

Module::arbitrary_imports_from_available instead generates all imports to start, then decides whether to group adjacent ones with the same module / type. This is cleaner, but if we did it with random module / type names, I think we would almost never generate any compact imports with more than 1 element.

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.

1 participant