Explicitly materialize debuginfo tests for all debuggers

[Kobzol]

When testing #158298, I realized that when you don't have a given debugger (CDB, GDB, LLDB) available, compiletest will silently skip generating "variants" of debuginfo tests for a given debugger. So if you run a single debuginfo test, it will run 0/1/2/3 tests, based on what debuggers you have available. So it will show running 1/2/3 tests without telling you that it is actually three separate tests, but some of them were automatically ignored.

This is made even worse by the fact that bootstrap/compiletest currently automatically discovers debuggers, so there is a lot of implicit behavior stacked on top of each other.

This PR changes that, so that compiletest always creates all three variants of the tests, but if you don't have a debugger X available, then the X variant will be ignored, so you can see clearly in the output that it was ignored and why, which is much better than the test simply disappearing.

So after running a given debuginfo test, you will see e.g. this:

running 3 tests
test [debuginfo-cdb] tests/debuginfo/basic-types.rs ... ignored, cdb is not available
test [debuginfo-gdb] tests/debuginfo/basic-types.rs ... ok
test [debuginfo-lldb] tests/debuginfo/basic-types.rs ... ok

Which makes it more more obvious that there are in fact three separate tests, but some of them are ignored (and why).

The way this is achieved is a bit hacky, but that is caused by the previous way compiletest did things. To simulate the three variants of each debuginfo test, compiletest currently generates a separate instance (!) of the Config for each debugger, in the run_tests function. That's quite hacky, to say the least, and it requires storing a debugger field in the Config, which specifies for which variant we are currently running the debuginfo test.

I wanted to try using a single config, and encoding the CDB/GDB/LLDB variants as revisions instead. However, I found out that some debuginfo tests actually do use revisions for.. actual revisions, which caught me by surprise. So we would either need to expand the set of used revisions, so that if the test has e.g. revision=lto, revision=no-lto, we would then turn that into:

• revision=lto-cdb
• revision=lto-gdb
• revision=no-lto-cdb
• revision=no-lto-gdb
• revision=no-lto-lldb

That's maybe not such a bad solution, and it would allow us to use a single Config instance, but it would also require either encoding the debugger inside the revision string and then parsing it out (ugh), or turning revisions into a struct that would contain multiple information (such as the debugger used and then the revision name).

Or we could introduce a separate mechanism for "multiplying" tests, but we already have revisions, and it seems overkill to introduce something like this only for debuggers (unless it is also needed at other places...).

So what I did in this PR instead is to keep the three separate configs, but rather than not generating the Config when a debugger is missing, we always generate a separate config for each debugger, but then we ignore tests that do not match the "active" debugger in the Config. Because this ignore logic is not per directive line, but per test, so I had to introduce a new block of code that does that, but that seems fine to me, when compared to the mountain of hacks already present in this part of the codebase xD

This is implemented in the second commit, the first commit is just a small simplification refactoring.

r? @jieyouxu

Fixes: #126628

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[rustbot]

compiletest directives have been modified. Please add or update docs for the
new or modified directive in src/doc/rustc-dev-guide/.

[jieyouxu]

cf. #126628 too

[jieyouxu]

Thanks, yeah... how to handle the Cartesian product of revision-like things is indeed... interesting.

View changes since this review

[jieyouxu]

Discussion: yeah, I can't say I'm a huge fan of doing 3 copies of the config, cf. thread #t-infra/bootstrap > compiletest CLI parsing @ 💬