Skip to content
17 changes: 17 additions & 0 deletions tooling/ast_fuzzer/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,3 +39,20 @@ cargo +nightly fuzz run acir_vs_brillig fuzz/artifacts/acir_vs_brillig/crash-927
Note that `cargo fuzz` requires `nightly` build, which can be either turned on with the `cargo +nightly` flag, or by running `rustup default nightly`. Also note that `cargo fuzz run` automatically creates a `--release` build, there is no need for an explicit flag to be passed.

The `NOIR_AST_FUZZER_SHOW_AST` env var can be used to print the AST before compilation, in case the compiler crashes on the generated program. Otherwise if the execution fails, the output will include the AST, the inputs, and the ACIR/Brillig opcodes.

## `arbtest`

To get quick feedback about whether there are any easy-to-discover bugs, we can run the following test:

```shell
cargo test -p noir_ast_fuzzer_fuzz arbtest
```

Unlike `cargo fuzz`, these don't "ramp up" the complexity of the code, but go full tilt from the beginning, and only run for a limited amount of time (e.g. 10 seconds). Upon failure they print a hexadecimal `seed`, which can be used with the `NOIR_ARBTEST_SEED` env var to replicate the error.

## Minimizing Noir

At the moment test failures end up with one or two Noir-like AST printed on the console, with the corresponding ABI formatted inputs.
We can turn these into `nargo` projects to replicate the problem that causes the error.

Especially with the `arbtest` mentioned above, the Noir AST can be big, certainly much larger than what we would want to put in a bug ticket. If that is the case, we can try minimizing the example with the [Noir Minimizer](./minimizer/README.md) tool.
Loading
Loading