Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustc: Remove Session::dep_graph #44502

Merged
merged 1 commit into from
Sep 15, 2017

Conversation

alexcrichton
Copy link
Member

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

@rust-highfive
Copy link
Collaborator

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member Author

r? @michaelwoerister

@alexcrichton alexcrichton force-pushed the remove-session-dep-graph branch 4 times, most recently from fca0733 to 789af95 Compare September 12, 2017 04:09
@michaelwoerister
Copy link
Member

Looks good to me, but something seems to have gone wrong somewhere because tests are failing.

@michaelwoerister
Copy link
Member

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 arielb1 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 12, 2017
@nikomatsakis
Copy link
Contributor

Problem is that MetaData(a::function1) is changing (when it did not before).

@bors
Copy link
Contributor

bors commented Sep 13, 2017

☔ The latest upstream changes (presumably #44420) made this pull request unmergeable. Please resolve the merge conflicts.

@michaelwoerister
Copy link
Member

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.

@michaelwoerister
Copy link
Member

OK, so the problem is that we are reading the crate_disambiguator from the Session before it is initialized here:

*sess.crate_disambiguator.borrow_mut() = Symbol::intern(&compute_crate_disambiguator(sess));

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 crate_disambiguator before it is initialized?

@alexcrichton
Copy link
Member Author

Oh wow thanks for helping debug that @michaelwoerister! I'll fix that and make an Ice

@alexcrichton
Copy link
Member Author

@bors: r=michaelwoerister

@bors
Copy link
Contributor

bors commented Sep 13, 2017

📌 Commit 23c531b has been approved by michaelwoerister

@alexcrichton
Copy link
Member Author

@bors: r=michaelwoerister

@bors
Copy link
Contributor

bors commented Sep 13, 2017

📌 Commit 0bf82f5 has been approved by michaelwoerister

@alexcrichton alexcrichton force-pushed the remove-session-dep-graph branch 2 times, most recently from 6da258a to 9212b69 Compare September 13, 2017 17:41
@alexcrichton
Copy link
Member Author

@bors: r=michaelwoerister

@bors
Copy link
Contributor

bors commented Sep 13, 2017

📌 Commit 9212b69 has been approved by michaelwoerister

@alexcrichton
Copy link
Member Author

@bors: r=michaelwoerister

@bors
Copy link
Contributor

bors commented Sep 13, 2017

📌 Commit 7e983d6 has been approved by michaelwoerister

@bors
Copy link
Contributor

bors commented Sep 14, 2017

⌛ Testing commit 7e983d6a178cfb75461ff498f5f02b03e3313ac4 with merge a2e806ad5f9636471725b35f353c8188b04b8bac...

@bors
Copy link
Contributor

bors commented Sep 14, 2017

💔 Test failed - status-travis

@kennytm
Copy link
Member

kennytm commented Sep 14, 2017

Cannot test stage1-librustc, legit. At least one build_session_ call not fixed.

[01:06:59]    Compiling rustc_driver v0.0.0 (file:///checkout/src/librustc_driver)
[01:07:01] error[E0061]: this function takes 4 parameters but 5 parameters were supplied
[01:07:01]    --> /checkout/src/librustc_driver/test.rs:108:40
[01:07:01]     |
[01:07:01] 108 |     let sess = session::build_session_(options,
[01:07:01]     |                                        ^^^^^^^ expected 4 parameters
[01:07:01]
[01:07:02] error: aborting due to previous error
[01:07:02]
[01:07:02] error: Could not compile `rustc_driver`.
[01:07:02] warning: build failed, waiting for other jobs to finish...
[01:08:24] error: build failed

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
Copy link
Member Author

@bors: r=michaelwoerister

@bors
Copy link
Contributor

bors commented Sep 14, 2017

📌 Commit 1cf956f has been approved by michaelwoerister

@bors
Copy link
Contributor

bors commented Sep 14, 2017

⌛ Testing commit 1cf956f with merge 2d288a5...

bors added a commit that referenced this pull request Sep 14, 2017
…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
@bors
Copy link
Contributor

bors commented Sep 15, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing 2d288a5 to master...

@bors bors merged commit 1cf956f into rust-lang:master Sep 15, 2017
@michaelwoerister
Copy link
Member

Awesome!

@alexcrichton alexcrichton deleted the remove-session-dep-graph branch September 15, 2017 14:29
bors added a commit to rust-lang-ci/rust that referenced this pull request May 29, 2021
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants