Extra Credit, Minimization, Effective Fuzzing, and Existing Projects

avoid the unfixed ones in `ices/`! ## Extra credit Here are a few things you can do to help the Rust project after filing an ICE. - [Bisect][bisect] the bug to figure out when it was introduced. If you find the regressing PR / commit, you can mark the issue with the label `S-has-bisection`. If not, consider applying `E-needs-bisection` instead. - Fix "distractions": problems with the test case that don't contribute to triggering the ICE, such as syntax errors or borrow-checking errors - Minimize the test case (see below). If successful, you can label the issue with `S-has-mcve`. Otherwise, you can apply `E-needs-mcve`. - Add the minimal test case to the rust-lang/rust repo as a [crashes test]. While you're at it, consider including other "untracked" crashes in your PR. Please don't forget to mark your issue with `S-bug-has-test` afterwards. See also [applying and removing labels][labeling]. ## Minimization It is helpful to carefully *minimize* the fuzzer-generated input. When minimizing, be careful to preserve the original error, and avoid introducing distracting problems such as syntax, type-checking, or borrow-checking errors. There are some tools that can help with minimization. If you're not sure how to avoid introducing syntax, type-, and borrow-checking errors while using these tools, post both the complete and minimized test cases. Generally, *syntax-aware* tools give the best results in the least amount of time. [`treereduce-rust`][treereduce] and [picireny][picireny] are syntax-aware. [`halfempty`][halfempty] is not, but is generally a high-quality tool. ## Effective fuzzing When fuzzing rustc, you may want to avoid generating machine code, since this is mostly done by LLVM. Try `--emit=mir` instead. A variety of compiler flags can uncover different issues. `-Zmir-opt-level=4` will turn on MIR optimization passes that are not run by default, potentially uncovering interesting bugs. `-Zvalidate-mir` can help uncover such bugs. If you're fuzzing a compiler you built, you may want to build it with `-C target-cpu=native` or even PGO/BOLT to squeeze out a few more executions per second. Of course, it's best to try multiple build configurations and see what actually results in superior throughput. You may want to build rustc from source with debug assertions to find additional bugs, though this is a trade-off: it can slow down fuzzing by requiring extra work for every execution. To enable debug assertions, add this to `bootstrap.toml` when compiling rustc: ```toml [rust] debug-assertions = true ``` ICEs that require debug assertions to reproduce should be tagged [`requires-debug-assertions`][requires-debug-assertions]. ## Existing projects - [fuzz-rustc][fuzz-rustc] demonstrates how to fuzz rustc with libfuzzer - [icemaker][icemaker] runs rustc and other tools on a large number of source files with a variety of flags to catch ICEs - [tree-splicer][tree-splicer] generates new source files by combining existing ones while maintaining correct syntax

This section provides guidance on contributing to the Rust project after finding an ICE (Internal Compiler Error), including bisecting the bug, fixing distractions, and minimizing test cases. It details how to effectively minimize fuzzer-generated inputs while preserving the error and avoiding new errors, suggesting tools like `treereduce-rust`, `picireny`, and `halfempty`. The section also gives advice on effective fuzzing of rustc, such as avoiding machine code generation with `--emit=mir`, using compiler flags like `-Zmir-opt-level=4` and `-Zvalidate-mir`, and optimizing compiler builds. Additionally, it mentions existing fuzzing projects like `fuzz-rustc`, `icemaker`, and `tree-splicer`.