Buildbot Request: Add one --enable-debug --enable-optimize bot that at least bootstraps (no tests)

[pnkfelix]

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.

[pnkfelix]

See also #17166 (but this is not a dupe of that bug, despite my somewhat misleading comment on that ticket -- #17166 is about no-opt builds, while #27010 is solely about --enable-debug --enable-optimize builds).

[pnkfelix]

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

The above really is a very weak fallback plan. In particular, it would not catch bugs like: #27023

[edunham]

Notes from discussing this in a meeting: Ideally even just bootstrap with enable_debug, without running tests if tests are slow, and gate merge on enable_debug enable_optimize bootstrap succeeding. Nothing tests a full bootstrap with -g that we know of yet -- needs feedback from @alexcrichton

[alexcrichton]

This all sounds good to me, just needs a bot set up which unfortunately takes a good deal of work currently :(

[huonw]

Is setting up a new bot any easier now?

[alexcrichton]

A builder has now been added but the build is currently red

[pnkfelix]

Yes we need to first fix #28947 (at least), or revert the PR that exposed that (bleah)

[sanxiyn]

#28947 is fixed. Can we disable tests on auto-linux-64-debug-opt and start to block on it?

[dotdash]

@sanxiyn No, this is still blocked by #25270

[pnkfelix]

@dotdash but #25270 only affects windows, right? As I understand it, there will only be one, linux-only, enable-debug build bot

[sanxiyn]

Eh, that's why I said "disable tests". This issue's title also says "no tests".

[dotdash]

@sanxiyn Oh, oops, didn't notice the no-test thing. Sorry!

@pnkfelix No, happens at least on Linux as well, i.e. I can reproduce that.

[pnkfelix]

@dotdash hmm okay then the metadata (and title) for #25270 is pretty misleading ...

[alexcrichton]

If we don't need to run tests then it seems fine to start gating -- rust-lang-deprecated/rust-buildbot#38

[alexcrichton]

We're not gating!

[alexcrichton]

er, *now

[pnkfelix]

\o/