Consider (re?)enabling parallelism for debuginfo tests.

[eddyb]

AFAICT debuginfo tests are way slower than other kinds of tests due to being executed sequentially (I haven't properly checked the source but I couldn't see many threads in htop and it looked sequential).

This is especially noticeable on machines with 16 or more hardware threads, where other test suites make visible progress at significantly faster rates.

[eddyb]

The other thing I've noticed before but I wasn't sure about, is that there seems to be no skipping of previously-passing tests.

[tromey]

src/tools/compiletest/src/main.rs says:

    // Some older versions of LLDB seem to have problems with multiple
    // instances running in parallel, so only run one test thread at a
    // time.
    env::set_var("RUST_TEST_THREADS", "1");

This dates back to 2014 (and maybe before but I didn't dig any deeper):

commit ca0446d10795691e3fc206794ac7fbd441442b34
Author: Michael Woerister <michaelwoerister@posteo>
Date:   Sun Oct 26 10:57:29 2014 +0100

    debuginfo: Set RUST_TEST_TASKS to 1 again for LLDB tests

Maybe such old versions of lldb aren't relevant any more.

[tromey]

Removing that line sure seems to help. The question then is whether it can be removed. @michaelwoerister - you added that, do you recall?

I don't know anything about skipping already-passed tests.

[michaelwoerister]

As far as I remember, back in 2014 LLDB tests failed reliably when run in parallel. That was the only reason why we made them run one at a time. If that's not a problem anymore, we should run them in parallel, yes.

For GDB and CDB tests are already running in parallel, right?

[tromey]

For GDB and CDB tests are already running in parallel, right?

I believe so.

[tromey]

I don't know anything about skipping already-passed tests.

I think this already happens, since I see this i output:

running 268 tests
i.iFFiiiiiiiiiiiiiiiiiiiiiii.iiiiii.iiiiiiiiiiiiiiiiiiiiiiiiiiiiiii..Fi.iiiiiiiiiiiiiiFiiiiiiiiiiiii 100/268
iiiiii.ii..ii.iiiiiiiiiii.iiiiiii.i.iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 200/268
i.i.iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii.ii..iiiiiiiiiiiiii.iiiiiii.

[tmiasko]

I don't know anything about skipping already-passed tests.

I think this already happens, since I see this i output:

I think I fixed this back in #68391 (the spurious hash mismatch mentioned in the pull request description).