UI Tests that check ICEing thread names break with parallel-compiler = true

[anp]

When I run ./x.py test locally on a clean checkout of master with parallel-compiler = true, I see a couple of failures that seem to be related to the name of the rustc thread which ICEd in the tests. I turned parallel-compiler off, reran the test command, and the tests passed.

Here's the stderr diffs of the failing tests:

---- [ui] ui/consts/miri_unleashed/mutable_references_ice.rs stdout ----
diff of stderr:

4	LL |     x: &UnsafeCell::new(42),
5	   |        ^^^^^^^^^^^^^^^^^^^^
6	
-	thread 'rustc' panicked at 'assertion failed: `(left != right)`
+	thread '<unnamed>' panicked at 'assertion failed: `(left != right)`
8	  left: `Const`,

...

---- [ui] ui/pattern/const-pat-ice.rs stdout ----
diff of stderr:

-	thread 'rustc' panicked at 'assertion failed: rows.iter().all(|r| r.len() == v.len())', src/librustc_mir/hair/pattern/_match.rs:LL:CC
+	thread '<unnamed>' panicked at 'assertion failed: rows.iter().all(|r| r.len() == v.len())', src/librustc_mir/hair/pattern/_match.rs:LL:CC
2	note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

My assumption is that the parallel-compiler flag doesn't result in all of the threads being named rustc, and so when the ICE occurs it produces an error message from an unnamed thread. I also assume this is totally OK in most cases, because very few things rely on the names of compiler threads.

If these completely unfounded assumptions are accurate, then would it be reasonable to set the name of threads in the compiler's pool?

• Commit: c6293e3
• OS: Arch Linux (fairly current as of filing)

[pnkfelix]

triage: P-high, since fixing this is presumably high impact for WG-parallel-rustc. Removing nomination label.

[mati865]

Would it be enough to normalize output of those two tests similarly to this?

rust/src/test/ui/consts/miri_unleashed/mutable_references_ice.rs

Line 4 in 0221e26

// normalize-stderr-test "note: rustc 1.* running on .*" -> "note: rustc VERSION running on TARGET"

[pnkfelix]

(also, I'm tempted to remove the ICE label. Its a little weird that we have tests that are checking the output format of ICEs, but regardless of that, this bug is not about addressing any ICEs in the compiler itself.)

[pnkfelix]

Would it be enough to normalize output of those two tests similarly to this?

rust/src/test/ui/consts/miri_unleashed/mutable_references_ice.rs

Line 4 in 0221e26

// normalize-stderr-test "note: rustc 1.* running on .*" -> "note: rustc VERSION running on TARGET"

Yes I suspect something like that might well suffice.

[pnkfelix]

(I'm willing to mentor fixes to this bug. I suspect there are very easy solutions available.)

[hbina]

I will try to reproduce this error, if I can I want to try to take it down!

[hbina]

Tested it on Ubuntu 18.04, and it did panic. Waiting on instructions, I have little clue as how to proceed.

[cuviper]

My assumption is that the parallel-compiler flag doesn't result in all of the threads being named rustc, and so when the ICE occurs it produces an error message from an unnamed thread. I also assume this is totally OK in most cases, because very few things rely on the names of compiler threads.

Yes, and I have a commit to add thread names in #64358, 4152abe. We could easily apply that separately without waiting for the new rustc-rayon to be published.

[hbina]

Hmm, so I need to apply the same changes to this issue as well? @cuviper
I might be a bit slow, I borked my Linux machine ...

[cuviper]

@hbina Yes, if you apply the same thread_name change, it will fix this issue. I'm also hoping that the wait on new rustc-rayon will be resolved soon, so we can just land my PR in full.

Either way, I don't think this issue deserves P-high -- the actual ICE behavior of these tests is correctly handled, but for the cosmetic thread name.

[pnkfelix]

closing as fixed since #64358 landed.