Stream: git-wasmtime

Topic: wasmtime / issue #4537 implement fuzzing for component types

Wasmtime GitHub notifications bot (Jul 29 2022 at 16:53):

dicej commented on issue #4537:

This is ready for another review. Per https://github.com/bytecodealliance/wasmtime/issues/4307#issuecomment-1199624852, CI will be broken until we've enabled the component-model feature unconditionally when testing.

Wasmtime GitHub notifications bot (Jul 29 2022 at 18:14):

alexcrichton commented on issue #4537:

Also it looks like you may have had to deal with a lot of Cargo features and conditional compilation in this PR to get fiddly bits to work. I think it's fine to say that during testing we can assume that the component model is unconditionally enabled and hopefully avoid too much of a maze of optional dependencies and such.

Wasmtime GitHub notifications bot (Jul 29 2022 at 21:41):

dicej commented on issue #4537:

I've addressed a few of the issues above. Planning to work on the rest on Monday.

Wasmtime GitHub notifications bot (Aug 01 2022 at 16:16):

alexcrichton commented on issue #4537:

Also to get a head start on deduplicating internally within the codebase, could you update the fact-valid-module fuzzer to using this new enum Type in the component-fuzz-util crate?

During the intern phase of that fuzzer not all types are supported yet so I think it would be fine to return a Result from interning and "throw out" test cases with unsupported types (e.g. lists/strings at the time of this writing)

Wasmtime GitHub notifications bot (Aug 02 2022 at 16:53):

dicej commented on issue #4537:

@alexcrichton I believe I've addressed all your latest feedback (deferring func_new API changes for later). And yes, I've run the fuzz tests for an hour or so without issue.

Last updated: Dec 23 2024 at 12:05 UTC