Valentin Huber

> PRs welcome :) Not sure you want a PR based on my understanding :D. This also seems related to #833, which is still a good idea imo.

Besides the optional improvements outlined above, I think this is done.

> One other thing: It'd be pretty amazing to #[derive] mappings for each sub part of an input (maybe even recursiveley), so we suddenly end up with a cheap grammar...

I see — thank you for your suggestion! I think I personally would prefer the simplicity of my initial version for most inputs. If you look at the file `havoc_mutations.rs`,...

No worries – I hope you enjoyed your time off! > The issue is that your version only works with Vec which is very inflexible. Fair enough, this is the...

Also: I attempted to merge main and saw that for some reason, `StdScheduledMutator` will no longer accept a `tuple_list` of mutators that got `append`ed. Haven't had time to investigate, might...

I'm not quite sure I understand where you'd need flexibility that isn't available with the system in this PR. Could you provide an example? Maybe one where you struggled with...

I think I understood what you mean. I added `MutVecFunctionMappingMutator`, where a user needs to provide a mapping function with type `for MutVecInput { MutVecInput::from(&mut self.byte_array_custom_mapper) } pub fn byte_array_custom_mapper_corpus_extractor(&self)...

I finally figured out how to do this a bit more generic, for all these types that are essentially just wrappers around a reference to implement traits. This should work...

We can (and at least I will) have multiple wrappers per input. Even two ways to do so: - Add one set of mapped havoc_mutations per byte array type sub-part...