feature request: support list of generic args

[0xalpharush]

If I have fn roundtrip<T>, I would think test-fuzz can maintain a separate corpus for each T, and generate an entrypoint for each one. However, I must specify T e.g. #[test_fuzz(generic_args = "String")] and can only provide one type as a list will fail to be parsed by the proc macro.

It would be nice to generate a binary for each generic arg in the list and be able to run all of them without having to replace the type manually. Maybe I am missing a better way to do this...

[smoelius]

Hey, @0xalpharush. This is an interesting idea. If we were to implement it, though, I think it should be opt-in. Currently, inputs are dumped into the same corpus directory regardless of generic args. This has the advantage that those inputs can serve as seeds for any generic args, even ones that were not observed during testing.

Minor point, but we would need a strategy for turning generic args into directory names.

However, I must specify T e.g. #[test_fuzz(generic_args = "String")] and can only provide one type as a list will fail to be parsed by the proc macro.

As a workaround, you could create a different entry point for each generic arg, and create their corpus directories by manually copying the one that was recorded for the generic function.

So your multiple entry points would look something like this:

#[test_fuzz::test_fuzz] // for harness generation only; corpus created manually
fn foo_X(x: X) { foo(x); }

#[test_fuzz::test_fuzz] // for harness generation only; corpus created manually
fn foo_Y(y: Y) { foo(y); }

...

#[test_fuzz::test_fuzz]
fn foo<T>(value: T) { ... }

[0xalpharush]

If I do #[test_fuzz::test_fuzz] fn foo<T>(value: T) { ... }, I believe the proc macro must be redefining it and it errors with cannot find function "foo" in this scope. So all of the call-sites in tests need to be replaced with foo_X, foo_Y etc. But this accomplishes what I wanted. Thanks!