Part of #154314.
PR #153801 did introduce an option to run rustc tests with parallel compiler enabled using option --parallel-frontend-threads. There a collection of tests was marked ignore-parallel-frontend due to subtle difference in output diagnostics. For example:
---- [ui] tests/ui/structs/default-field-values/post-mono.rs#indirect stdout ----
Saved the actual stderr to `build/x86_64-unknown-linux-gnu/test/ui/structs/default-field-values/post-mono.indirect/post-mono.indirect.stderr`
diff of stderr:
24 LL | indirect::<1>();
25 | ^^^^^^^^^^^^^^^
26
+ note: the above error was encountered while instantiating `fn std::rt::lang_start::<()>`
+
27 error: aborting due to 1 previous error
28
29 For more information about this error, try `rustc --explain E0080`.
The addition of message "the above error was encountered while instantiating fn std::rt::lang_start::<()>" in output diagnostics was the sole cause of failures in these tests with parallel frontend enabled:
Failed tests
- tests/ui/abi/simd-abi-checks-avx.rs
- tests/ui/consts/const-eval/issue-50814-2.rs
- tests/ui/consts/const-eval/issue-50814.rs
- tests/ui/consts/mono-reachable-invalid-const.rs
- tests/ui/consts/required-consts/collect-in-called-fn.rs
- tests/ui/consts/required-consts/collect-in-dead-closure.rs
- tests/ui/consts/required-consts/collect-in-dead-drop.rs
- tests/ui/consts/required-consts/collect-in-dead-fn-behind-assoc-type.rs
- tests/ui/consts/required-consts/collect-in-dead-fn-behind-generic.rs
- tests/ui/consts/required-consts/collect-in-dead-fn-behind-opaque-type.rs
- tests/ui/consts/required-consts/collect-in-dead-fn.rs
- tests/ui/consts/required-consts/collect-in-dead-fnptr-in-const.rs
- tests/ui/consts/required-consts/collect-in-dead-fnptr.rs
- tests/ui/consts/required-consts/collect-in-dead-move.rs
- tests/ui/consts/required-consts/collect-in-promoted-const.rs
- tests/ui/inline-const/required-const.rs
- tests/ui/lint/large_assignments/copy_into_box_rc_arc.rs
- tests/ui/lint/large_assignments/copy_into_fn.rs
- tests/ui/lint/large_assignments/inline_mir.rs
- tests/ui/lint/large_assignments/large_future.rs
- tests/ui/lint/large_assignments/move_into_fn.rs
- tests/ui/simd/const-err-trumps-simd-err.rs
- tests/ui/structs/default-field-values/post-mono.rs
Meanwhile there were similar tests with //@ ignore-parallel-frontend post-monomorphization errors I was unable to reproduce a failure for with --parallel-frontend-threads set:
Other tests
- tests/ui/consts/const-eval/index-out-of-bounds-never-type.rs
- tests/ui/consts/required-consts/collect-in-dead-forget.rs
- tests/ui/consts/required-consts/collect-in-dead-vtable.rs
- tests/ui/consts/required-consts/interpret-in-const-called-fn.rs
- tests/ui/consts/required-consts/interpret-in-promoted.rs
- tests/ui/consts/required-consts/interpret-in-static.rs
collect_items_rec uses tcx.dcx().err_count() global error counter to count errors before and after checking items, difference of which is assumed to be number of errors for checking said items:
|
// FIXME: don't rely on global state, instead bubble up errors. Note: this is very hard to do. |
|
let error_count = tcx.dcx().err_count(); |
and later
|
// Check for PMEs and emit a diagnostic if one happened. To try to show relevant edges of the |
|
// mono item graph. |
|
if tcx.dcx().err_count() > error_count |
|
&& starting_item.node.is_generic_fn() |
|
&& starting_item.node.is_user_defined() |
|
{ |
|
match starting_item.node { |
|
MonoItem::Fn(instance) => tcx.dcx().emit_note(EncounteredErrorWhileInstantiating { |
|
span: starting_item.span, |
|
kind: "fn", |
|
instance, |
|
}), |
|
MonoItem::Static(def_id) => tcx.dcx().emit_note(EncounteredErrorWhileInstantiating { |
|
span: starting_item.span, |
|
kind: "static", |
|
instance: Instance::new_raw(def_id, GenericArgs::empty()), |
|
}), |
|
MonoItem::GlobalAsm(_) => { |
|
tcx.dcx().emit_note(EncounteredErrorWhileInstantiatingGlobalAsm { |
|
span: starting_item.span, |
|
}) |
|
} |
|
} |
|
} |
However we call collect_items_rec in parallel in which leads to this assumption to fail:
|
par_for_each_in(roots, |root| { |
|
collect_items_root(tcx, dummy_spanned(*root), &state, recursion_limit); |
|
}); |
Thus it creates unintended inconsistency in tests' outputs.
Part of #154314.
PR #153801 did introduce an option to run rustc tests with parallel compiler enabled using option
--parallel-frontend-threads. There a collection of tests was markedignore-parallel-frontenddue to subtle difference in output diagnostics. For example:The addition of message "the above error was encountered while instantiating
fn std::rt::lang_start::<()>" in output diagnostics was the sole cause of failures in these tests with parallel frontend enabled:Failed tests
Meanwhile there were similar tests with
//@ ignore-parallel-frontend post-monomorphization errorsI was unable to reproduce a failure for with--parallel-frontend-threadsset:Other tests
collect_items_recusestcx.dcx().err_count()global error counter to count errors before and after checking items, difference of which is assumed to be number of errors for checking said items:rust/compiler/rustc_monomorphize/src/collector.rs
Lines 417 to 418 in bbe8536
and later
rust/compiler/rustc_monomorphize/src/collector.rs
Lines 541 to 564 in bbe8536
However we call
collect_items_recin parallel in which leads to this assumption to fail:rust/compiler/rustc_monomorphize/src/collector.rs
Lines 1820 to 1822 in bbe8536
Thus it creates unintended inconsistency in tests' outputs.