Incremental compilation + case insensitive filesystems == sadness

[alexcrichton]

Given this code

mod a { pub fn foo() {} }
mod A { pub fn foo() {} }

pub fn main() {
    a::foo();
    A::foo();
}

when compiled on (for example) Windows:

$ rustc +nightly -C incremental=incr foo.rs --crate-type rlib
warning: module `A` should have a snake case name such as `a`
 --> foo.rs:2:1
  |
2 | mod A { pub fn foo() {} }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(non_snake_case)] on by default

error: failed to remove foo.foo-a.rcgu.o: The system cannot find the file specified. (os error 2)

error: failed to remove foo.foo-a.rcgu.bytecode.encoded: The system cannot find the file specified. (os error 2)

warning: Error finalizing incremental compilation session directory `\\?\C:\msys64\home\alex\incr\foo-2274d9nt8ooh9\s-ex32xyt5c1-1f7ubw8-working`: The system cannot find the file specified. (os error 2)

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.24.0-nightly (0a3761e63 2018-01-03) running on x86_64-pc-windows-msvc

thread 'rustc' panicked at 'src\librustc\session\mod.rs:645: Trying to invalidate IncrCompSession `InvalidBecauseOfErrors { session_directory: "\\\\?\\C:\\msys64\\home\\alex\\incr\\foo-2274d9nt8ooh9\\s-ex32xyt5c1-1f7ubw8-working" }`', src\librustc\session\mod.rs:1130:26
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I'll be fixing the ICE as part of #47141 as it's preventing it from landing (the ICE isn't really the issue here anyway, it's the "failed to remove" business). This is also a serious problem for linking artifacts!

$ rustc +nightly -C incremental=incr foo.rs
warning: module `A` should have a snake case name such as `a`
 --> foo.rs:2:1
  |
2 | mod A { pub fn foo() {} }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(non_snake_case)] on by default

error: linking with `link.exe` failed: exit code: 1120
  |
  = note: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX64\\x64\\link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "foo.__rustc_fallback_codegen_unit.rcgu.o" "foo.foo.rcgu.o" "foo.foo-A.rcgu.o" "foo.foo-a.rcgu.o" "foo.std-rt.volatile.rcgu.o" "/OUT:foo.exe" "foo.crate.allocator.rcgu.o" "/OPT:REF,NOICF" "/DEBUG" "/NATVIS:C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\intrinsic.natvis" "/NATVIS:C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\liballoc.natvis" "/NATVIS:C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\libcore.natvis" "/LIBPATH:C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-86003fe2ba26724d.rlib" "C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-bb826b401e977c60.rlib" "C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-d08d48f09a9d2f10.rlib" "C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liblibc-2641bedcb07f8f2a.rlib" "C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc_system-d4cd645fbdb93df8.rlib" "C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-9fb3c940ca5fe920.rlib" "C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd_unicode-e033f95dfa73709c.rlib" "C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-b24b1226646be575.rlib" "C:\\Users\\alex\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-98237266b8364c3b.rlib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "msvcrt.lib"
  = note: foo.foo-a.rcgu.o : warning LNK4042: object specified more than once; extras ignored
          foo.foo.rcgu.o : error LNK2019: unresolved external symbol _ZN3foo1A3foo17hcc8ef77d474fdbcdE referenced in function _ZN3foo4main17hdc141899c6b702c7E
          foo.exe : fatal error LNK1120: 1 unresolved externals


error: aborting due to previous error

cc @michaelwoerister

[alexcrichton]

Note that this was discovered as part of #47141 in these failing logs. Notably the generated bindings in style for Gecko contains a mod js in addition to a mod JS. That didn't cause link errors (thankfully) but is causing the CI to bounce.

[alexcrichton]

(also the reason for this is that we're putting module names in filenames on the filesystem, and that's how the conflict is arising -- the two module object files get canonicalized into the same file)

[retep998]

Would this be fixed by switching to using hashes as the filenames as proposed in #47186?

[michaelwoerister]

@retep998 Yes, the same fix should apply.

[michaelwoerister]

This should be fixed by #47269 (which is in the latest nightly already). @alexcrichton, was that a regular NTFS file system you were testing this on? In that case it should be easy to write a regression test (that actually triggers).

[michaelwoerister]

I don't think this is a regression, btw. The underlying logic has been there from pretty much the beginning.

[retep998]

The regression was when incremental compilation was changed to be enabled by default.

[alexcrichton]

@michaelwoerister this is indeed fixed, thanks!

[michaelwoerister]

I'll do a backport then.