I think this article probably deserves a passing mention to the classic tool for reducing compiler bug cases, creduce [1]. I know it's used for rust or at least it can be used for rust.

It uses delta debugging [2] to minimize the reproducer, and AFAIK doesn't know about Rust. But it could be taught these rust-specific transformations.

[1] https://embed.cs.utah.edu/creduce/

[2] https://en.wikipedia.org/wiki/Delta_debugging

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.

This is called "Test-case reduction". Bug minimisation would be about reducing the number/severity of bugs in code.

> But it not always easy to toggle such comments on and off

Try:

  /*-* /
  non_pub_locally_unused_item(----) { ---- }
  //-*/

remove the space on the first line to re-enable it.

For A/B testing, I use this in C++; it looks like it works in rust (according to my syntax highlighter):

  //* //add/delete the first slash to toggle these blocks
  fooA();
  /*/
  fooB();
  /**/

I like this for C/C++:

  #if 1 // or 0
  A
  #else
  B
  #endif

This can even be nested.

This is so overwhelmingly better in every conceivable way that there is no excuse for ever using the other thing. (Unless you are using Rust and don't have it?)

Yeah, that's good too. When I don't need nesting, I like toggleable comments because the inactive block gets grayed out.

Some editors like vim also grey out the text with "#if".

Good job