Should `---keep-stage` handle missing stages?

When using ./x.py, the options --keep-stage [n] and --keep-stage-std [n] will terminate with an error if these stages have not already been built. Instead of terminating, it seems like it would be helpful if the command issued a warning and then built the missing stages.

For context, I'm working on a Rust compiler plugin that requires changes to the LLVM backend. Keeping prior stages speeds up build times considerably, so for convenience, we've added a script that passes --keep-stage to ./x.py. However, for this script to work, we've had to add logic to adjust the --keep-stage arguments when one or more stages is missing. We would not need this additional handling if x.py built any missing stages by default instead of terminating.

However, I can also see how this change might be less than ideal if there are situations where it's helpful to terminate with an error immediately when a stage is missing. Or maybe there's a configuration option that would solve this problem already, and I've just missed it.

Are you also skipping --keep-stage whenever you rebase on top of the latest commit on the master branch, whenever you are switching between branches built on top of different commits and whenever the rustc or the standard library source changes in a way that necessitates a rebuild? Or to put it another way: --keep-stage is fragile flag that should only be used when you know for sure that it is safe to use (we print a warning when you do use it for this reason) and should IMHO not be hidden somewhere in a script. As such I don't think we should make any changes to make it more convenient for cases where it is applied automatically rather than manually by the person who (hopefully) knows whether or not it is safe to use.

1 Like

Thank you for the context (and the heads-up on the footguns that are waiting for me)!

Since most of our changes are external to the compiler and we infrequently rebase onto master, we’ve been able to use this quite a bit more liberally than advisable without running into issues. I can see now why automating this step any further (or at all) wouldn’t be a great idea.