cfg(fuzzing_repro) causes unnecessary recompilations, switch to CARGO_FUZZ_REPRO env var instead?

[daprilik]

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 :)

[daprilik]

...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?

[daprilik]

...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())
}