[Kobzol]

View all comments

Part of https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Enabling.20the.20parallel.20frontend.20by.20default.20on.20nightly/with/624597688.

UI tests will still use one frontend thread by default.

CC @petrochenkov

[petrochenkov]

CI fails due to UI tests, they should be compiled with --jobs-frontend=1 because they require reproducible diagnostics.

[Kobzol]

Wasn't there some flag that reordered the diagnostics, or made compiletest to compare them in an order agnostic way? If at all possible, I think that it would be better if we actually ran (at least most) UI tests under the parallel frontend.

[petrochenkov]

I think that it would be better if we actually ran (at least most) UI tests under the parallel frontend.

We do run them, on the test-x86_64-gnu-parallel-frontend job, in special mode.

Wasn't there some flag that reordered the diagnostics, or made compiletest to compare them in an order agnostic way?

Yeah, but that's not enough for some tests, and those tests are disabled with //@ ignore-parallel-frontend on that job (but run in the default mode).
Output blessing is also not supported in the parallel mode, but we want to keep it in the UI tests by default.

[Kobzol]

Can't we solve blessing by forcing 1 frontend thread when --bless is passed?

[petrochenkov]

I'd rather keep the things as is, it's just good to have precise snapshot testing running on something reproducible.
Besides ui tests, --jobs-frontend=1 will need to be used on mir dump tests, and maybe some other test suites.

[Kobzol]

I don't want to block this PR on that, but I find it a bit concerning that we aren't testing a bunch of nightly stuff on our CI. We already don't test the next trait solver, and now we also wouldn't be testing the parallel frontend, even though both would be enabled on nightly.

I'm happy to do the compiletest/bootstrap work to enable running the parallel frontend everywhere. Do you want that to be the default eventually (and perhaps have a separate one-off job that runs things sequentially, like we have the parallel job today)?

[petrochenkov]

Do you want that to be the default eventually

For ui tests (.stderr snapshot testing) - no, I don't expect diagnostics to become reproducible anytime soon, if at all.
Technically we could make -Zui-testing reset the frontend threads to 1 (or otherwise slow down the compiler to serialize the diagnostics) instead of passing --jobs-frontend=1, but that doesn't seem to make much difference.

[petrochenkov]

If there are enough CI resources we could also run rustc twice on every ui test - once in the default mode (if it's parallel) and once in single-threaded mode for precise .stderr comparisons.
Most of //~ ERROR annotations in .rs files should match in parallel mode too, with exception of some tests involving query cycles.

and perhaps have a separate one-off job that runs things sequentially

So this ^^^ would mean limiting the precise .stderr comparison testing to some x86_64-linux-gnu.
I'm not sure, maybe it won't be that terrible, eventually, but it will skip some parts of the test suite.

[Kobzol]

Maybe I misunderstood how the current tooling works. I thought that:

• There is some flag or logic that can compare the emitted diagnostics in an order-independent way. If that exists, then I think that we don't need precise comparisons? As long as the order is the only thing that changes, we can bless with 1 thread and then compare with multiple threads. Or do you consider the actual precise diagnostics ordering to be load-bearing across the whole test suite, rather than e.g. in a subset of tests which we would test with 1 thread (or both with 1 thread and with the parallel frontend)?
• If there are tests that are truly broken under the parallel frontend, we can just mark them as such, and always run them with 1 thread (rather than skipping them entirely when the parallel frontend is enabled by default).

[petrochenkov]

There is some flag or logic that can compare the emitted diagnostics in an order-independent way.

This is correct.

If that exists, then I think that we don't need precise comparisons?

I think that we do still need them, at least while the single-threaded compiler is the default.
Losing them is bad in the same sense as e.g. anonymizing line numbers in .stderr files (which we do), and similarly to the line numbers we can sacrifice them if there are strong reasons (like diff sizes for line numbers). So they are not exactly load bearing, but good to have, and should be kept if we can afford it.

[petrochenkov]

There is some flag or logic that can compare the emitted diagnostics in an order-independent way.

Although that infra currently compares the output on per-line basis, not on per-diagnostic, so technically the diagnostics can be interspersed and messed up entirely, and the check will still pass.

[Kobzol]

Interesting. The obtain-borrowck.rs ui-fulldeps test now fails, likely because it override borrow check and stores some data in a thread local. But the interesting thing is that it only seems to happen when -Zthreads=1 is used. I presume that rustc behaves slightly differently when -Zthreads is unset, vs when it is set to 1?

[Kobzol]

Let's test everything, as there's a high chance that there would be more CI failures.

@bors try jobs=* nolimit

[rust-log-analyzer]

The job test-various failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [run-make] tests/run-make/const-trait-stable-toolchain stdout ----

error: rmake recipe failed to complete
status: exit status: 101
command: cd "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/const-trait-stable-toolchain/rmake_out" && env -u RUSTFLAGS -u __RUSTC_DEBUG_ASSERTIONS_ENABLED -u __STD_DEBUG_ASSERTIONS_ENABLED -u __STD_REMAP_DEBUGINFO_ENABLED AR="/wasi-sdk-34.0-x86_64-linux/bin/llvm-ar" BUILD_ROOT="/checkout/obj/build/x86_64-unknown-linux-gnu" CC="/wasi-sdk-34.0-x86_64-linux/bin/wasm32-wasip1-clang" CC_DEFAULT_FLAGS="-ffunction-sections -fdata-sections --target=wasm32-wasip1 -w" CXX="/wasi-sdk-34.0-x86_64-linux/bin/wasm32-wasip1-clang++" CXX_DEFAULT_FLAGS="-ffunction-sections -fdata-sections --target=wasm32-wasip1 -w" HOST_RUSTC_DYLIB_PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" LD_LIBRARY_PATH=":/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib" LD_LIB_PATH_ENVVAR="LD_LIBRARY_PATH" LLVM_BIN_DIR="/checkout/obj/build/x86_64-unknown-linux-gnu/ci-llvm/bin" LLVM_COMPONENTS="aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils abi aggressiveinstcombine all all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgputargetmca amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo cas cfguard cgdata codegen codegentypes core coroutines coverage csky cskyasmparser cskycodegen cskydesc cskydisassembler cskyinfo debuginfobtf debuginfocodeview debuginfodwarf debuginfodwarflowlevel debuginfogsym debuginfologicalview debuginfomsf debuginfopdb demangle dlltooldriver dtlto dwarfcfichecker dwarflinker dwarflinkerclassic dwarflinkerparallel dwp engine executionengine extensions filecheck frontendatomic frontenddirective frontenddriver frontendhlsl frontendoffloading frontendopenacc frontendopenmp fuzzercli fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo hipstdpar instcombine instrumentation interfacestub interpreter ipo irprinter irreader jitlink libdriver lineeditor linker loongarch loongarchasmparser loongarchcodegen loongarchdesc loongarchdisassembler loongarchinfo lto m68k m68kasmparser m68kcodegen m68kdesc m68kdisassembler m68kinfo mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts objcopy object objectyaml option orcdebugging orcjit orcshared orctargetprocess passes plugins powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvtargetmca runtimedyld sandboxir scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support supportlsp symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target targetparser telemetry textapi textapibinaryreader transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo webassemblyutils windowsdriver windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86targetmca xray xtensa xtensaasmparser xtensacodegen xtensadesc xtensadisassembler xtensainfo" LLVM_FILECHECK="/checkout/obj/build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck" NODE="/node/bin/node" PYTHON="/usr/bin/python3" RUNNER="/wasmtime-v44.0.1-x86_64-linux/wasmtime run -Wexceptions -C cache=n --dir . --env RUSTC_BOOTSTRAP" RUSTC="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" RUSTDOC="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc" SOURCE_ROOT="/checkout" TARGET="wasm32-wasip1" TARGET_EXE_DYLIB_PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/wasm32-wasip1/lib" __BOOTSTRAP_JOBS="4" __RMAKE_VERBOSE_SUBPROCESS_OUTPUT="1" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/const-trait-stable-toolchain/rmake"
stdout: none
--- stderr -------------------------------
LD_LIBRARY_PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/const-trait-stable-toolchain/rmake_out:/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib::/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib" RUSTC_BOOTSTRAP="-1" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "const-super-trait.rs" "--cfg" "feature_enabled"
output status: `exit status: 1`
=== STDOUT ===



=== STDERR ===
error: `[const]` is not allowed here
##[error] --> const-super-trait.rs:7:12
  |
7 | trait Bar: [const] Foo {}
  |            ^^^^^^^
  |
note: this trait is not `const`, so it cannot have `[const]` trait bounds
 --> const-super-trait.rs:7:1
  |
7 | trait Bar: [const] Foo {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the nightly release channel
##[error] --> const-super-trait.rs:1:30
  |
1 | #![cfg_attr(feature_enabled, feature(const_trait_impl))]
  |                              ^^^^^^^^^^^^^^^^^^^^^^^^^

error: `[const]` can only be applied to `const` traits
##[error] --> const-super-trait.rs:9:17
  |
9 | const fn foo<T: [const] Bar>(x: &T) {
  |                 ^^^^^^^ can't be applied to `Bar`
  |
note: `Bar` can't be used with `[const]` because it isn't `const`
 --> const-super-trait.rs:7:1
  |
7 | trait Bar: [const] Foo {}
  | ^^^^^^^^^^^^^^^^^^^^^^

error: `[const]` can only be applied to `const` traits
##[error] --> const-super-trait.rs:7:12
  |
7 | trait Bar: [const] Foo {}
  |            ^^^^^^^ can't be applied to `Foo`
  |
note: `Foo` can't be used with `[const]` because it isn't `const`
 --> const-super-trait.rs:3:1
  |
3 | trait Foo {
  | ^^^^^^^^^

error[E0015]: cannot call non-const method `<T as Foo>::a` in constant functions
##[error]  --> const-super-trait.rs:10:7
   |
10 |     x.a();
   |       ^^^
   |
---
 
 error: `[const]` can only be applied to `const` traits
+ --> const-super-trait.rs:9:17
+  |
+9 | const fn foo<T: [const] Bar>(x: &T) {
+  |                 ^^^^^^^ can't be applied to `Bar`
+  |
+note: `Bar` can't be used with `[const]` because it isn't `const`
+ --> const-super-trait.rs:7:1
+  |
+7 | trait Bar: [const] Foo {}
+  | ^^^^^^^^^^^^^^^^^^^^^^
+
+error: `[const]` can only be applied to `const` traits
  --> const-super-trait.rs:7:12
   |
 7 | trait Bar: [const] Foo {}
@@ -27,18 +39,6 @@
   |
 3 | trait Foo {
   | ^^^^^^^^^
-
-error: `[const]` can only be applied to `const` traits
- --> const-super-trait.rs:9:17
-  |
-9 | const fn foo<T: [const] Bar>(x: &T) {
-  |                 ^^^^^^^ can't be applied to `Bar`
-  |
-note: `Bar` can't be used with `[const]` because it isn't `const`
- --> const-super-trait.rs:7:1
-  |
-7 | trait Bar: [const] Foo {}
-  | ^^^^^^^^^^^^^^^^^^^^^^
 
 error[E0015]: cannot call non-const method `<T as Foo>::a` in constant functions
   --> const-super-trait.rs:10:7

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
------------------------------------------

[rust-bors]

💔 Test for da8f090 failed: CI. Failed jobs:

• try - test-aarch64-apple-1 (web logs, enhanced plaintext logs)
• try - test-aarch64-gnu (web logs, enhanced plaintext logs)
• try - test-aarch64-gnu-debug (web logs, enhanced plaintext logs)
• try - test-arm-android (web logs, enhanced plaintext logs)
• try - test-i686-gnu-1 (web logs, enhanced plaintext logs)
• (and 13 other jobs)

[Kobzol]

Blocked on #163664.

@rustbot blocked

[Kobzol]

#163664 has landed. Now I have to convert a few run-make tests to UI tests with the new machinery, and then migrate run-make tests to use RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags=threads.