UI test failures with parallel-compiler=true #75760
Labels
A-testsuite
Area: The testsuite used to check the correctness of rustc
C-bug
Category: This is a bug.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-compiler-parallel
Working group: Parallelizing the compiler
Comments
jyn514
added
A-testsuite
|
Ran into this, the defaults-cyclic-fail tests seem to pass now, but this remains for the others. Speculatively, it seems to be, since the issue in one case is that the errors duplicate, and the issue in the other case is that the error never gets found, is that diagnostics do not get absorbed back into a single thread and deduplicated properly. ---- [ui] ui/privacy/privacy2.rs stdout ----
diff of stderr:
23
24 error: requires `sized` lang_item
25
- error: aborting due to 3 previous errors
+ error: requires `sized` lang_item
+
+ error: requires `sized` lang_item
+
+ error: aborting due to 5 previous errors
27
28 Some errors have detailed explanations: E0432, E0603.
29 For more information about an error, try `rustc --explain E0432`.---- [ui] ui/privacy/privacy3.rs stdout ----
diff of stderr:
6
7 error: requires `sized` lang_item
8
- error: aborting due to 2 previous errors
+ error: requires `sized` lang_item
+
+ error: requires `sized` lang_item
+
+ error: aborting due to 4 previous errors
10
11 For more information about this error, try `rustc --explain E0432`.
12 ---- [ui] ui/traits/cycle-cache-err-60010.rs stdout ----
diff of stderr:
6 |
7 = note: required because of the requirements on the impl of `Query<RootDatabase>` for `ParseQuery`
8
- error[E0275]: overflow evaluating the requirement `Runtime<RootDatabase>: RefUnwindSafe`
- --> $DIR/cycle-cache-err-60010.rs:31:20
- |
- LL | trait Database {
- | -------- required by a bound in this
- LL | type Storage;
- | ------------- required by this bound in `Database`
- ...
- LL | type Storage = SalsaStorage;
- | ^^^^^^^^^^^^
- |
- = note: required because it appears within the type `RootDatabase`
- = note: required because of the requirements on the impl of `SourceDatabase` for `RootDatabase`
- = note: required because of the requirements on the impl of `Query<RootDatabase>` for `ParseQuery`
- = note: required because it appears within the type `SalsaStorage`
-
- error: aborting due to 2 previous errors
+ error: aborting due to previous error
26
27 For more information about this error, try `rustc --explain E0275`.
28 |
This was referenced Sep 7, 2020
|
Hello everyone. My name is Emanuel and I would like to start contributing on the parallelization effort of rustc. I am new to open source contributions and to Rust, so I also asked for the help of Josh Triplett on Zulip. Using rustc 1.52.0-dev (x86_64-unknown-linux-gnu) 15 tests fail: So I would like some opinions on how to tackle those issues. Any help is appreciated. |
|
@emanuellima1 I'm not sure how to fix the underlying issue that diagnostics aren't deduplicated, but another short-term fix is to not send the duplicates to rustc_error in the first place somehow. |
|
Just dived into it and tried to make some fixes: #97307 . |
|
Submitted a new PR to fix another set of ui test failures |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 27, 2022
catch unwind in parallel mode during wfcheck Update rust-lang#75760 When performing wfcheck, from the test results, the parallel mode will stop all checks when an `item`'s check failed, (e.g. the first ui test failure raised from [here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs#L249))while the serial mode will output each `item`'s check result via `catch_unwind`. This leads to inconsistencies in the final output of the two mode. In my local environment, this modification prevents the following ui tests from failing when set `parallel-compiler = true` in `config.toml`: ``` [ui] src/test\ui\associated-types\defaults-cyclic-fail-1.rs [ui] src/test\ui\associated-types\defaults-cyclic-fail-2.rs [ui] src/test\ui\associated-types\hr-associated-type-bound-2.rs [ui] src/test\ui\associated-types\impl-wf-cycle-1.rs [ui] src/test\ui\associated-types\impl-wf-cycle-2.rs [ui] src/test\ui\issues\issue-20413.rs [ui] src/test\ui\parallel_test\defaults-cyclic-fail-para.rs ```
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 3, 2022
get rid of `tcx` in deadlock handler when parallel compilation This is a very obscure and hard-to-trace problem that affects thread scheduling. If we copy `tcx` to the deadlock handler thread, it will perform unpredictable behavior and cause very weird problems when executing `try_collect_active_jobs`(For example, the deadlock handler thread suddenly preempts the content of the blocked worker thread and executes the unknown judgment branch, like rust-lang#94654). Fortunately we can avoid this behavior by precomputing `query_map`. This change fixes the following ui tests failure on my environment when set `parallel-compiler = true`: ``` [ui] src/test\ui\async-await\no-const-async.rs [ui] src/test\ui\infinite\infinite-struct.rs [ui] src/test\ui\infinite\infinite-tag-type-recursion.rs [ui] src/test\ui\issues\issue-3008-1.rs [ui] src/test\ui\issues\issue-3008-2.rs [ui] src/test\ui\issues\issue-32326.rs [ui] src/test\ui\issues\issue-57271.rs [ui] src/test\ui\issues\issue-72554.rs [ui] src/test\ui\parser\fn-header-semantic-fail.rs [ui] src/test\ui\union\union-nonrepresentable.rs ``` Updates rust-lang#75760 Fixes rust-lang#94654
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jul 19, 2022
use `par_for_each_in` in `par_body_owners` and `collect_crate_mono_items`
Using `par_iter` in non-parallel mode will cause the entire process to abort when any iteration panics. So we can use `par_for_each_in` instead to make the error message consistent with parallel mode. This means that the compiler will output more error messages in some cases. This fixes the following ui tests when set `parallel-compiler = true`:
```
[ui] src/test\ui\privacy\privacy2.rs
[ui] src/test\ui\privacy\privacy3.rs
[ui] src/test\ui\type_length_limit.rs
```
This refers to rust-lang#68171
Updates rust-lang#75760
|
Just submitted a new PR to fix 3 of the 4 remaining failing tests. The remaining one is about the extra output of #[Edit] The remain one is because of the |
3 tasks
jyn514
changed the title
jyn514
added
the
T-compiler
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this issue
Apr 5, 2023
write threads info into log only when debugging The current tracing log will unconditionally write thread information during parallel compilation, which sometimes confuses some normal output log information This fixes the UI test failure of: ``` [ui] tests/ui/consts/const_in_pattern/issue-73431.rs ``` Updates rust-lang#75760
|
This issue currently only involves the scenario of |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Apr 6, 2023
add `dont_check_failure_status` option in the compiler test Sometimes the compiler triggers one ice while processing another ice. This will cause a recursive panic and go to [`sys::abort_internal()`](https://github.com/rust-lang/rust/blob/master/library/std/src/panicking.rs#L675), which generates an unfixed exit code. So I think we need an option to allow these use cases to generate different exit codes Updates rust-lang#75760 cc rust-lang#95134 For example, when set `parallel_compiler = true`, issue-95134 will ice in `report_ice` since it try to print the query stack. Below is the brief error message: ``` failures: ---- [ui] tests\ui\recursion\issue-95134.rs stdout ---- error: Error: expected failure status (Some(101)) but received status Some(-1073740791). status: exit code: 0xc0000409 command: PATH="D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage1\bin;C:\Program Files (x86)\Windows Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64;D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage0-bootstrap-tools\x86_64-pc-windows-msvc\release\deps;D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage0\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.4\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.4\libnvvp;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\TortoiseGit\bin;C:\Program Files\CMake\bin;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files\Git\cmd;C:\Program Files\NVIDIA Corporation\Nsight Compute 2021.2.1\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Users\HuaweiOpensource\anaconda3;C:\Users\HuaweiOpensource\anaconda3\Scripts;C:\Users\HuaweiOpensource\anaconda3\Library\bin;C:\Users\HuaweiOpensource\anaconda3\Library\mingw-w64;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\GnuWin32\bin;C:\Users\HuaweiOpensource\AppData\Local\Programs\Python\Python38\Scripts\;C:\Users\HuaweiOpensource\AppData\Local\Programs\Python\Python38\;C:\Users\HuaweiOpensource\.cargo\bin;C:\Users\HuaweiOpensource\.cargo\bin;D:\Program Files\JetBrains\CLion 2022.1.3\bin;;D:\Program Files\JetBrains\PyCharm Community Edition 2020.3\bin;;D:\Program Files\OpenSSL-Win64\bin;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit;C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64;" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\stage1\\bin\\rustc.exe" "D:\\rust-backup\\parallel_rust\\rust-para\\tests\\ui\\recursion\\issue-95134.rs" "-Zthreads=1" "--target=x86_64-pc-windows-msvc" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Zdeduplicate-diagnostics=no" "-Cstrip=debuginfo" "--remap-path-prefix=D:\\rust-backup\\parallel_rust\\rust-para\\tests\\ui=fake-test-src-base" "-C" "prefer-dynamic" "--out-dir" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\test\\ui\\recursion\\issue-95134" "-A" "unused" "-Crpath" "-Cdebuginfo=0" "-Lnative=D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\native\\rust-test-helpers" "-L" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\test\\ui\\recursion\\issue-95134\\auxiliary" "-Copt-level=0" stdout: none --- stderr ------------------------------- thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', C:\Users\HuaweiOpensource\.cargo\registry\src\github.com-1ecc6299db9ec823\ena-0.14.2\src\snapshot_vec.rs:199:10 stack backtrace: 0: 0x7ffc3e90bc05 - std::backtrace_rs::backtrace::trace_unsynchronized::hfabb14c555fa1e54 1: 0x7ffc3e900799 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88786f2c1c37cad0 2: 0x7ffc3e95143b - core::fmt::write::hef4555c5285e005b 3: 0x7ffc3e8ef2aa - std::io::Write::write_fmt::h9ea304efc4781c26 4: 0x7ffc3e90059b - std::sys_common::backtrace::print::h7b33cd350eefb143 ...... 178: 0x7ffc27d6a3f2 - <&mut serde_json[7222a1897944c7c8]::ser::Serializer<&mut alloc[6a6f6c0f0cd9fa15]::vec::Vec<u8>, serde_json[7222a1897944c7c8]::ser::PrettyFormatter> as serde[d3e6684f4f38fcf7]::ser::Serializer>::collect_seq::<&alloc[6a6f6c0f0cd9fa15]::vec::Vec<serde_json[7222a1897944c7c8]::value::Value>> 179: 0x7ffc3e8ed9ec - std::sys::windows::thread::Thread::new::thread_start::h5be4f069fac1a629 180: 0x7ffcb0b37614 - BaseThreadInitThunk 181: 0x7ffcb18c26a1 - RtlUserThreadStart error: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.70.0-dev running on x86_64-pc-windows-msvc note: compiler flags: -Z threads=1 -C codegen-units=1 -Z ui-testing -Z simulate-remapped-rust-src-base=/rustc/FAKE_PREFIX -Z translate-remapped-path-to-local-path=no -Z deduplicate-diagnostics=no -C strip=debuginfo -C prefer-dynamic -C rpath -C debuginfo=0 -C opt-level=0 query stack during panic: thread 'rustc' panicked at 'type variables should not be hashed: _#0t', D:\rust-backup\parallel_rust\rust-para\compiler\rustc_type_ir\src\lib.rs:718:17 stack backtrace: 0: 0x7ffc3e90bc05 - std::backtrace_rs::backtrace::trace_unsynchronized::hfabb14c555fa1e54 1: 0x7ffc3e900799 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88786f2c1c37cad0 2: 0x7ffc3e95143b - core::fmt::write::hef4555c5285e005b 3: 0x7ffc3e8ef2aa - std::io::Write::write_fmt::h9ea304efc4781c26 4: 0x7ffc3e90059b - std::sys_common::backtrace::print::h7b33cd350eefb143 5: 0x7ffc3e91c109 - std::panicking::default_hook::h12f01c5f2b8959c6 ...... 197: 0x7ffc27d6a3f2 - <&mut serde_json[7222a1897944c7c8]::ser::Serializer<&mut alloc[6a6f6c0f0cd9fa15]::vec::Vec<u8>, serde_json[7222a1897944c7c8]::ser::PrettyFormatter> as serde[d3e6684f4f38fcf7]::ser::Serializer>::collect_seq::<&alloc[6a6f6c0f0cd9fa15]::vec::Vec<serde_json[7222a1897944c7c8]::value::Value>> 198: 0x7ffc3e8ed9ec - std::sys::windows::thread::Thread::new::thread_start::h5be4f069fac1a629 199: 0x7ffcb0b37614 - BaseThreadInitThunk 200: 0x7ffcb18c26a1 - RtlUserThreadStart error: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.70.0-dev running on x86_64-pc-windows-msvc note: compiler flags: -Z threads=1 -C codegen-units=1 -Z ui-testing -Z simulate-remapped-rust-src-base=/rustc/FAKE_PREFIX -Z translate-remapped-path-to-local-path=no -Z deduplicate-diagnostics=no -C strip=debuginfo -C prefer-dynamic -C rpath -C debuginfo=0 -C opt-level=0 query stack during panic: thread panicked while processing panic. aborting. ------------------------------------------ ```
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Apr 6, 2023
add `dont_check_failure_status` option in the compiler test Sometimes the compiler triggers one ice while processing another ice. This will cause a recursive panic and go to [`sys::abort_internal()`](https://github.com/rust-lang/rust/blob/master/library/std/src/panicking.rs#L675), which generates an unfixed exit code. So I think we need an option to allow these use cases to generate different exit codes Updates rust-lang#75760 cc rust-lang#95134 For example, when set `parallel_compiler = true`, issue-95134 will ice in `report_ice` since it try to print the query stack. Below is the brief error message: ``` failures: ---- [ui] tests\ui\recursion\issue-95134.rs stdout ---- error: Error: expected failure status (Some(101)) but received status Some(-1073740791). status: exit code: 0xc0000409 command: PATH="D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage1\bin;C:\Program Files (x86)\Windows Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64;D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage0-bootstrap-tools\x86_64-pc-windows-msvc\release\deps;D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage0\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.4\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.4\libnvvp;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\TortoiseGit\bin;C:\Program Files\CMake\bin;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files\Git\cmd;C:\Program Files\NVIDIA Corporation\Nsight Compute 2021.2.1\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Users\HuaweiOpensource\anaconda3;C:\Users\HuaweiOpensource\anaconda3\Scripts;C:\Users\HuaweiOpensource\anaconda3\Library\bin;C:\Users\HuaweiOpensource\anaconda3\Library\mingw-w64;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\GnuWin32\bin;C:\Users\HuaweiOpensource\AppData\Local\Programs\Python\Python38\Scripts\;C:\Users\HuaweiOpensource\AppData\Local\Programs\Python\Python38\;C:\Users\HuaweiOpensource\.cargo\bin;C:\Users\HuaweiOpensource\.cargo\bin;D:\Program Files\JetBrains\CLion 2022.1.3\bin;;D:\Program Files\JetBrains\PyCharm Community Edition 2020.3\bin;;D:\Program Files\OpenSSL-Win64\bin;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit;C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64;" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\stage1\\bin\\rustc.exe" "D:\\rust-backup\\parallel_rust\\rust-para\\tests\\ui\\recursion\\issue-95134.rs" "-Zthreads=1" "--target=x86_64-pc-windows-msvc" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Zdeduplicate-diagnostics=no" "-Cstrip=debuginfo" "--remap-path-prefix=D:\\rust-backup\\parallel_rust\\rust-para\\tests\\ui=fake-test-src-base" "-C" "prefer-dynamic" "--out-dir" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\test\\ui\\recursion\\issue-95134" "-A" "unused" "-Crpath" "-Cdebuginfo=0" "-Lnative=D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\native\\rust-test-helpers" "-L" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\test\\ui\\recursion\\issue-95134\\auxiliary" "-Copt-level=0" stdout: none --- stderr ------------------------------- thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', C:\Users\HuaweiOpensource\.cargo\registry\src\github.com-1ecc6299db9ec823\ena-0.14.2\src\snapshot_vec.rs:199:10 stack backtrace: 0: 0x7ffc3e90bc05 - std::backtrace_rs::backtrace::trace_unsynchronized::hfabb14c555fa1e54 1: 0x7ffc3e900799 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88786f2c1c37cad0 2: 0x7ffc3e95143b - core::fmt::write::hef4555c5285e005b 3: 0x7ffc3e8ef2aa - std::io::Write::write_fmt::h9ea304efc4781c26 4: 0x7ffc3e90059b - std::sys_common::backtrace::print::h7b33cd350eefb143 ...... 178: 0x7ffc27d6a3f2 - <&mut serde_json[7222a1897944c7c8]::ser::Serializer<&mut alloc[6a6f6c0f0cd9fa15]::vec::Vec<u8>, serde_json[7222a1897944c7c8]::ser::PrettyFormatter> as serde[d3e6684f4f38fcf7]::ser::Serializer>::collect_seq::<&alloc[6a6f6c0f0cd9fa15]::vec::Vec<serde_json[7222a1897944c7c8]::value::Value>> 179: 0x7ffc3e8ed9ec - std::sys::windows::thread::Thread::new::thread_start::h5be4f069fac1a629 180: 0x7ffcb0b37614 - BaseThreadInitThunk 181: 0x7ffcb18c26a1 - RtlUserThreadStart error: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.70.0-dev running on x86_64-pc-windows-msvc note: compiler flags: -Z threads=1 -C codegen-units=1 -Z ui-testing -Z simulate-remapped-rust-src-base=/rustc/FAKE_PREFIX -Z translate-remapped-path-to-local-path=no -Z deduplicate-diagnostics=no -C strip=debuginfo -C prefer-dynamic -C rpath -C debuginfo=0 -C opt-level=0 query stack during panic: thread 'rustc' panicked at 'type variables should not be hashed: _#0t', D:\rust-backup\parallel_rust\rust-para\compiler\rustc_type_ir\src\lib.rs:718:17 stack backtrace: 0: 0x7ffc3e90bc05 - std::backtrace_rs::backtrace::trace_unsynchronized::hfabb14c555fa1e54 1: 0x7ffc3e900799 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88786f2c1c37cad0 2: 0x7ffc3e95143b - core::fmt::write::hef4555c5285e005b 3: 0x7ffc3e8ef2aa - std::io::Write::write_fmt::h9ea304efc4781c26 4: 0x7ffc3e90059b - std::sys_common::backtrace::print::h7b33cd350eefb143 5: 0x7ffc3e91c109 - std::panicking::default_hook::h12f01c5f2b8959c6 ...... 197: 0x7ffc27d6a3f2 - <&mut serde_json[7222a1897944c7c8]::ser::Serializer<&mut alloc[6a6f6c0f0cd9fa15]::vec::Vec<u8>, serde_json[7222a1897944c7c8]::ser::PrettyFormatter> as serde[d3e6684f4f38fcf7]::ser::Serializer>::collect_seq::<&alloc[6a6f6c0f0cd9fa15]::vec::Vec<serde_json[7222a1897944c7c8]::value::Value>> 198: 0x7ffc3e8ed9ec - std::sys::windows::thread::Thread::new::thread_start::h5be4f069fac1a629 199: 0x7ffcb0b37614 - BaseThreadInitThunk 200: 0x7ffcb18c26a1 - RtlUserThreadStart error: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.70.0-dev running on x86_64-pc-windows-msvc note: compiler flags: -Z threads=1 -C codegen-units=1 -Z ui-testing -Z simulate-remapped-rust-src-base=/rustc/FAKE_PREFIX -Z translate-remapped-path-to-local-path=no -Z deduplicate-diagnostics=no -C strip=debuginfo -C prefer-dynamic -C rpath -C debuginfo=0 -C opt-level=0 query stack during panic: thread panicked while processing panic. aborting. ------------------------------------------ ```
|
this test also fails when parallel-compiler is enabled: probably we need to normalize the stderr so that only one crate is shown? that also avoids having to update the test when we add dependencies. |
28 tasks
I think diagnostic information should be preserved as much as possible. |
|
i don't think it's useful to have a full list of the crates in the sysroot. see fd95715 for the solution i came up with (it also allows us to stop ignoring the test on non-unix platforms). |
|
a bunch of rustdoc tests are also failing - the |
|
@jyn514 Due to #106930, rustdoc will not get auto traits when parallel compilation is enabled, otherwise it will cause homu to wait infinitely. |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 15, 2023
…cjgillot Don't require each rustc_interface tool to opt-in to parallel_compiler Previously, forgetting to call `interface::set_thread_safe_mode` would cause the following ICE: ``` thread 'rustc' panicked at 'uninitialized dyn_thread_safe mode!', /rustc/dfe0683138de0959b6ab6a039b54d9347f6a6355/compiler/rustc_data_structures/src/sync.rs:74:18 ``` This calls `set_thread_safe_mode` in `interface::run_compiler` to avoid requiring it in the caller. Fixes `tests/run-make-fulldeps/issue-19371` when parallel-compiler is enabled. r? `@SparrowLii` cc rust-lang#75760
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Jul 16, 2023
Don't require each rustc_interface tool to opt-in to parallel_compiler Previously, forgetting to call `interface::set_thread_safe_mode` would cause the following ICE: ``` thread 'rustc' panicked at 'uninitialized dyn_thread_safe mode!', /rustc/dfe0683138de0959b6ab6a039b54d9347f6a6355/compiler/rustc_data_structures/src/sync.rs:74:18 ``` This calls `set_thread_safe_mode` in `interface::run_compiler` to avoid requiring it in the caller. Fixes `tests/run-make-fulldeps/issue-19371` when parallel-compiler is enabled. r? `@SparrowLii` cc rust-lang/rust#75760
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I changed the
config.tomlto sayand ran
x.py test.I got this result:
More specifically:
I know that the parallel-compiler setting is still experimental/unsupported.
But it would be nice if it didn't inject test failures like this, if we can fix it.
The text was updated successfully, but these errors were encountered: