en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/generators/instance_allocation_strategy.rs#ba4e22bc Make it easier to reuse fuzzing configuration on the CLI (#10123)* Make it easier to reuse fuzzing configuration on the CLIDuring fuzzing we emit a debug log of configured options to assist withreproducing fuzz test cases outside of the fuzzing harness. Mappingoptions the fuzzer is using though to CLI flags, for example, is a bitof an art though and not obvious. Just today we've got a fuzz bug and Icouldn't figure out how to reproduce on the CLI and it turns out theissue was that I was forgetting a flag that was being configured inresponse to another flag. I got a bit fed up with constantly trying tomap one to the other, so I've decided to fix things.This commit adds a `Display for CommonOptions` implementation to the`wasmtime-cli-flags` crate. This is built on the same macro-constructioninfrastructure of all our flags making it a relatively low one-time-costto implement this. Each option value now implements not only parsing butprinting as well.Next the `wasmtime-fuzzing` crate was updated to create a`CommonOptions` first which is then in turn used to create a`wasmtime::Config`. This provides a layer to insert a log statement withto emit all configuration options in a form that can be easilycopy/pasted to the CLI to reproduce.Overall after doing this I was able to quickly reproduce the bug inquestion (yay!). The CLI flag logging is pretty verbose right now sincethe fuzzing infrastructure sets many settings redundantly to theirdefaults, but reducing flags to a minimum is expected to be relativelyeasy compared to otherwise trying to extract the options.* Fix build and dependencies from wasmtime-fuzzing* Always provide `wasmtime::MpkEnabled`It's an otherwise very small `enum` which makes it easier toconditionally compile `wasmtime-cli-flags`* Frob some crate features some more* Fix specification of `wasmtime_linkopt_force_jump_veneer` option List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/instance_allocation_strategy.rs Mon, 27 Jan 2025 21:34:55 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/generators/instance_allocation_strategy.rs#b14551d7 Refactor configuration for the pooling allocator (#5205)This commit changes the APIs in the `wasmtime` crate for configuring the pooling allocator. I plan on adding a few more configuration options in the near future and the current structure was feeling unwieldy for adding these new abstractions. The previous `struct`-based API has been replaced with a builder-style API in a similar shape as to `Config`. This is done to help make it easier to add more configuration options in the future through adding more methods as opposed to adding more field which could break prior initializations. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/instance_allocation_strategy.rs Fri, 04 Nov 2022 20:06:45 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/generators/instance_allocation_strategy.rs#c227063f fuzz: refactor fuzz generators (#4404)Previously, much of the logic for generating the various objects needed for fuzzing was concentrated primarily in `generators.rs`. In trying to piece together what code does what, the size of the file and the light documentation make it hard to discern what each part does. Since several generator structures had been split out as separate modules in the `generators/` directory, this change takes that refactoring further by moving the structures in `generators.rs` to their own modules. No logic changes were made, only the addition of documentation in a few places. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/instance_allocation_strategy.rs Thu, 07 Jul 2022 18:44:27 +0000 Andrew Brown <andrew.brown@intel.com>