cargo-llvm-lines VS cargo-bisect-rustc

This is a livestream, the "offline" artefact is a function of that but not the primary one. Jon essentially uses livestreams as exploratory labs / presentations, and even ignoring the regular Q&As audience interaction is both common and commonly useful there — for instance in this one /u/dtolnay suggests something about cargo-llvm-lines as Jon is working with it.

If you want to dig further, I see though that some of this time is spent in codegen (generating LLVM IR) and in LLVM. Maybe something is generating much more IR than before, which then takes a lot of time to process. Another tool is https://github.com/dtolnay/cargo-llvm-lines which shows the number of lines of unoptimized LLVM IR for each of your functions. In general it can be useful to optimize compile times of your project, in this case it might show which area of your code triggers this bug.

cargo llvm-lines, too.

> One big downside is losing the ability to build any commit from source without meta-complexity creeping in. For example, let’s say that you are trying to do git bisect. At some point, git checks out an older commit, but the script fails to build from source because the binary that is being used to build the compiler is now the wrong version. Sure, this can be addressed, but this introduces unwanted complexity that contributors would rather not deal with.

If it's the main concern of using a prior build of the compiler, an alternative solution is to develop a tool for contributors to automate and ease the process. For example, Rust has this: https://github.com/rust-lang/cargo-bisect-rustc

Added support for tools like cargo-bisect-rustc.

Finally, https://github.com/rust-lang/cargo-bisect-rustc/blob/master/TUTORIAL.md can bisect Nightlies or (if recent enough, I think CI artifacts are kept 3 months) PRs to tell you one introduced a problem.