Description
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)