Github Label: ICEBreaker-Cleanup-Crew
The “Cleanup Crew” are focused on improving bug reports. Specifically, the goal is to try to ensure that every bug report has all the information that will be needed for someone to fix it:
This kind of cleanup is invaluable in getting bugs fixed. Better still, it can be done by anybody who knows Rust, without any particularly deep knowledge of the compiler.
Let's look a bit at the workflow for doing “cleanup crew” actions.
Here the ultimate goal is to produce an example that reproduces the same problem but without relying on any external crates. Such a test ought to contain as little code as possible, as well. This will make it much easier to isolate the problem.
However, even if the “ultimate minimal test” cannot be achieved, it's still useful to post incremental minimizations. For example, if you can eliminate some of the external dependencies, that is helpful, and so forth.
It's particularly useful to reduce to an example that works in the Rust playground, rather than requiring people to checkout a cargo build.
There are many resources for how to produce minimized test cases. Here are a few:
If you are on the “Cleanup Crew”, you will sometimes see multiple bug reports that seem very similar. You can link one to the other just by mentioning the other bug number in a Github comment. Sometimes it is useful to close duplicate bugs. But if you do so, you should always copy any test case from the bug you are closing to the other bug that remains open, as sometimes duplicate-looking bugs will expose different facets of the same problem.
For regressions (something that used to work, but no longer does), it is super useful if we can figure out precisely when the code stopped working. The gold standard is to be able to identify the precise PR that broke the code, so we can ping the author, but even narrowing it down to a nightly build is helpful, especially as that then gives us a range of PRs. (One other challenge is that we sometimes land “rollup” PRs, which combine multiple PRs into one.)
To help in figuring out the cause of a regression we have a tool called cargo-bisect-rustc. It will automatically download and test various builds of rustc. For recent regressions, it is even able to use the builds from our CI to track down the regression to a specific PR; for older regressions, it will simply identify a nightly.
To learn to use cargo-bisect-rustc, check out this blog post, which gives a quick introduction to how it works. You can also ask questions at the Zulip stream #t-compiler/cargo-bisect-rustc, or help in improving the tool.
If the regression occurred more than 90 days ago, then cargo-bisect-rustc will not able to identify the particular PR that caused the regression, just the nightly build. In that case, we can identify the set of PRs that this corresponds to by using the git history.
The command rustc +nightly -vV will cause rustc to output a number of useful bits of version info, including the commit-hash. Given the commit-hash of two nightly versions, you can find all of PRs that have landed in between by taking the following steps:
git log --author=bors --format=oneline SHA1..SHA2Often, just eye-balling the PR descriptions (which are included in the commit messages) will give you a good idea which one likely caused the problem. But if you're unsure feel free to just ping the compiler team (@rust-lang/compiler) or else to ping the authors of the PR themselves.