Update cargo-fuzz setup; split fuzz_value_sanitize so it runs

[moodmosaic]

This makes clarity/fuzz/ build and actually run on nightly. It also moves fuzz_value_sanitize into its own target so cargo-fuzz detects and runs it. Diff kept minimal.

Notes:

• This fixes compiler errors to keep Expand input coverage with fuzzing #6355 moving.
• I haven’t reviewed what these existing fuzz targets actually test. They’ve been in the repo for some time. I kept the diff minimal to get them compiling and running.

How to:

• List: cargo +nightly fuzz list
• Build all: cargo +nightly fuzz build
• Build one: cargo +nightly fuzz build fuzz_sanitize
• Build one: cargo +nightly fuzz build fuzz_value_sanitize
• Run: cargo +nightly fuzz run fuzz_sanitize
• Run: cargo +nightly fuzz run fuzz_value_sanitize

[moodmosaic]

/cc @BowTiedRadone

[fdefelici]

I’ve added a bunch of comments about the workflows.

I’d also like to raise a broader structural idea: instead of keeping the fuzz folder nested inside the clarity crate, would it make sense to move it under the contrib/ folder?

We could, for example, introduce a dedicated fuzzing/ folder inside contrib/, which could later house multiple fuzzers as we expand coverage. The current clarity/fuzz would simply become one of them:

contrib/  
    fuzzing/  
        clarity-fuzzer/   (current clarity/fuzz)  
        other1-fuzzer/  
        other2-fuzzer/  
        ...

This would avoid nested crates inside clarity, make the structure more consistent, and give us room to organize future fuzzers without cluttering core crates.

If we agree this structure is beneficial, we could address it in this PR. The effort should be minimal, and since we’re already restoring the old fuzzer, could be the right time to make this change.

[fdefelici]

It’s not entirely clear why this workflow requires this input. Could you elaborate?

We might consider simplifying by hardcoding the version in the fuzz-targets job or by using an environment variable instead.

[moodmosaic]

Yes, cargo fuzz needs nightly. However we could follow the rule of three and inline it for now directly in the job.

[fdefelici]

The fuzz-targets job doesn’t actually need the setup dependency, as it completely overrides the toolchain parameter with its own value.
We might consider removing this dependency to make clear the intent.

[moodmosaic]

Yes, this doesn’t use any outputs from setup. 👍

[fdefelici]

Maybe cache key is too narrow. If nightly version changes, we could get stale caches that fail to build because dependencies or the compiler version mismatch

[moodmosaic]

Perhaps

fuzz-${{ inputs.rust-nightly-version }}-${{ hashFiles('clarity/fuzz/Cargo.lock') }}

or something like

fuzz-${{ inputs.rust-nightly-version }}-${{ runner.os }}-${{ hashFiles('clarity/fuzz/Cargo.lock') }}

We'll have to try.

[fdefelici]

Could we use check here instead of build?
Since the objective is only to verify whether it compiles, this would be faster and more aligned with the purpose of the workflow.

[moodmosaic]

Good catch. I always do cargo +nightly fuzz build but here check would be more efficient.

[moodmosaic]

instead of keeping the fuzz folder nested inside the clarity crate, would it make sense to move it under the contrib/ folder?

Right now it makes more sense to keep the fuzz folder inside the clarity crate.

That way it matches how we handle example-based and property-based tests, and keeps fuzzing a first-class part of the folder/crate rather than something tucked away in contrib/.

Also, with this structure, cargo fuzz works naturally from the crate root without needing --manifest-path.

Moving it under contrib/ pays off when/if we had multiple independent fuzzers with shared arbitraries. Until then, local fuzz targets keep the workflow simple: "open the crate and see all its tests, including fuzz".

I think it’s a good idea to tackle reorganizing later, once we add more fuzzers, so we can keep #6355 moving.