-
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
incr.comp.: Crate Metadata not corresponding to a DefId is untracked. #41417
Comments
Yes, I want to refactor how this stuff is handled. Ultimately, I think that metadata should just be a bunch of (key, value) pairs where the However, it occurs to me that once we get the red-green system, we could just have a single "metadata" node corresponding to the entire crate, and then let the red/green caching remember what the values of specific metadata queries were. |
After some discussion on IRC, @michaelwoerister and I were thinking that the best immediate way to make progress here is going to involve converting all To that end, here is a checklist of Remaining
Resolve and elsewhere in rustc?Rename these methods to
Transitioned
??
|
cc @cramertj @aochagavia -- you interested in tackling some of these? In some cases, queries actually exist already, and we just have to convert code to use them exclusively (e.g., |
Mentoring instructions: The current step in resolving this is to move methods from the The idea then for a PR is to:
|
I would love to get started on this. I will try to have an implementation for one of the items up in a couple days to align on direction. |
Yeah, I can take a look at some of these tonight or tomorrow. |
@cramertj I was planning on taking a look at the couple of the first ones today or tomorrow morning if you want to start a little further down the list. Wouldn't want us stepping on each other's toes 😄 |
@achernyak Sounds great! Thanks. |
@cramertj @achernyak great! =) |
One downside of this approach, that came up during discussion, is that this would mean that we would have to load and deserialize each value just to find out if it has changed or not. Currently we directly load fingerprints to do this check. |
Can't we save fingerprints in the parent crate metadata and copy the expected fingerprints into the child crate IC-info? |
Yes, we could presumably special-case this code somewhat, though I think that -- for this to really work well -- we would want to align the metadata and queries so that they have a 1:1 relationship (refactoring the |
query for describe_def Resolves `fn describe_def(&self, def: DefId) -> Option<Def>;` of rust-lang#41417. r? @nikomatsakis I would greatly appreciate a review. I hope I covered everything described in the pr.
query for describe_def Resolves `fn describe_def(&self, def: DefId) -> Option<Def>;` of rust-lang#41417. r? @nikomatsakis I would greatly appreciate a review. I hope I covered everything described in the pr.
query for describe_def Resolves `fn describe_def(&self, def: DefId) -> Option<Def>;` of rust-lang#41417. r? @nikomatsakis I would greatly appreciate a review. I hope I covered everything described in the pr.
Many of these methods don't take |
@cramertj good point. I'd prefer to change the macro, but I'm not sure how easy that would be to do. I guess you can leverage the |
@cramertj in the short term, I think most of these can be handled but using a tuple like Also |
query for def_span Resolves `fn def_span(&self, sess: &Session, def: DefId) -> Span;` of #41417. I had to change the query name to `def_sess_span` since `ty::TyCtxt` already has a method `def_span` implemented. This also will probably have merge conflicts with #41534 but I will resolves those once it's merged and wanted to start a code review on this one now. r? @eddyb
I am making this comment as a way to track the conversions that proved problematic. Used in resolve:
Unreachable tcx in calls. Call sights should be converted on-demand computations:
|
@cramertj will do! I'll do a sweep with what I can find, and you can compare. |
Updated -- I tagged with all the PRs. |
@nikomatsakis Great, thanks! It looks like almost all the rest are ones I put off because they don't have a single |
More Queries for Crate Metadata This covers a little bit of clean up and the following parts of rust-lang#41417: * `fn item_attrs(&self, def_id: DefId) -> Vec<ast::Attribute>;` * `fn fn_arg_names(&self, did: DefId) -> Vec<ast::Name>;` * `fn trait_of_item(&self, def_id: DefId) -> Option<DefId>;` * `fn impl_parent(&self, impl_def_id: DefId) -> Option<DefId>;` * ` fn is_foreign_item(&self, did: DefId) -> bool;` * `fn is_exported_symbol(&self, def_id: DefId) -> bool;` r? @nikomatsakis
More Queries for Crate Metadata This covers a little bit of clean up and the following parts of rust-lang#41417: * `fn item_attrs(&self, def_id: DefId) -> Vec<ast::Attribute>;` * `fn fn_arg_names(&self, did: DefId) -> Vec<ast::Name>;` * `fn trait_of_item(&self, def_id: DefId) -> Option<DefId>;` * `fn impl_parent(&self, impl_def_id: DefId) -> Option<DefId>;` * ` fn is_foreign_item(&self, did: DefId) -> bool;` * `fn is_exported_symbol(&self, def_id: DefId) -> bool;` r? @nikomatsakis
that's a closed PR? Is that what you meant to link to? |
@nikomatsakis, that PR was closed due to a Windows build issue in #41766 which was taking too long to resolved. I believe @cramertj closed both of these to not keep the PRs open for an extended period of time. |
Finally getting back to this-- I'm opening a PR with a few new ones. I also looked at |
@cramertj Anything that is wrapped in a Tracked (like lang_items) you don't need to worry about. Those things can only be accessed when specifying a |
@michaelwoerister Oh, good to know. We should check those ones off on the list, then. I'll put together a list of them when I get a chance later today. |
@cramertj Excellent, thank you! |
Out of the list above, I see these included as
|
Track more crate metadata Part of #41417 r? @nikomatsakis
|
Could the list in #41417 (comment) be updated? #41766 was closed, and some are done in later PRs. Specifically,
Also,
|
Mentoring update: Mentoring instructions can be found here
There are many things in crate metadata that are not covered by dependency tracking (basically everything below this line). Those are things that are unlikely to change in an upstream crate, which is why this has not caused problems yet, but we'll not want to rely on that.
The best way to solve this is probably to create separate "input" DepNodes for these.
cc @nikomatsakis
The text was updated successfully, but these errors were encountered: