Invalid paths are suggested for "possibly newer version of crate" error on Windows

[fhahn]

#30778 uncovered that on Windows (Rust compiled with msvc), additional paths are suggested when there's a newer version of a crate, e.g. e.g. for changing-crates.rs the following notes are emitted:

C:/bot/slave/auto-win-msvc-64-opt/build/src/test/compile-fail/changing-crates.rs:17:1: 17:16 note: crate `a` path #1: \\?\C:\bot\slave\auto-win-msvc-64-opt\build\obj\x86_64-pc-windows-msvc\test\compile-fail\changing-crates.stage2-x86_64-pc-windows-msvc.compile-fail.libaux\a.dll
C:/bot/slave/auto-win-msvc-64-opt/build/src/test/compile-fail/changing-crates.rs:17:1: 17:16 note: crate `b` path #1: \\?\C:\bot\slave\auto-win-msvc-64-opt\build\obj\x86_64-pc-windows-msvc\test\compile-fail\changing-crates.stage2-x86_64-pc-windows-msvc.compile-fail.libaux\b.dll
C:/bot/slave/auto-win-msvc-64-opt/build/src/test/compile-fail/changing-crates.rs:17:1: 17:16 help: please recompile this crate using --crate-type lib
C:/bot/slave/auto-win-msvc-64-opt/build/src/test/compile-fail/changing-crates.rs:17:1: 17:16 note: crate `a` path #1: x86_64-pc-windows-msvc/test/compile-fail\changing-crates.stage2-x86_64-pc-windows-msvc.compile-fail.libaux\a.dll.lib
C:/bot/slave/auto-win-msvc-64-opt/build/src/test/compile-fail/changing-crates.rs:17:1: 17:16 note: crate `a` path #2: C:\bot\slave\auto-win-msvc-64-opt\build\obj\x86_64-pc-windows-msvc\stage2\lib\rustlib\x86_64-pc-windows-msvc\lib\arena-db5a760f.dll.lib

The last two notes shouldn't be there. The first of those seem to point to the one already suggested, except that the first part is missing and slashes instead of backslashes are used. The last note suggests arena-db5a760f.dll.lib, but that does not seem right at all.

The following tests fail due to this issue (marked as // ignore-msvc for now)

[compile-fail] compile-fail/changing-crates.rs
[compile-fail] compile-fail/svh-change-lit.rs
[compile-fail] compile-fail/svh-change-significant-cfg.rs
[compile-fail] compile-fail/svh-change-trait-bound.rs
[compile-fail] compile-fail/svh-change-type-arg.rs
[compile-fail] compile-fail/svh-change-type-ret.rs
[compile-fail] compile-fail/svh-change-type-static.rs
[compile-fail] compile-fail/svh-use-trait.rs

[petrochenkov]

I see these error all the time on Windows/GNU, but never got to actually reporting them.

How to reproduce:

• Get a fresh clone of Rust repo.
• make check-stage1-cfail, everything passes, these errors never happen right away.
• work with Rust repo, change things, recompile, not sure what exactly needs to be changed
• make check-stage1-cfail again, several stage1 tests fail, these tests never fail on stage2 as part of make check

Failing tests:

failures:
    [compile-fail] compile-fail\changing-crates.rs
    [compile-fail] compile-fail\svh-change-lit.rs
    [compile-fail] compile-fail\svh-change-significant-cfg.rs
    [compile-fail] compile-fail\svh-change-trait-bound.rs
    [compile-fail] compile-fail\svh-change-type-arg.rs
    [compile-fail] compile-fail\svh-change-type-ret.rs
    [compile-fail] compile-fail\svh-change-type-static.rs

Output of one of the tests:

---- [compile-fail] compile-fail\svh-change-type-static.rs stdout ----

error: C:/msys64/home/we/rust/src/test/compile-fail/svh-change-type-static.rs:19: unexpected "note": '19:1: 19:16: crate `a` path #1: \\?\C:\msys64\home\we\rust\build0\x86_64-pc-windows-gnu\stage1\lib\rustlib\x86_64-pc-windows-gnu\lib\libarena-fdb5dc8c.rlib compiled by "rustc 1.15.0-dev (dcad4c53f 2016-12-16)"'

error: C:/msys64/home/we/rust/src/test/compile-fail/svh-change-type-static.rs:19: unexpected "note": '19:1: 19:16: crate `a` path #2: \\?\C:\msys64\home\we\rust\build0\x86_64-pc-windows-gnu\stage1\lib\rustlib\x86_64-pc-windows-gnu\lib\arena-fdb5dc8c.dll compiled by "rustc 1.15.0-dev (dcad4c53f 2016-12-16)"'

error: 2 unexpected errors found, 0 expected errors not found
status: exit code: 101
command: PATH="blahblahblah" x86_64-pc-windows-gnu/stage1/bin/rustc.exe C:/msys64/home/we/rust/src/test/compile-fail/svh-change-type-static.rs -L x86_64-pc-windows-gnu/test/compile-fail/ --target=x86_64-pc-windows-gnu --error-format json -L x86_64-pc-windows-gnu/test/compile-fail\svh-change-type-static.stage1-x86_64-pc-windows-gnu.compile-fail.libaux -C prefer-dynamic -o x86_64-pc-windows-gnu/test/compile-fail\svh-change-type-static.stage1-x86_64-pc-windows-gnu.exe --cfg rtopt -C rpath -O -L x86_64-pc-windows-gnu/rt
unexpected errors (from JSON output): [
    Error {
        line_num: 19,
        kind: Some(
            Note
        ),
        msg: "19:1: 19:16: crate `a` path #1: \\\\?\\C:\\msys64\\home\\we\\rust\\build0\\x86_64-pc-windows-gnu\\stage1\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libarena-fdb5dc8c.rlib compiled by \"rustc 1.15.0-dev (dcad4c53f 2016-12-16)\""
    },
    Error {
        line_num: 19,
        kind: Some(
            Note
        ),
        msg: "19:1: 19:16: crate `a` path #2: \\\\?\\C:\\msys64\\home\\we\\rust\\build0\\x86_64-pc-windows-gnu\\stage1\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\arena-fdb5dc8c.dll compiled by \"rustc 1.15.0-dev (dcad4c53f 2016-12-16)\""
    }
]

thread '[compile-fail] compile-fail\svh-change-type-static.rs' panicked at 'explicit panic', C:/msys64/home/we/rust/src/tools/compiletest/src\runtest.rs:1114

cc @michaelwoerister

[michaelwoerister]

@petrochenkov Did I do that? :)

[petrochenkov]

@michaelwoerister
I believe this started together with all the work on incremental compilation / hashing, so you or @nikomatsakis probably had highest chances to make the change causing this.

[michaelwoerister]

@petrochenkov It's possible. But off the top of my head I can't think of anything that would cause that.
@alexcrichton might also no something?

[alexcrichton]

I feel like I've seen errors like this all the time when the build dir gets into weird states, but starting back from a stage0 libstd usually fixes everything. I've never had a chance to track it down unfortunately so nothing leaps to mind :(

[nikomatsakis]

I can't think of anything that incremental would have done to cause this, but I have observed this sort of thing I think (though not on Windows) -- this is not to say that changes for incremental are not at fault in some way of course.

[ChrisDenton]

Is this still an issue? It's been a few years without comment so I'm just wondering if it's been fixed in the meantime?