thread 'rustc' panicked at 'src/librustc/session/mod.rs:809 with clean cargo new project
#59224
Comments
|
Problem does not exist when the project lives in the local filesystem. |
Centril
added
A-driver
|
Backtrace suggests issues with incremental? cc @Zoxc |
Centril
added
the
T-compiler
|
Does not occur on windows. Neither on a attached network folder (assign it to a letter, e.g. |
|
I suspect this is due to older SMB versions (pre-3.0) not supporting locking files. Not sure why we need that though. cc @michaelwoerister |
|
@Zoxc smbutil claims it's on 3.0, but I don't really trust macOS's SMB driver that much: |
|
Instead of using the lock file api, could we alternatively just open the file without |
|
The lock files are how |
|
@michaelwoerister what about providing an option to move the cache and/or the lockfiles outside of the source directory? That would have the added benefit of improved performance on networked file systems. |
|
Good thinking! As far as |
|
For any future googlers who may stumble on this, [build]
# Cargo doesn't support ~ expansion here.
target-dir = "/opt/my-special-target-dir"in |
…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.
I just created a new project with
cargo new rust-cliand then cd'ed into the directory and rancargo buildbut I got this error:I made no changes to the generated project after running
cargo new.Meta
I'm on macOS 10.14.2.
The project lives on an SMB file share. No idea whether that's relevant, but it's the only slightly unorthodox bit of my setup.
The text was updated successfully, but these errors were encountered: