chore: clippy fixes

tooling/greybox_fuzzer/src/coverage.rs

@@ -5,7 +5,7 @@
 //! There are several mechanisms for coverage being used:
 //! 1. Standard branch coverage taken from brillig, the same as with standard, non-zk programs (detects which branch has been taken in an if)
 //! 2. Conditional move coverage from brillig
 //! 3. Novel boolean witness coverage. If ACIR execution was successful, we scan the witness for potential boolean values and detect interesting testcases, if we discover a boolean witness with a state that hasn't been previously encountered.
 
 use std::collections::{HashMap, HashSet};
 use std::hash::Hash;
@@ -150,7 +150,7 @@
 
 pub type BrilligCoverageRanges = Vec<BrilligCoverageItemRange>;
 
 /// Raw brillig coverage is just a buffer of uints that contain counters
 pub type RawBrilligCoverage = Vec<u32>;
 
 /// Information about the coverage of a single testcase execution
@@ -199,8 +199,8 @@
 pub struct AccumulatedSingleBranchCoverage {
     /// A bitmask of encountered powers of 2 of repetitions of this branch
     encountered_loop_log2s: u32,
     /// Which testcases showed log2 behavior
     testcases_involved: [Option<TestCaseId>; 32],
     /// The maximum number of iterations of this branch encountered in a single execution
     encountered_loop_maximum: u32,
     /// Testcase that produced the maximum iterations count
@@ -214,8 +214,8 @@
 pub struct AccumulatedCmpCoverage {
     /// How many time during a single execution this comparison had the difference between arguments be this power of 2
     encountered_loop_log2s: u32,
     /// Which testcases exhibited this behavior
     testcases_involved: [Option<TestCaseId>; 32],
     /// The maximum number of iterations of this comparison with this difference log encountered in a single execution
     encountered_loop_maximum: u32,
     /// Which testcase exhibited this behavior
@@ -234,7 +234,7 @@
 pub struct AccumulatedFuzzerCoverage {
     /// All observed states of boolean witnesses
     acir_bool_coverage: HashSet<AcirBoolState>,
     /// Testcases in which the boolean states have been observed
     bool_state_to_testcase_id: HashMap<AcirBoolState, TestCaseId>,
     /// Branch coverage in brillig that has been observed
     brillig_branch_coverage: Vec<AccumulatedSingleBranchCoverage>,
@@ -743,7 +743,7 @@
             // TODO(Parse constants in brillig and add to the dictionary)
             | BrilligOpcode::Const { .. }
             | BrilligOpcode::IndirectConst { .. }
-            | BrilligOpcode::Return{..} |
+            | BrilligOpcode::Return |
             BrilligOpcode::ForeignCall { .. }
             | BrilligOpcode::Mov { .. }
             | BrilligOpcode::Load { .. }

tooling/greybox_fuzzer/src/mutation/field.rs

@@ -1,3 +1,32 @@
+//! This file contains mechanisms for deterministically mutating a given field value
+//! Types of mutations applied:
+//! 1. Substitutions
+//!     1. With zero
+//!     2. With one
+//!     3. With minus one
+//!     4. With a value from the dictionary (created from analyzing the code of the program and testcases in the corpus)
+//!     5. With a power of 2
+//!     6. With a power of 2 minus 1
+//! 2. Inversions
+//!     1. Negation
+//!     2. Multiplicative inverse
+//! 3. Update with a value that is a power of 2
+//!     1. Addition
+//!     2. Subtraction
+//!     3. Multiplication
+//!     4. Division
+//! 4. Update with a small (1-255) value
+//!     1. Addition
+//!     2. Subtraction
+//!     3. Multiplication
+//! 5. Update with a dictionary value
+//!     1. Addition
+//!     2. Subtraction
+//!     3. Multiplication
+//!
+//! There are configurations for determining probability of each top-level and low-level mutation
+//! Currently, the configurations are constant and "new" methods aren't used, but the architecture is prepared for easier introduction of MOpt (Mutation Optimization) technique in the future
+
 use super::configurations::{
     BASIC_FIELD_ELEMENT_DICTIONARY_UPDATE_CONFIGURATION,
     BASIC_FIELD_ELEMENT_POW_2_UPDATE_CONFIGURATION,
@@ -10,37 +39,8 @@
 use acvm::{AcirField, FieldElement};
 use noirc_abi::input_parser::InputValue;
 use rand::{Rng, seq::SliceRandom};
 use rand_xorshift::XorShiftRng;
 
-/// This file contains mechanisms for deterministically mutating a given field value
-/// Types of mutations applied:
-/// 1. Substitutions
-///     a. With zero
-///     b. With one
-///     c. With minus one
-///     d. With a value from the dictionary (created from analyzing the code of the program and testcases in the corpus)
-///     e. With a power of 2
-///     f. With a power of 2 minus 1
-/// 2. Inversions
-///     a. Negation
-///     b. Multiplicative inverse
-/// 3. Update with a value that is a power of 2
-///     a. Addition
-///     b. Subtraction
-///     c. Multiplication
-///     d. Division
-/// 4. Update with a small (1-255) value
-///     a. Addition
-///     b. Subtraction
-///     c. Multiplication
-/// 5. Update with a dictionary value
-///     a. Addition
-///     b. Subtraction
-///     c. Multiplication
-///
-/// There are configurations for determining probability of each top-level and low-level mutation
-/// Currently, the configurations are constant and "new" methods aren't used, but the architecture is prepared for easier introduction of MOpt (Mutation Optimization) technique in the future
-///
 const SMALL_VALUE_MAX: u64 = 0xff;
 const SMALL_VALUE_MIN: u64 = 1;
 
@@ -54,7 +54,7 @@
 
 struct FieldMutator<'a> {
     dictionary: &'a Vec<FieldElement>,
     prng: &'a mut XorShiftRng,
 }
 
 impl<'a> FieldMutator<'a> {

tooling/greybox_fuzzer/src/mutation/string.rs

@@ -18,13 +18,13 @@ use std::cmp::min;
 
 /// This file contains mechanisms for mutating string InputValues. It can perform the following mutations:
 /// 1. Value mutations
-///     a. Substitution a random character in the string with a random appropriate value from the dictionary
-///     b. Substitution of a random character with a random character
+///     1. Substitution a random character in the string with a random appropriate value from the dictionary
+///     2. Substitution of a random character with a random character
 /// 2. Structural mutations
-///     a. Chaotically splicing the string with itself (constructing a new string from random chunks of initial string)
-///     b. Duplication of a random chunk (picking a chunk of the string and inserting it several times)
-///     c. Inserting a repeated random value
-///     d. Swapping two chunks
+///     1. Chaotically splicing the string with itself (constructing a new string from random chunks of initial string)
+///     2. Duplication of a random chunk (picking a chunk of the string and inserting it several times)
+///     3. Inserting a repeated random value
+///     4. Swapping two chunks
 ///
 /// It also contains the splicing mechanism used when splicing two inputs. It chooses between:
 /// 1. Structured splicing (preserving the indices of the values)

tooling/nargo_cli/src/cli/check_cmd.rs

@@ -124,9 +124,8 @@ fn create_input_toml_template(
     fn default_value(typ: AbiType) -> toml::Value {
         match typ {
             AbiType::Array { length, typ } => {
-                let default_value_vec = std::iter::repeat(default_value(*typ))
-                    .take(length.try_into().unwrap())
-                    .collect();
+                let default_value_vec =
+                    std::iter::repeat_n(default_value(*typ), length.try_into().unwrap()).collect();
                 toml::Value::Array(default_value_vec)
             }
             AbiType::Struct { fields, .. } => {

tooling/nargo_cli/src/cli/fuzz_cmd.rs

@@ -362,13 +362,13 @@ fn display_fuzzing_report_and_store(
     writer.flush().expect("Failed to flush writer");
 
     match &status {
-        FuzzingRunStatus::ExecutionPass { .. } => {
+        FuzzingRunStatus::ExecutionPass => {
             writer
                 .set_color(ColorSpec::new().set_fg(Some(Color::Green)))
                 .expect("Failed to set color");
             writeln!(writer, "ok").expect("Failed to write to stderr");
         }
-        FuzzingRunStatus::MinimizationPass { .. } => {
+        FuzzingRunStatus::MinimizationPass => {
             writer
                 .set_color(ColorSpec::new().set_fg(Some(Color::Green)))
                 .expect("Failed to set color");

tooling/nargo_cli/src/cli/test_cmd/formatters.rs

@@ -16,9 +16,9 @@ use super::TestResult;
 /// 3. For each test, one `test_start_async` event
 ///    (there's no `test_start_sync` event because it would happen right before `test_end_sync`)
 /// 4. For each package, sequentially:
-///     a. A `package_start_sync` event
-///     b. One `test_end` event for each test
-///     a. A `package_end` event
+///     1. A `package_start_sync` event
+///     2. One `test_end` event for each test
+///     3. A `package_end` event
 ///
 /// The reason we have some `sync` and `async` events is that formatters that show output
 /// to humans rely on the `sync` events to show a more predictable output (package by package),
@@ -116,7 +116,7 @@ impl Formatter for PrettyFormatter {
         writer.flush()?;
 
         match &test_result.status {
-            TestStatus::Pass { .. } => {
+            TestStatus::Pass => {
                 writer.set_color(ColorSpec::new().set_fg(Some(Color::Green)))?;
                 write!(writer, "ok")?;
                 writer.reset()?;
@@ -138,7 +138,7 @@ impl Formatter for PrettyFormatter {
                     );
                 }
             }
-            TestStatus::Skipped { .. } => {
+            TestStatus::Skipped => {
                 writer.set_color(ColorSpec::new().set_fg(Some(Color::Yellow)))?;
                 write!(writer, "skipped")?;
                 writer.reset()?;