-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Conversation
r? @zackmdavis (rust_highfive has picked a reviewer for you, use r? to override) |
cc #65031 |
r? @Zoxc |
I think this PR will need some discussion, cc @michaelwoerister |
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 |
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. |
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. |
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.
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. |
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. |
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:
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/ |
I should be able to take a closer look at this next week. @Zoxc, feel free to assign this to me. |
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
☔ The latest upstream changes (presumably #67803) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #68034) made this pull request unmergeable. Please resolve the merge conflicts. |
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 I'll leave it to @Zoxc to give the final r+. |
I plan to do it in a follow-up PR. |
☔ The latest upstream changes (presumably #67397) made this pull request unmergeable. Please resolve the merge conflicts. |
Rebased. |
☔ The latest upstream changes (presumably #68101) made this pull request unmergeable. Please resolve the merge conflicts. |
I have implemented a cleverer interface in commit 9aa0a9a2bbaad8f7fc27648a126294d4e668c252. I can add it to this PR if you think it good enough. |
☔ The latest upstream changes (presumably #70330) made this pull request unmergeable. Please resolve the merge conflicts. |
This is needed since `middle::cstore` defines another type named `DepKind`, and we should not rely on shadowing to get the right one.
Rebased. |
@bors r+ |
📌 Commit 0f918cb has been approved by |
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
☔ The latest upstream changes (presumably #70343) made this pull request unmergeable. Please resolve the merge conflicts. |
) -> (R, DepNodeIndex) | ||
where | ||
C: DepGraphSafe + StableHashingContextProvider<'a>, | ||
C: DepGraphSafe + HashStableContextProvider<H>, |
There was a problem hiding this comment.
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
.
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
The interface for librustc consists in two traits:
DepKind
andDepContext
.The
DepKind
is the main interface. It allows to probe properties of the dependency.As before,
DepNode
is the pair of aDepKind
object and a hash fingerprint.The
DepContext
takes the place of theTyCtxt
, and handles communication with the query engine.The use of the
ImplicitCtxt
throughty::tls
is done through theDepKind
trait.This may not be the best choice, but it seemed like the simplest.