Spawned off of #26484
Just as it is important to developers that we try to avoid injecting test regressions (and thus we have bors check that the regression test suite passes before every commit to master), it is also important to developers that the debug-enabled build of rustc actually be able to bootstrap.
Unfortunately, none of the current bots build with --enable-debug. This is justifiable as a default setting, since it is more important to ensure that Rust work in its "release" configuration, and for that, the default of --disable-debug --enable-optimize for the bots makes sense. However, it also means that none of the bots are ensuring that rustc can bootstrap under a --enable-debug configuration.
Fallback Idea: if it is determined that --enable-debug is too slow for a bot, even if it just doing a bootstrap (and not running the test suite), then as a fallback we could instead just do the build with RUST_FLAGS=-g; this would also address the problem that was exposed by #26484, I think. I have not checked that latter claim formally, but based on the investigation, it seems like it is a problem solely with mixing -g and LLVM assertions, which are enabled on the nightly channel IIRC, and not e.g. with the assertions and consistency checks injected by a --enable-debug build.
Spawned off of #26484
Just as it is important to developers that we try to avoid injecting test regressions (and thus we have bors check that the regression test suite passes before every commit to master), it is also important to developers that the debug-enabled build of
rustcactually be able to bootstrap.Unfortunately, none of the current bots build with
--enable-debug. This is justifiable as a default setting, since it is more important to ensure that Rust work in its "release" configuration, and for that, the default of--disable-debug --enable-optimizefor the bots makes sense. However, it also means that none of the bots are ensuring thatrustccan bootstrap under a--enable-debugconfiguration.Fallback Idea: if it is determined that
--enable-debugis too slow for a bot, even if it just doing a bootstrap (and not running the test suite), then as a fallback we could instead just do the build withRUST_FLAGS=-g; this would also address the problem that was exposed by #26484, I think. I have not checked that latter claim formally, but based on the investigation, it seems like it is a problem solely with mixing-gand LLVM assertions, which are enabled on the nightly channel IIRC, and not e.g. with the assertions and consistency checks injected by a--enable-debugbuild.