Keep fuzz inputs for older branches

[ekzyis]

close #265

see comment below for more information

[ekzyis]

4babc48 looks good to me now. Updated PR description.

I ran this against a test fuzz corpora in ekzyis@a4ef010 (a different branch) to speed things up. Took 30 minutes with --extra-ref v30.2 --extra-ref v29.3. To do the same, run this in the VM:

$ git clone --depth=1 --branch=test-keep-fuzz-inputs-for-older-branches https://github.com/ekzyis/qa-assets
$ cp -r qa-assets/delete-nonreduced-fuzz-inputs .
$ cd delete-nonreduced-fuzz-inputs
$ sudo cargo run -- --extra-ref v30.2 --extra-ref v29.3

I had to allow empty commits because fuzzing another ref might not lead to any new fuzz inputs.

[maflcko]

lgtm, just some nits

[ekzyis]

Thanks for the review! I didn't squash the commits yet. I thought it would make the next review easier.

I'm currently debugging why I can't use fs::remove_dir, see #274 (comment).

[ekzyis]

Squashed all commits into 4373c77.

Btw, I didn't make sure that libFuzzer will only add fuzz targets to the output directory, and not delete the ones in the output directory that don't increase coverage for the fuzzed binary. I only looked at the documentation for -merge, and it doesn't mention it would:

You may use the same flag to add more interesting items to an existing corpus. Only the inputs that trigger new coverage will be added to the first corpus.

For -set_cover_merge, which is what we're using, I only found this comment in the source code:

// Merges all corpora into the first corpus. A file is added into
// the first corpus only if it adds new features. Unlike `Merger::Merge`,
// this implementation calculates an approximation of the minimum set
// of corpora files, that cover all known features (set cover problem).
// Generally, this means that files with more features are preferred for
// merge into the first corpus. When two files have the same number of
// features, the smaller one is preferred.
size_t Merger::SetCoverMerge(const std::set<uint32_t> &InitialFeatures,

[maflcko]

heh, I guess there could be a check to see if the file to exists, and then delete from. Otherwise, keep the move. This would allow to use remove_dir, but not important. Either way is fine.