[WIP] fuzz: parsing support for #[fuzz] and #[fuzz_param] attributes

[kayagokalp]

DISCLAIMER

Currently still experimenting, will come up with the RFC once that I have a more robust mindset around how to expose this to the user.

---

This PR adds parsing infrastructure for fuzz testing attributes in preparation for future fuzzing capabilities. The implementation follows the same patterns as existing #[test] attributes.

Changes

• Attribute constants: Added FUZZ_ATTRIBUTE_NAME, FUZZ_PARAM_ATTRIBUTE_NAME and parameter names
• AttributeKind variants: New Fuzz and FuzzParam enum variants with proper validation
• Function detection: Updated is_test_function() to include fuzz functions
• Test entry processing: Modified to handle fuzz functions alongside test functions

Usage Examples

Basic fuzz function:

#[fuzz]
fn fuzz_my_function(input: u64) {
    // fuzz test logic
}

With parameters:

#[fuzz]
#[fuzz_param(name = "input", iteration = 1000)]
#[fuzz_param(name = "seed", min_val = 0, max_val = 100)]
fn fuzz_with_params(input: u64, seed: u32) {
    // parameterized fuzz test
}

Implementation Notes

• Functions cannot have both #[test] and #[fuzz] attributes
• #[fuzz] attribute expects no arguments (similar to #[test])
• #[fuzz_param] supports name, iteration, min_val, max_val arguments
• Multiple #[fuzz_param] attributes allowed per function
• Only one #[fuzz] attribute per function

Testing

Added comprehensive test coverage:

• Unit tests for attribute parsing
• E2E tests for valid usage patterns
• Error cases for invalid targets, arguments, and multiplicity

[codspeed-hq]

CodSpeed Performance Report

Merging #7354 will not alter performance

_{Comparing kayagokalp/fuzz-parsing (1722998) with master (1e04b80)}

Summary

✅ 25 untouched benchmarks

[ironcev]

Awesome to see fuzzing coming to life 💪 ❤️

Just a small remark, we have a standardize way of testing attributes.

To adapt tests in this PR, please take a look at should_pass/language/attributes_all_in_one tests. For failing tests that test multiplicity etc., please take a look at should_fail/attributes_invalid_... tests.

Essentially, the separate tests from this PR should be added to those standard tests.

If there is a special logic to be tested, e.g., no #[test] and #[fuzz] attribute together, only then a dedicated test needs to be added. For this we also have examples, like, e.g., attributes_cfg_mismatching_program_type and several other tests.

[kayagokalp]

Awesome to see fuzzing coming to life 💪 ❤️

Just a small remark, we have a standardize way of testing attributes.

To adapt tests in this PR, please take a look at should_pass/language/attributes_all_in_one tests. For failing tests that test multiplicity etc., please take a look at should_fail/attributes_invalid_... tests.

Essentially, the separate tests from this PR should be added to those standard tests.

If there is a special logic to be tested, e.g., no #[test] and #[fuzz] attribute together, only then a dedicated test needs to be added. For this we also have examples, like, e.g., attributes_cfg_mismatching_program_type and several other tests.

Sounds great, will move the tests. I am more in experimenting phase, opened the PR to just talk over it.

Curious to see if you have a preference on how we should enable this? Like should this be an attribute as in this PR or should this interface move to Forc.toml

[ironcev]

Like should this be an attribute as in this PR or should this interface move to Forc.toml

Personally, I am for fixture-based approach where fuzzing is just one of the possible ways to parameterize tests. And everything is attribute-defined. A good example of this would be rstest in Rust.

This is IMO the most general approach that can be stepwise taken in all directions we want, based on the community input and need.

(It is a pity that we don't have macros like Rust and need to implement these attributes in the compiler/tooling, but that's a whole other topic.)

If we go with fixture-based approach (with only attributes implemented at first being case and fuzz), an example would look like this:

#[test] // This is mandatory.
#[case(0, 0)] // Fixed case we are particularly interested in.
#[fuzz(a_iterations = 10, b_min = 42, b_max = 84)] // Additional test casess based on fuzzing input.
fn test(a: u64, b: u64) { ... }

Note that in this case we don't need fuzz_param attribute. The fuzz actually takes over its role. We can brainstorm more how to nicely parameterize the test function arguments, _ approach is just an idea. Also, I expect fuzzing to work with complex types as well, like structs. But those are all things we can develop in steps.