Names in expected compiler error messages are sometimes qualified and sometimes not

[CarlKCarlK]

When I run

#[test]
fn ui() {
    let t = trybuild::TestCases::new();
    t.compile_fail("tests/ui/*.rs");
}

on my local machine's Windows and WSL Ubuntu, I get an expected compiler error message such as:

  | doesn't satisfy `_: MultiwayRangeSetBlaze<'_, _>`

When I run on GitHub actions or when another dev runs on their machine the error message becomes qualified with (for example) "range_set_blaze::":

  | doesn't satisfy `_: range_set_blaze::MultiwayRangeSetBlaze<'_, _>`

This also happens with Iter vs std::slice::Iter. I think all the machines are running rustc 1.69.0.

Any ideas on what could be making the compiler slightly give different error messages?

Thanks,
Carl

p.s. In case someone wants a repro:

git clone https://github.com/CarlKCarlK/range-set-blaze.git delui                                             │
cd delui                                                                                                      │
git checkout 9f2088                                                                                           │
cargo test ui

Should say "1 passed"

[dtolnay]

I cannot reproduce a difference in qualified-ness. For me, locally and in GitHub Actions, using a 1.69.0 toolchain, paths in the error are always unqualified. My best guess is your CI was not using the toolchain you thought it was.

[dtolnay]

I confirmed that the hash you gave (9f2088a063) passes cargo test on my machine using 1.69.0, and also on GitHub Actions using 1.69.0 (CarlKCarlK/range-set-blaze@14bdd5b).

I also confirmed that UI tests on your current main branch and current stable toolchain work the same locally and all the platforms in GitHub Actions (CarlKCarlK/range-set-blaze@33ae458).

[CarlKCarlK]

David,

Thanks for looking into this. I now wonder if UI tests that compare complicated error messages are practical. In the hope that things would just start working, I tried again. According to "rustc --version" both my local Windows (and Ubuntu) and GitHub CI are running: rustc 1.70.0 (90c541806 2023-05-31), but the error output is just a little different:

EXPECTED:
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
error[E0599]: the method `union` exists for struct `Tee<Iter<'_, ({integer}, {integer})>>`, but its trait bounds were not satisfied
 --> tests/ui/tee.rs:8:17
  |
8 |     let _c = a0.union(a1);
  |                 ^^^^^ method cannot be called on `Tee<Iter<'_, ({integer}, {integer})>>` due to unsatisfied trait bounds
  |
 ::: $RUST/core/src/slice/iter.rs
  |
  | pub struct Iter<'a, T: 'a> {
  | -------------------------- doesn't satisfy `_: SortedDisjoint<_>`
  |
...
ACTUAL OUTPUT:
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
error[E0599]: the method `union` exists for struct `Tee<Iter<'_, ({integer}, {integer})>>`, but its trait bounds were not satisfied
 --> tests/ui/tee.rs:8:17
  |
8 |     let _c = a0.union(a1);
  |                 ^^^^^ method cannot be called on `Tee<Iter<'_, ({integer}, {integer})>>` due to unsatisfied trait bounds
 --> $RUST/core/src/slice/iter.rs
  |
  = note: doesn't satisfy `_: SortedDisjoint<_>`
  |

https://github.com/CarlKCarlK/range-set-blaze/actions/runs/5459393103/jobs/9935353753#step:7:1229

I don't see any way to figure out the cause of the difference, so I'll just leave UI tests off for now.

(Thanks for all the great tools that you've created.)

• Carl

[dtolnay]

I think that difference would be from the rust-src rustup component not being installed in CI. Without rust-src, rustc won't be able to render standard library source snippets into your errors. You have rust-src installed locally because I see a standard library "pub struct Iter<'a, T: 'a> {" in your .stderr file.

In CI:

      - uses: dtolnay/rust-toolchain@stable
        with:
          components: rust-src

[CarlKCarlK]

Thanks! Adding components: rust-src fixed the bug in my project's testing.

(I've also updated an article that recommended UI testing with a note to mind the toolchain.)