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

Move the dep_graph construction to a dedicated crate. #67761

Merged
merged 9 commits into from
Mar 24, 2020

Conversation

cjgillot
Copy link
Contributor

The interface for librustc consists in two traits: DepKind and DepContext.

The DepKind is the main interface. It allows to probe properties of the dependency.
As before, DepNode is the pair of a DepKind object and a hash fingerprint.

The DepContext takes the place of the TyCtxt, and handles communication with the query engine.

The use of the ImplicitCtxt through ty::tls is done through the DepKind trait.
This may not be the best choice, but it seemed like the simplest.

@rust-highfive
Copy link
Collaborator

r? @zackmdavis

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 31, 2019
@cjgillot
Copy link
Contributor Author

cc #65031

src/librustc_dep_graph/lib.rs Outdated Show resolved Hide resolved
src/librustc_dep_graph/lib.rs Outdated Show resolved Hide resolved
src/librustc_dep_graph/lib.rs Outdated Show resolved Hide resolved
@Centril
Copy link
Contributor

Centril commented Dec 31, 2019

r? @Zoxc

@rust-highfive rust-highfive assigned Zoxc and unassigned zackmdavis Dec 31, 2019
@Zoxc
Copy link
Contributor

Zoxc commented Dec 31, 2019

I think this PR will need some discussion, cc @michaelwoerister

@michaelwoerister
Copy link
Member

Thanks for flagging that, @Zoxc. I think this PR is indeed a bit too invasive to just merge it. Is there any plan agreed upon by the compiler team for splitting things into more crates? I'm all for moving things out of librustc but it would be good to discuss the high-level picture/crate structure before jumping into bigger refactorings.

@Centril
Copy link
Contributor

Centril commented Jan 2, 2020

Is there any plan agreed upon by the compiler team for splitting things into more crates? I'm all for moving things out of librustc but it would be good to discuss the high-level picture/crate structure before jumping into bigger refactorings.

I think there's a general desire to split things and we've had a design meeting where we loosely agreed to splitting crates based on data vs. logic crates (see e.g. #65324). The execution of that will vary depending on how deep the implicit dependencies go and how much of a mess there is to untangle. Therefore it will be hard to come up with any grand scheme, and so we should experiment and see what logical units pop out and land those.

From what I can tell of the specifics in this PR, it will allow me to further move parts of the HIR (the Map & friends) out of librustc beyond what #67803 achieves.

@michaelwoerister
Copy link
Member

Therefore it will be hard to come up with any grand scheme, and so we should experiment and see what logical units pop out and land those.

It might not be easy but I think it is still worthwhile to define a clean goal to work towards. Otherwise there's the risking of ending up with even more accidental complexity.

@Centril
Copy link
Contributor

Centril commented Jan 2, 2020

It might not be easy but I think it is still worthwhile to define a clean goal to work towards.

I don't disagree, but that clean goal will necessarily be vague and very high level (e.g. a list of crate names and a vague notion of dependencies). Only by actually trying it out experimentally will we find out if it is possible or not.

Otherwise there's the risking of ending up with even more accidental complexity.

I actually doubt this. The longer librustc exists the more it invites chaos (I'm looking at you rustc::mir & rustc_mir) and adding more implicit dependencies over time. By splitting things we'll architecturally prevent "what's another hack". Merging crates is also easier than splitting.

@petrochenkov
Copy link
Contributor

petrochenkov commented Jan 2, 2020

I'm wary of introducing more bureaucracy because things may end up similarly to the start-to-end queries - years pass and very little happens except for some meetings once in few months.

The crate-ification with the general, even if vague, "separate data vs logic" idea in mind actively improves build times and parallelism now, making any other work easier.
I'm happy with how it worked out for the libsyntax split so far, and wouldn't mind if people actively working on other parts of the compiler performed this crate-ification independently in accordance with their expertise and domain knowledge, without a centralized compiler team approval.

@michaelwoerister
Copy link
Member

End-to-end queries has to solve lots of hard architectural problems. You call it "bureaucracy", I call it a safe guard that has prevented us from making unnecessary mistakes :)

I think there should be a high-level tracking, stating something like @Centril mentioned on discord:

"clean goal" is I think to have at least one data crate for each IR and then a series of in-out crates for e.g. AST -> HIR, HIR -> HAIR, ...

I think that (vague) goal can be considered as approved by the compiler team. I also it should be made a bit more concrete, with at least the list of "header" crates we are shooting for.

I do agree that large parts of this are domain specific and "local" questions should not have to wait for compiler team approval. I would just like to have a little more transparency of what's even going on. This is something the team is discussed in the last design meeting: https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-12-20-major-change-process/

@michaelwoerister
Copy link
Member

I should be able to take a closer look at this next week. @Zoxc, feel free to assign this to me.

bors added a commit that referenced this pull request Jan 4, 2020
Extract `rustc_hir` out of `rustc`

The new crate contains:
```rust
pub mod def;
pub mod def_id;
mod hir;
pub mod hir_id;
pub mod itemlikevisit;
pub mod pat_util;
pub mod print;
mod stable_hash_impls;

pub use hir::*;
pub use hir_id::*;
pub use stable_hash_impls::HashStableContext;
```

Remains to be done in follow-up PRs:

- Move `rustc::hir::map` into `rustc_hir_map` -- this has to be a separate crate due to the `dep_graph` (blocked on #67761).

- Move references to `rustc::hir` to `rustc_hir` where possible.

cc #65031

r? @Zoxc
@bors
Copy link
Contributor

bors commented Jan 5, 2020

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

@bors
Copy link
Contributor

bors commented Jan 9, 2020

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

@michaelwoerister
Copy link
Member

michaelwoerister commented Jan 10, 2020

From my point of view we can go forward with this PR as it is. I have a gut feeling that things could be factored slightly better so that not everything goes through DepKind but that can be looked into at some other time and should not cause major changes.

I'll leave it to @Zoxc to give the final r+.

@cjgillot
Copy link
Contributor Author

From my point of view we can go forward with this PR as it is. I have a gut feeling that things could be factored slightly better so that not everything goes through DepKind but that can be looked into at some other time and should not cause major changes.

I plan to do it in a follow-up PR.

@bors
Copy link
Contributor

bors commented Jan 10, 2020

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

@cjgillot
Copy link
Contributor Author

Rebased.

@bors
Copy link
Contributor

bors commented Jan 10, 2020

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

@cjgillot
Copy link
Contributor Author

I have implemented a cleverer interface in commit 9aa0a9a2bbaad8f7fc27648a126294d4e668c252. I can add it to this PR if you think it good enough.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 23, 2020
@bors
Copy link
Contributor

bors commented Mar 23, 2020

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

@cjgillot
Copy link
Contributor Author

Rebased.

@Zoxc
Copy link
Contributor

Zoxc commented Mar 23, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Mar 23, 2020

📌 Commit 0f918cb has been approved by Zoxc

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 23, 2020
@Centril Centril removed the S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. label Mar 23, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 24, 2020
Rollup of 11 pull requests

Successful merges:

 - rust-lang#67761 (Move the dep_graph construction to a dedicated crate.)
 - rust-lang#69740 (Replace some desc logic in librustc_lint with article_and_desc)
 - rust-lang#69981 (Evaluate repeat expression lengths as late as possible)
 - rust-lang#70087 (Remove const eval loop detector)
 - rust-lang#70242 (Improve E0308 error message wording)
 - rust-lang#70264 (Fix invalid suggestion on `&mut` iterators yielding `&` references)
 - rust-lang#70267 (get rid of ConstPropUnsupported; use ZST marker structs instead)
 - rust-lang#70277 (Remove `ReClosureBound`)
 - rust-lang#70283 (Add regression test for rust-lang#70155.)
 - rust-lang#70294 (Account for bad placeholder types in where clauses)
 - rust-lang#70309 (Clean up E0452 explanation)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Mar 24, 2020

⌛ Testing commit 0f918cb with merge 342c5f3...

@bors
Copy link
Contributor

bors commented Mar 24, 2020

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

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 24, 2020
@bors bors merged commit 9da25d9 into rust-lang:master Mar 24, 2020
) -> (R, DepNodeIndex)
where
C: DepGraphSafe + StableHashingContextProvider<'a>,
C: DepGraphSafe + HashStableContextProvider<H>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can replace DepGraphSafe + HashStableContextProvider<H> with DepContext here and in with_task_impl and with_eval_always_task. Then you could remove both DepGraphSafe and HashStableContextProvider.

@cjgillot cjgillot deleted the split_graph branch March 24, 2020 06:29
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 27, 2020
Move the query system to a dedicated crate

The query system `rustc::ty::query` is split out into the `rustc_query_system` crate.

Some commits are unformatted, to ease rebasing.

Based on rust-lang#67761 and rust-lang#69910.

r? @Zoxc
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.