Rust: sysroot spans are not printed on some targets (affected: Debian, rust-lang's own i586; unaffected: Fedora)

[infinity0]

EDIT(@eddyb): For a detailed update/explanation, see https://github.com/rust-lang/rust/issues/53081#issuecomment-558804239.

---

I'm trying to track down why we have this diff on all arches, which causes that test to fail:

Test, test output

~~~~
29 |
30 LL | fn hash(&self, hasher: &mut impl Hasher) {}
31 | ^^^^^^^^^^^ expected generic parameter, found impl Trait

• |
• ::: $SRC_DIR/libcore/hash/mod.rs:185:13
• |
• LL | fn hash(&self, state: &mut H);
• | - declaration in trait here
  37
  38 error: aborting due to 3 previous errors
  39
  ~~~~

The test passes on Fedora.

Two main things we're doing differently in Debian is that we're currently using cargo 0.27 to build (rather than cargo 0.28) and we also omit some components. However I don't see why either of these should affect the above test output. I also can't see why our other patches should affect it.

[Dylan-DPC]

@infinity0

The issue is not OS-dependent. The reason your build is failing is because the function signature in your implementation isn't matching the function in your trait definition.

[infinity0]

@Dylan-DPC

I think you're misunderstanding this bug report, this is part of a test (ui/impl-trait/impl-generic-mismatch) which tests that rustc correctly fails to compile invalid code. In Debian, this works fine, our rustc does indeed fail to compile the invalid code. However the problem is that the error message is missing some things. That's what the diff is about.

[infinity0]

Our const-size_of-cycle test also fails but passes in Fedora with a similar lack-of-error-details.

~~~~
diff of stderr:

2 |
3 note: ...which requires normalizing ParamEnvAnd { param_env: ParamEnv { caller_bounds: [], reveal: All }, value: [u8; _] }...
4 note: ...which requires const-evaluating Foo::bytes::{{constant}}...

• --> $SRC_DIR/libcore/mem.rs:LL:COL
• |
• LL | intrinsics::size_of::()
• | ^^^^^^^^^^^^^^^^^^^^^^^^^^
  9 = note: ...which again requires computing layout of Foo, completing the cycle
  10 note: cycle used when const-evaluating Foo::bytes::{{constant}}
• --> $SRC_DIR/libcore/mem.rs:LL:COL
• |
• LL | intrinsics::size_of::()
• | ^^^^^^^^^^^^^^^^^^^^^^^^^^
  15
  16 error: aborting due to previous error
  17
  ~~~~

[infinity0]

related: #54546

[infinity0]

Strangely, if I run rust's own upstream binary compiler from here the output is also missing error details.

~~~~
$ rustc/bin/rustc -L$PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib ../const-size_of-cycle.rs
error[E0391]: cycle detected when computing layout of Foo
|
note: ...which requires normalizing ParamEnvAnd { param_env: ParamEnv { caller_bounds: [], reveal: All }, value: [u8; _] }...
note: ...which requires const-evaluating Foo::bytes::{{constant}}...
= note: ...which again requires computing layout of Foo, completing the cycle
note: cycle used when const-evaluating Foo::bytes::{{constant}}

error: aborting due to previous error

For more information about this error, try rustc --explain E0391.
~~~~

[infinity0]

@oli-obk you created src/test/ui/impl-trait/impl-generic-mismatch.stderr in 00842d10cd703263833132867d59c85b343eb202, and @davidtwco you created src/test/ui/compile-fail-migration/const-size_of-cycle.stderr in b16a30677f4e641329e768272cf9d3ecc2fa31c4, do either of you have any clues about these mismatching error messages?

[eddyb]

cc @michaelwoerister This looks like it might be related to file paths for libcore, not being found when running tests.

[infinity0]

FWIW here is the output with RUST_LOG=debug:

~~~~
$ RUST_LOG=trace rustc/bin/rustc -L$PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib ../const-size_of-cycle.rs
INFO $TS: jobserver::imp: created a jobserver: Client { read: File { fd: 3, path: "pipe:[57109581]", read: true, write: false }, write: File { fd: 4, path: "pipe:[57109581]", read: false, write: true } }
INFO $TS: rustc_driver: codegen backend candidate: $PWD/rustc/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends
INFO $TS: rustc_driver: probing $PWD/rustc/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends for a codegen backend
INFO $TS: rustc_metadata::creader: resolving crate extern crate std as std
INFO $TS: rustc_metadata::creader: falling back to a load
INFO $TS: rustc_metadata::locator: lib candidate: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-52f862a21e09568c.rlib
INFO $TS: rustc_metadata::locator: lib candidate: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-52f862a21e09568c.so
INFO $TS: rustc_metadata::locator: rlib reading metadata from: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-52f862a21e09568c.rlib
INFO $TS: rustc_metadata::locator: reading "libstd-52f862a21e09568c.rlib" => 314.101µs
INFO $TS: rustc_metadata::creader: register crate extern crate std as std
INFO $TS: rustc_metadata::creader: resolving dep crate core hash: af89e4eb0280bac6 extra filename: -f2133e8b70369157
INFO $TS: rustc_metadata::creader: resolving crate extern crate core as core
INFO $TS: rustc_metadata::creader: falling back to a load
INFO $TS: rustc_metadata::locator: lib candidate: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-f2133e8b70369157.rlib
INFO $TS: rustc_metadata::locator: rlib reading metadata from: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-f2133e8b70369157.rlib
INFO $TS: rustc_metadata::locator: reading "libcore-f2133e8b70369157.rlib" => 224.774µs
INFO $TS: rustc_metadata::creader: register crate extern crate core as core
INFO $TS: rustc_metadata::creader: resolving dep crate compiler_builtins hash: d04ac580e8a9e993 extra filename: -71671e8958739d51
INFO $TS: rustc_metadata::creader: resolving crate extern crate compiler_builtins as compiler_builtins
INFO $TS: rustc_metadata::creader: falling back to a load
INFO $TS: rustc_metadata::locator: lib candidate: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-71671e8958739d51.rlib
INFO $TS: rustc_metadata::locator: rlib reading metadata from: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-71671e8958739d51.rlib
INFO $TS: rustc_metadata::locator: reading "libcompiler_builtins-71671e8958739d51.rlib" => 167.677µs
INFO $TS: rustc_metadata::creader: register crate extern crate compiler_builtins as compiler_builtins
INFO $TS: rustc_metadata::creader: resolving dep crate core hash: af89e4eb0280bac6 extra filename: -f2133e8b70369157
INFO $TS: rustc_metadata::creader: resolving crate extern crate core as core
INFO $TS: rustc_metadata::creader: resolving dep crate alloc hash: de32cde30cc6bc18 extra filename: -2d44723f32308cf8
INFO $TS: rustc_metadata::creader: resolving crate extern crate alloc as alloc
INFO $TS: rustc_metadata::creader: falling back to a load
INFO $TS: rustc_metadata::locator: lib candidate: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-2d44723f32308cf8.rlib
INFO $TS: rustc_metadata::locator: rlib reading metadata from: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-2d44723f32308cf8.rlib
INFO $TS: rustc_metadata::locator: reading "liballoc-2d44723f32308cf8.rlib" => 129.342µs
INFO $TS: rustc_metadata::creader: register crate extern crate alloc as alloc
INFO $TS: rustc_metadata::creader: resolving dep crate core hash: af89e4eb0280bac6 extra filename: -f2133e8b70369157
INFO $TS: rustc_metadata::creader: resolving crate extern crate core as core
INFO $TS: rustc_metadata::creader: resolving dep crate compiler_builtins hash: d04ac580e8a9e993 extra filename: -71671e8958739d51
INFO $TS: rustc_metadata::creader: resolving crate extern crate compiler_builtins as compiler_builtins
INFO $TS: rustc_metadata::creader: resolving dep crate alloc_system hash: 20b374f02cf54767 extra filename: -48c8a8552cff934e
INFO $TS: rustc_metadata::creader: resolving crate extern crate alloc_system as alloc_system
INFO $TS: rustc_metadata::creader: falling back to a load
INFO $TS: rustc_metadata::locator: lib candidate: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-48c8a8552cff934e.rlib
INFO $TS: rustc_metadata::locator: rlib reading metadata from: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-48c8a8552cff934e.rlib
INFO $TS: rustc_metadata::locator: reading "liballoc_system-48c8a8552cff934e.rlib" => 54.302µs
INFO $TS: rustc_metadata::creader: register crate extern crate alloc_system as alloc_system
INFO $TS: rustc_metadata::creader: resolving dep crate core hash: af89e4eb0280bac6 extra filename: -f2133e8b70369157
INFO $TS: rustc_metadata::creader: resolving crate extern crate core as core
INFO $TS: rustc_metadata::creader: resolving dep crate compiler_builtins hash: d04ac580e8a9e993 extra filename: -71671e8958739d51
INFO $TS: rustc_metadata::creader: resolving crate extern crate compiler_builtins as compiler_builtins
INFO $TS: rustc_metadata::creader: resolving dep crate libc hash: e04f69583f78a1ba extra filename: -517830e9d56bab97
INFO $TS: rustc_metadata::creader: resolving crate extern crate libc as libc
INFO $TS: rustc_metadata::creader: falling back to a load
INFO $TS: rustc_metadata::locator: lib candidate: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-517830e9d56bab97.rlib
INFO $TS: rustc_metadata::locator: rlib reading metadata from: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-517830e9d56bab97.rlib
INFO $TS: rustc_metadata::locator: reading "liblibc-517830e9d56bab97.rlib" => 81.651µs
INFO $TS: rustc_metadata::creader: register crate extern crate libc as libc
INFO $TS: rustc_metadata::creader: resolving dep crate core hash: af89e4eb0280bac6 extra filename: -f2133e8b70369157
INFO $TS: rustc_metadata::creader: resolving crate extern crate core as core
INFO $TS: rustc_metadata::creader: resolving dep crate compiler_builtins hash: d04ac580e8a9e993 extra filename: -71671e8958739d51
INFO $TS: rustc_metadata::creader: resolving crate extern crate compiler_builtins as compiler_builtins
INFO $TS: rustc_metadata::creader: resolving dep crate libc hash: e04f69583f78a1ba extra filename: -517830e9d56bab97
INFO $TS: rustc_metadata::creader: resolving crate extern crate libc as libc
INFO $TS: rustc_metadata::creader: resolving dep crate unwind hash: 23d16d19bf235477 extra filename: -4c9cbe622de116ab
INFO $TS: rustc_metadata::creader: resolving crate extern crate unwind as unwind
INFO $TS: rustc_metadata::creader: falling back to a load
INFO $TS: rustc_metadata::locator: lib candidate: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-4c9cbe622de116ab.rlib
INFO $TS: rustc_metadata::locator: rlib reading metadata from: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-4c9cbe622de116ab.rlib
INFO $TS: rustc_metadata::locator: reading "libunwind-4c9cbe622de116ab.rlib" => 53.925µs
INFO $TS: rustc_metadata::creader: register crate extern crate unwind as unwind
INFO $TS: rustc_metadata::creader: resolving dep crate core hash: af89e4eb0280bac6 extra filename: -f2133e8b70369157
INFO $TS: rustc_metadata::creader: resolving crate extern crate core as core
INFO $TS: rustc_metadata::creader: resolving dep crate compiler_builtins hash: d04ac580e8a9e993 extra filename: -71671e8958739d51
INFO $TS: rustc_metadata::creader: resolving crate extern crate compiler_builtins as compiler_builtins
INFO $TS: rustc_metadata::creader: resolving dep crate libc hash: e04f69583f78a1ba extra filename: -517830e9d56bab97
INFO $TS: rustc_metadata::creader: resolving crate extern crate libc as libc
INFO $TS: rustc_metadata::creader: resolving dep crate alloc_jemalloc hash: e11976872a475adc extra filename: -a7f738f7aa980965
INFO $TS: rustc_metadata::creader: resolving crate extern crate alloc_jemalloc as alloc_jemalloc
INFO $TS: rustc_metadata::creader: falling back to a load
INFO $TS: rustc_metadata::locator: lib candidate: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-a7f738f7aa980965.rlib
INFO $TS: rustc_metadata::locator: rlib reading metadata from: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-a7f738f7aa980965.rlib
INFO $TS: rustc_metadata::locator: reading "liballoc_jemalloc-a7f738f7aa980965.rlib" => 199.469µs
INFO $TS: rustc_metadata::creader: register crate extern crate alloc_jemalloc as alloc_jemalloc
INFO $TS: rustc_metadata::creader: resolving dep crate core hash: af89e4eb0280bac6 extra filename: -f2133e8b70369157
INFO $TS: rustc_metadata::creader: resolving crate extern crate core as core
INFO $TS: rustc_metadata::creader: resolving dep crate compiler_builtins hash: d04ac580e8a9e993 extra filename: -71671e8958739d51
INFO $TS: rustc_metadata::creader: resolving crate extern crate compiler_builtins as compiler_builtins
INFO $TS: rustc_metadata::creader: resolving dep crate libc hash: e04f69583f78a1ba extra filename: -517830e9d56bab97
INFO $TS: rustc_metadata::creader: resolving crate extern crate libc as libc
INFO $TS: rustc_metadata::creader: resolving dep crate panic_unwind hash: 1dcbbefca552f7b5 extra filename: -b89f1a9b548bfef9
INFO $TS: rustc_metadata::creader: resolving crate extern crate panic_unwind as panic_unwind
INFO $TS: rustc_metadata::creader: falling back to a load
INFO $TS: rustc_metadata::locator: lib candidate: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-b89f1a9b548bfef9.rlib
INFO $TS: rustc_metadata::locator: rlib reading metadata from: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-b89f1a9b548bfef9.rlib
INFO $TS: rustc_metadata::locator: reading "libpanic_unwind-b89f1a9b548bfef9.rlib" => 62.774µs
INFO $TS: rustc_metadata::creader: register crate extern crate panic_unwind as panic_unwind
INFO $TS: rustc_metadata::creader: resolving dep crate core hash: af89e4eb0280bac6 extra filename: -f2133e8b70369157
INFO $TS: rustc_metadata::creader: resolving crate extern crate core as core
INFO $TS: rustc_metadata::creader: resolving dep crate compiler_builtins hash: d04ac580e8a9e993 extra filename: -71671e8958739d51
INFO $TS: rustc_metadata::creader: resolving crate extern crate compiler_builtins as compiler_builtins
INFO $TS: rustc_metadata::creader: resolving dep crate alloc hash: de32cde30cc6bc18 extra filename: -2d44723f32308cf8
INFO $TS: rustc_metadata::creader: resolving crate extern crate alloc as alloc
INFO $TS: rustc_metadata::creader: resolving dep crate libc hash: e04f69583f78a1ba extra filename: -517830e9d56bab97
INFO $TS: rustc_metadata::creader: resolving crate extern crate libc as libc
INFO $TS: rustc_metadata::creader: resolving dep crate unwind hash: 23d16d19bf235477 extra filename: -4c9cbe622de116ab
INFO $TS: rustc_metadata::creader: resolving crate extern crate unwind as unwind
INFO $TS: rustc_driver::driver: 0 parse sess buffered_lints
INFO $TS: rustc_metadata::creader: resolving crate extern crate alloc_jemalloc as alloc_jemalloc
INFO $TS: rustc_metadata::creader: injecting a dep from 1 to 9
INFO $TS: rustc_metadata::creader: panic runtime not found -- loading panic_unwind
INFO $TS: rustc_metadata::creader: resolving crate extern crate panic_unwind as panic_unwind
INFO $TS: rustc_metadata::creader: injecting a dep from 1 to 9
INFO $TS: rustc_metadata::creader: resolved crates:
INFO $TS: rustc_metadata::creader: name: std
INFO $TS: rustc_metadata::creader: cnum: 1
INFO $TS: rustc_metadata::creader: hash: 55e0028ad01a6c49
INFO $TS: rustc_metadata::creader: reqd: Explicit
INFO $TS: rustc_metadata::creader: dylib: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-52f862a21e09568c.so
INFO $TS: rustc_metadata::creader: rlib: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-52f862a21e09568c.rlib
INFO $TS: rustc_metadata::creader: name: core
INFO $TS: rustc_metadata::creader: cnum: 2
INFO $TS: rustc_metadata::creader: hash: af89e4eb0280bac6
INFO $TS: rustc_metadata::creader: reqd: Explicit
INFO $TS: rustc_metadata::creader: rlib: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-f2133e8b70369157.rlib
INFO $TS: rustc_metadata::creader: name: compiler_builtins
INFO $TS: rustc_metadata::creader: cnum: 3
INFO $TS: rustc_metadata::creader: hash: d04ac580e8a9e993
INFO $TS: rustc_metadata::creader: reqd: Explicit
INFO $TS: rustc_metadata::creader: rlib: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-71671e8958739d51.rlib
INFO $TS: rustc_metadata::creader: name: alloc
INFO $TS: rustc_metadata::creader: cnum: 4
INFO $TS: rustc_metadata::creader: hash: de32cde30cc6bc18
INFO $TS: rustc_metadata::creader: reqd: Explicit
INFO $TS: rustc_metadata::creader: rlib: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-2d44723f32308cf8.rlib
INFO $TS: rustc_metadata::creader: name: alloc_system
INFO $TS: rustc_metadata::creader: cnum: 5
INFO $TS: rustc_metadata::creader: hash: 20b374f02cf54767
INFO $TS: rustc_metadata::creader: reqd: Explicit
INFO $TS: rustc_metadata::creader: rlib: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-48c8a8552cff934e.rlib
INFO $TS: rustc_metadata::creader: name: libc
INFO $TS: rustc_metadata::creader: cnum: 6
INFO $TS: rustc_metadata::creader: hash: e04f69583f78a1ba
INFO $TS: rustc_metadata::creader: reqd: Explicit
INFO $TS: rustc_metadata::creader: rlib: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-517830e9d56bab97.rlib
INFO $TS: rustc_metadata::creader: name: unwind
INFO $TS: rustc_metadata::creader: cnum: 7
INFO $TS: rustc_metadata::creader: hash: 23d16d19bf235477
INFO $TS: rustc_metadata::creader: reqd: Explicit
INFO $TS: rustc_metadata::creader: rlib: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-4c9cbe622de116ab.rlib
INFO $TS: rustc_metadata::creader: name: alloc_jemalloc
INFO $TS: rustc_metadata::creader: cnum: 8
INFO $TS: rustc_metadata::creader: hash: e11976872a475adc
INFO $TS: rustc_metadata::creader: reqd: Implicit
INFO $TS: rustc_metadata::creader: rlib: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-a7f738f7aa980965.rlib
INFO $TS: rustc_metadata::creader: name: panic_unwind
INFO $TS: rustc_metadata::creader: cnum: 9
INFO $TS: rustc_metadata::creader: hash: 1dcbbefca552f7b5
INFO $TS: rustc_metadata::creader: reqd: Implicit
INFO $TS: rustc_metadata::creader: rlib: $PWD/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-b89f1a9b548bfef9.rlib
error[E0391]: cycle detected when computing layout of Foo
|
note: ...which requires normalizing ParamEnvAnd { param_env: ParamEnv { caller_bounds: [], reveal: All }, value: [u8; _] }...
note: ...which requires const-evaluating Foo::bytes::{{constant}}...
= note: ...which again requires computing layout of Foo, completing the cycle
note: cycle used when const-evaluating Foo::bytes::{{constant}}

error: aborting due to previous error

For more information about this error, try rustc --explain E0391.
~~~~

Hopefully it's easy to reproduce with rust-lang's own rustc binaries.

[infinity0]

@michaelwoerister would our usage of --remap-path-prefix during the build, be interfering with the tests? If I ln -s src/libcore libcore the compilation output now contains the extra error detail, but the test still fails because the paths are different:

~~~~
[..]
10 note: cycle used when const-evaluating Foo::bytes::{{constant}}
- --> $SRC_DIR/libcore/mem.rs:LL:COL
+ --> libcore/mem.rs:289:5
12 |
[..]

$ strings ./build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-1361a4a303e9f67c.rlib | rg '/mem.rs'
libcore/mem.rs
$ strings ./build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-1361a4a303e9f67c.rlib | rg '/usr/src' | sort -u
/usr/src/rustc-1.31.0/src
~~~~

[johnterickson]

I am able to repro this at will in my CI environment if anyone has suggestions on extra logging to add or data to collect.

[oli-obk]

I'm not sure what the correct action to resolve this issue is.

Is it to change our test suite so it stops showing code snippets from the standard library?

[infinity0]

One way to fix this, assuming --remap-path-prefix is indeed the problem, is to make this mapping also apply to the definition of $SRC_DIR that the test harness uses. I did take a brief look but wasn't able to figure out how to hook that up, as I recall.

[RalfJung]

This affects not just distros building Rust; at least some tests on the i586-unknown-linux-gnu builder in our CI are also affected. So what is the currently recommended fix for that?
I see some tests added // ignore-x86. Is that considered best practice for this issue?

[petrochenkov]

I see some tests added // ignore-x86. Is that considered best practice for this issue?

This is certainly not a good practice.
My current suggestion is https://github.com/rust-lang/rust/pull/65421#issuecomment-544261831.

[RalfJung]

This is certainly not a good practice.

This should probably be fixed then.

My current suggestion is #65421 (comment).

That sounds like a hypothetical suggestion that needs libtest work first.
So what is it that we do right now to not block PRs on this one-year-old issue?

[RalfJung]

With https://github.com/rust-lang/rust/pull/66049 I am at least consolidating the existing work-arounds for this problem to all point to this issue here. There's around a dozen instances of this in our test suite.

[pnkfelix]

triage: P-high. Leaving nominated because T-compiler should discuss solutions to this.

[Centril]

@estebank Why was this nominated for T-release?

[estebank]

@Centril Isn't release in change of the per-platform binaries? I think this is partly a packaging issue, which makes me think they might want to be involved. Feel free to untag if I'm mistaken.

[pietroalbini]

Briefly discussed this during the infra meeting, and it wasn't clear to us why it was nominated to us.

[ehuss]

I think it might help to update the first comment with a summary of the issue. I'm not sure what the etiquette of that is.

A general summary:

The UI tests are written assuming --remap-path-prefix is not used (remap-debuginfo in config.toml). The consequence is that the error messages may include paths and snippets into the standard library. When remap-debuginfo is enabled, these messages change in format and structure because rustc will not show paths and snippets into the standard library.

This normally isn't a problem for the "main" platforms (linux/macos/windows), because the CI infrastructure is set up so that the tests run without remap-debuginfo, but the dist artifacts are built separately with remap-debuginfo enabled. However, some of the lower-tier platforms perform both tests and distribution in a single step with remap-debuginfo enabled. This also affects developers and distributors who use remap-debuginfo.

I see a few different approaches to fixing it:

• Separate the test and dist steps for the lower-tier platforms. I assume this is a no-go due to the extra CI burden. This doesn't help developers and distributors enabling it.
  
  
  
  • Alternatively, build a separate copy of the standard library with remap-debuginfo disabled to use only for tests. This should only add a few more minutes of extra time, but makes handling the sysroot more complex.
  
  
• Continue just disabling affected tests on the platforms where tests are run with remap-path-prefix enabled. This doesn't help developers and distributors enabling it.
• Change compiletest to somehow ignore fragments referencing the standard library. I don't see how that can be accomplished without significant effort.
• Change the diagnostic infrastructure so that it could filter sysroot paths during UI tests (maybe when -Zui-testing is set). I don't know how difficult that would be, but this seems like the most promising option.

Does that seem like a reasonable summary? Does anyone have any additional ideas or preferences?

I can see how this gets tossed between teams because it touches on CI infrastructure, rustbuild, compiletest, and compiler diagnostics.

[pietroalbini]

@ehuss thanks for the summary!

[RalfJung]

When remap-debuginfo is enabled, these messages change in format and structure because rustc will not show paths and snippets into the standard library.

Why does that option prevent printing libstd spans? Doesn't this mean libstd spans will also not be printed for users of Rust? If yes it seems best to make the testing setup match the one actually used by end-users.

[ehuss]

Why does that option prevent printing libstd spans?

This is stretching my knowledge of how diagnostics works, but from what I understand: The paths embedded in the std crate are remapped to things like /rustc/HASH/src/libstd/prelude/v1.rs. When the diagnostic printer goes to display a span from std, it tries to load that file and fails (because it doesn't exist), and skips it (I think this happens around here).

Doesn't this mean libstd spans will also not be printed for users of Rust?

Correct.

If yes it seems best to make the testing setup match the one actually used by end-users.

I think that would fall under either using -Zui-testing to have the diagnostic printer skip stdlib files, or build the standard library with remap-debuginfo enabled. I assume the later would be undesirable for developers, since it could cause problems with using a debugger (I think debuggers would fail to display source code). Or it could be a separate config.toml option? I'm not sure which is the best approach.

FWIW, with Cargo's build-std, you can see libstd spans since it doesn't use remap-path-prefix (unless the user sets that flag), so it is not impossible for a user to see them. I was delighted the first time I used a debugger with build-std and was able to step into the standard library. 🙂

[RalfJung]

I think that would fall under either using -Zui-testing to have the diagnostic printer skip stdlib files, or build the standard library with remap-debuginfo enabled.

That would mean making diagnostics as bad for tests as they are for distributed builds. It's consistent, but consistently not great.

I think the ideal outcome would be the opposite, to make diagnostics as good for distributed builds as they are for tests. libstd span printing should work even with the distributed artifacts. Strawman proposal: the paths could be remapped to $SYSROOT/src/libstd/prelude/v1.rs, and rustc could understand that $SYSROOT when displaying spans and search in the sysroot instead of taking that filename literally.

[eddyb]

However, some of the lower-tier platforms perform both tests and distribution in a single step with remap-debuginfo enabled.

Ooh, that explains everything! This is the first time I hear of this.

In that case, #53486 is indeed the solution IMO.
(@RalfJung's proposal appears to be equivalent)

[RalfJung]

@eddyb indeed that sounds like basically the same proposal. I just forgot that it requires people to install rust-src.

[pnkfelix]

I think that would fall under either using -Zui-testing to have the diagnostic printer skip stdlib files, or build the standard library with remap-debuginfo enabled.

That would mean making diagnostics as bad for tests as they are for distributed builds. It's consistent, but consistently not great.

I think the ideal outcome would be the opposite, to make diagnostics as good for distributed builds as they are for tests.

While I agree that the "ideal" outcome would be the opposite, I would just like to state that in my opinion, if we have to jump through many hoops to reach that ideal outcome, it would be an instance of letting "the best be the enemy of the good."

That is, I expect in practice it will be just fine for distributed builds to have the sysroot spans omitted from their diagnostics, and that likewise it would be just fine for our own ui tests to have them omitted too. In my own experience, the spans you care about checking are pointing into the ui tests themselves. Anything you want checked should be encoded in those tests.

(Maybe I just have low expectations for what value I expect our users to get out of seeing sysroot spans.)

[pnkfelix]

triage: Removing nomination label (T-compiler discussed this last week, and it seems like every other team has also discussed this recently, though perhaps with mixed enthusiasm due to confusion regarding relevance ...)

[estebank]

This seems to have affected windows as well.

[eddyb]

I took a deeper look at this, and the simplest approach for fixing #53486 won't directly fix this.
Or rather, won't fix running tests with remap-debuginfo = true in config.toml.

That's because there's no equivalent to the rust-src rustup component, for the stage{1,2} sysroots that exist while building/testing Rust. We could use a symlink to the real src directory, but I don't think that's supported on all platforms we build on (Windows and/or certain filesystems, AFAIK).

I'll work around that by removing a build/$CFG_COMPILER_HOST_TRIPLE/stage{0-sysroot,1,2} suffix from the sysroot, instead of adding lib/rustlib/src/rust (but only if the latter fails).

I'm also worried this might leak into codegen and cause non-deterministic builds, so we might have to do it only for loading the contents and diagnostics, or probably just gate the rewriting on --remap-path-prefix not being set to rewrite to the same /rustc/$HASH/ that rustc is rewriting to.

---

For the longest time I was confused and thought this needed "distcheck" to reproduce, but it's really just remap-debuginfo = true, which causes 56 tests to fail for ./x.py test --stage 1 src/test/ui, all of which mention this issue.

The remaining (non-failing) 26 tests that mention the issue are all src/test/ui/derives/derives-span-*.rs (except the Hash ones, since those are part of the failing 56), because src/etc/generate-deriving-span-tests.py generates the // ignores for all of them, even the ones that don't need it.