rustc: Remove Session::dep_graph
#44502
Conversation
|
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
alexcrichton
force-pushed
the
remove-session-dep-graph
branch
4 times, most recently
from
fca0733 to
789af95
Compare
|
Looks good to me, but something seems to have gone wrong somewhere because tests are failing. |
|
I've looked over the changes again and I don't see anything that should make a semantic difference. It's interesting that all failing tests are some kind of cross-crate scenarios. |
arielb1
added
the
S-waiting-on-author
|
Problem is that |
|
☔ The latest upstream changes (presumably #44420) made this pull request unmergeable. Please resolve the merge conflicts. |
|
So, it seems that moving incr-comp-session-dir initialization up to an earlier point suffices to make these tests fail. Don't know why yet. |
|
OK, so the problem is that we are reading the rust/src/librustc_driver/driver.rs Line 627 in 824952f We end up with a wrong directory for the crate and therefore can't find the metadata hashes later. When you fix this, @alexcrichton, could you also make sure that we get an ICE if someone tries to access the |
|
Oh wow thanks for helping debug that @michaelwoerister! I'll fix that and make an Ice |
alexcrichton
force-pushed
the
remove-session-dep-graph
branch
from
789af95 to
23c531b
Compare
|
@bors: r=michaelwoerister |
|
📌 Commit 23c531b has been approved by |
alexcrichton
force-pushed
the
remove-session-dep-graph
branch
from
23c531b to
0bf82f5
Compare
|
@bors: r=michaelwoerister |
|
📌 Commit 0bf82f5 has been approved by |
alexcrichton
force-pushed
the
remove-session-dep-graph
branch
2 times, most recently
from
6da258a to
9212b69
Compare
|
@bors: r=michaelwoerister |
|
📌 Commit 9212b69 has been approved by |
alexcrichton
force-pushed
the
remove-session-dep-graph
branch
from
9212b69 to
7e983d6
Compare
|
@bors: r=michaelwoerister |
|
📌 Commit 7e983d6 has been approved by |
|
⌛ Testing commit 7e983d6a178cfb75461ff498f5f02b03e3313ac4 with merge a2e806ad5f9636471725b35f353c8188b04b8bac... |
|
💔 Test failed - status-travis |
|
Cannot test stage1-librustc, legit. At least one |
This commit removes the `dep_graph` field from the `Session` type according to issue rust-lang#44390. Most of the fallout here was relatively straightforward and the `prepare_session_directory` function was rejiggered a bit to reuse the results in the later-called `load_dep_graph` function. Closes rust-lang#44390
alexcrichton
force-pushed
the
remove-session-dep-graph
branch
from
7e983d6 to
1cf956f
Compare
|
@bors: r=michaelwoerister |
|
📌 Commit 1cf956f has been approved by |
…elwoerister rustc: Remove `Session::dep_graph` This commit removes the `dep_graph` field from the `Session` type according to issue #44390. Most of the fallout here was relatively straightforward and the `prepare_session_directory` function was rejiggered a bit to reuse the results in the later-called `load_dep_graph` function. Closes #44390
|
☀️ Test successful - status-appveyor, status-travis |
|
Awesome! |
…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.
This commit removes the
dep_graphfield from theSessiontype according toissue #44390. Most of the fallout here was relatively straightforward and the
prepare_session_directoryfunction was rejiggered a bit to reuse the resultsin the later-called
load_dep_graphfunction.Closes #44390