Incremental compilation ICEs on Windows in file systems that don’t support file locking #66513
Comments
jonas-schievink
added
A-incr-comp
|
I think this could be fixed by changing https://github.com/rust-lang/rust/blob/master/src/librustc_data_structures/flock.rs#L155-L162 to: if ret == 0 {
let err = io::Error::last_os_error();
debug!("failed acquiring file lock: {}", err);
Err(err)
} else if ret == ERROR_INVALID_FUNCTION {
debug!("locking not supported");
Ok(Lock { _file: file })
} else {
debug!("successfully acquired lock");
Ok(Lock { _file: file })
} |
|
Note that cargo's implementation seems much more robust than rustc's. Perhaps they should be unified somehow? |
|
Encountered this issue on a virtual machine using Vagrant/VirtualBox: VM My (host) machine @chris-morgan, thankfully, pointed out that it's related to this issue that he opened and the current work-around is to disable incremental compilation via environment variable |
|
I think this is the same as #80027, which I have closed in favor of this. My link might provide an even easier way to reproduce. This bug still exists both on nightly and stable (as of 13 December, 2020) |
|
EDIT: The PR linked directly above has concluded that it's important not to ignore lock errors therefore this would not be a good idea. |
…tebank Don't panic when failing to initialize incremental directory. This removes a panic when rustc fails to initialize the incremental directory. This can commonly happen on various filesystems that don't support locking (often various network filesystems). Panics can be confusing and scary, and there are already plenty of issues reporting this. This has been panicking since 1.22 due to I think rust-lang#44502 which was a major rework of how things work. Previously, things were simpler and the [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.21.0/src/librustc_incremental/persist/load.rs#L43-L65) function would emit an error and then continue on without panicking. With 1.22, [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.22.0/src/librustc_incremental/persist/load.rs#L44) was changed so that it assumes it can load the data without errors. Today, the problem is that it calls [`prepare_session_directory`](https://github.com/rust-lang/rust/blob/fbf1b1a7193cda17008ab590e06ad28d9924023b/compiler/rustc_interface/src/passes.rs#L175-L179) and then immediately calls `garbage_collect_session_directories` which will panic since the session is `IncrCompSession::NotInitialized`. The solution here is to have `prepare_session_directory` return an error that must be handled so that compilation stops if it fails. Some other options: * Ignore directory lock failures. * Print a warning on directory lock failure, but otherwise continue with incremental enabled. * Print a warning on directory lock failure, and disable incremental. * Provide a different locking mechanism. Cargo ignores lock errors if locking is not supported, so that would be a precedent for the first option. These options would require quite a bit more changes, but I'm happy to entertain any of them, as I think they all have valid justifications. There is more discussion on the many issues where this is reported: rust-lang#49773, rust-lang#59224, rust-lang#66513, rust-lang#76251. I'm not sure if this can be considered closing any of those, though, since I think there is some value in discussing if there is a way to avoid the error altogether. But I think it would make sense to at least close all but one to consolidate them.
Put a bunch of Rust code with dependencies on WSL in Windows 10, and try to compile it using Rust on the Windows side (so that the working directory will start with
\\wsl$\), and incremental compilation falls over.In order to reproduce this with Cargo, you must include the patch in rust-lang/cargo#7602, or else rust-lang/cargo#7511 (which basically corresponds to this report) will have Cargo fail before ever invoking rustc.(That fix has now landed.)The important part of the
cargo buildoutput, with RUST_BACKTRACE=full:I was compiling the cpal crate with the working directory
\\wsl$\arch\home\me\code\cpal, usingcargo build. I think anything with a few dependencies will hit this.I haven’t done any code diving at this time, but I imagine the patch I applied to Cargo, rust-lang/cargo#7602, may be useful reference material.
The text was updated successfully, but these errors were encountered: