c-reduce has been a godsend for me when I’ve had to figure out the cause of C++ compiler crashes. Manual minimization may be semi-mindless, but for that very reason it’s really boring, and it takes forever. So much nicer to sic c-reduce at it, take a snack break, and most of the time come back to a nice minimal reproducer. (Though at least once it ended up reproducing a different compiler crash than the one in the original code… Oh well.)

I’d love if there was a Rust version. In addition to Rust-specific transformations, you’d probably want to teach it how to simplify an entire crate dependency tree, involving multiple rustc invocations, rather than just one file. C/C++ header files may be crude, but they have an advantage here: after running a source file through the preprocessor, you end up with a completely self-contained file that (probably) behaves the same way. Thus you only need to reduce that one file, and AFAIK that’s all c-reduce supports. Also, for anything that is declared in a header file but defined in a different source file, c-reduce doesn’t need to know or care about the definition; if the compiler crash occurred on a source file not containing the definition, then the definition can’t be responsible. Rust doesn’t have that kind of natural separation, but maybe aggressively emptying out function bodies would be a good enough substitute.

> Though at least once it ended up reproducing a different compiler crash than the one in the original code

I use creduce a lot and this experience is not at all uncommon. The fix is to make your interestingness test very specific.

the title for one of the creduce papers starts with "test-case reduction", which i think is clearer terminology than "bug minimisation". "bug minimisation" sounds like it is focusing on reducing the number of defects or something, which this isn't (directly) about.