Open daprilik opened 1 year ago
...though, after toying around with the feature for a bit, I will mention that it results in quite a lot of re-complation when switching between fuzzzing and fuzzing-repro flows.
Maybe its worth reconsidering the current approach, and switching to something like a CARGO_FUZZ_REPRO env-var instead?
...yeah, the constant recompilation really isn't great.
I would really prefer reconsidering the --cfg fuzzer_repro
approach, and swapping it out with an env-var instead.
I don't think the performance difference is too bad, especially if one does something like:
static IS_REPRO: OnceLock<bool> = OnceLock::new();
pub fn is_repro() -> bool {
*IS_REPRO.get_or_init(|| std::env::var("CARGO_FUZZ_REPRO").is_ok())
}
EDIT: See subsequent comments. Original title: "Publish release with
cfg(fuzzing_repro)
"This feature is already documented in the guide, so it was quite puzzling when it didn't seem to work after I ran
cargo install cargo-fuzz
!Any chance you could cut a new release with
fuzzing_repro
support?This is something I'm quite interested in using, and I'd like to avoid taking a dependency on a particular
cargo-fuzz
git commit :)