diff --git a/tooling/greybox_fuzzer/src/coverage.rs b/tooling/greybox_fuzzer/src/coverage.rs index 1c06cafc453..5b550116589 100644 --- a/tooling/greybox_fuzzer/src/coverage.rs +++ b/tooling/greybox_fuzzer/src/coverage.rs @@ -743,7 +743,7 @@ pub fn analyze_brillig_program_before_fuzzing( // TODO(Parse constants in brillig and add to the dictionary) | BrilligOpcode::Const { .. } | BrilligOpcode::IndirectConst { .. } - | BrilligOpcode::Return{..} | + | BrilligOpcode::Return | BrilligOpcode::ForeignCall { .. } | BrilligOpcode::Mov { .. } | BrilligOpcode::Load { .. } diff --git a/tooling/greybox_fuzzer/src/mutation/field.rs b/tooling/greybox_fuzzer/src/mutation/field.rs index f73170b48c7..9c019d132b3 100644 --- a/tooling/greybox_fuzzer/src/mutation/field.rs +++ b/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, @@ -12,35 +41,6 @@ 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; diff --git a/tooling/greybox_fuzzer/src/mutation/string.rs b/tooling/greybox_fuzzer/src/mutation/string.rs index 8790218825d..986b70bae4f 100644 --- a/tooling/greybox_fuzzer/src/mutation/string.rs +++ b/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) diff --git a/tooling/nargo_cli/src/cli/check_cmd.rs b/tooling/nargo_cli/src/cli/check_cmd.rs index 80d32cd52b6..f4c0a8e260f 100644 --- a/tooling/nargo_cli/src/cli/check_cmd.rs +++ b/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, .. } => { diff --git a/tooling/nargo_cli/src/cli/fuzz_cmd.rs b/tooling/nargo_cli/src/cli/fuzz_cmd.rs index 5e8cb490321..5b0f2c75d3a 100644 --- a/tooling/nargo_cli/src/cli/fuzz_cmd.rs +++ b/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"); diff --git a/tooling/nargo_cli/src/cli/test_cmd/formatters.rs b/tooling/nargo_cli/src/cli/test_cmd/formatters.rs index 69df19f5a3c..a1c7be1e0ee 100644 --- a/tooling/nargo_cli/src/cli/test_cmd/formatters.rs +++ b/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()?;