-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Make traits_in_crate
and impls_in_crate
proper queries
#100601
Make traits_in_crate
and impls_in_crate
proper queries
#100601
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cjgillot (or someone else) soon. Please see the contribution instructions for more information. |
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.
Thanks @Robert-Cunningham
For the second and fourth ticks, I wasn't able to find many other analyses that iterate through the HIR looking for traits or impls. I'm looking for something like for item in tcx.hir().items(), but maybe the iterations referenced in the original PR have a different shape that I'm not used to? It seems like e.g. coherence makes ample use of impl_trait_ref() but never needs to iterate.
rustc_typeck::coherence::inherent_impls::crate_inherent_impls
uses such a loop. One in inherent_impls_overlap_check::crate_inherent_impls_overlap_check
too.
I wonder if we should get rid of all_local_trait_impls
replaced by impls_in_crate
, and change the return type of tcx.hir().trait_impls
to match that replacement.
Can we implement implementations_of_trait
as a query in terms of impls_in_crate
directly, and remove the special case in metadata decoding and in trait_impls_of
query?
@@ -1848,9 +1830,16 @@ impl<'a, 'tcx> EncodeContext<'a, 'tcx> { | |||
.map(|(trait_def_id, mut impls)| { | |||
// Bring everything into deterministic order for hashing | |||
impls.sort_by_cached_key(|&(index, _)| { |
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.
Can we get rid of this sort and the one above?
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.
impls_in_crate
returns a FxIndexMap<DefId, Vec<(DefId, Option<SimplifiedType>)>>
; The Vec
part should be in source code order, and the Map<TraitId, ...>
part is ordered by the source code order of the Impls. Since the source code is hashed into crate_hash, I believe you're right, we can remove both of these sorts.
In fact, if I understand correctly, we can also remove a third sort in encode_incoherent_impls
, since it ultimately relies on a similarly stable iteration through tcx.hir().items()
.
Thanks for your thoughts! My initial take on your second point are that we can definitely drop I'll continue to work through your other points over the next day or two. |
☔ The latest upstream changes (presumably #102040) made this pull request unmergeable. Please resolve the merge conflicts. |
ping from triage: Can you please address the merge conflicts - and post your status on this PR? FYI: when a PR is ready for review, send a message containing |
@Robert-Cunningham @rustbot label: +S-inactive |
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
Ok! I think the content here is ready for review, so I'll mark it @rustbot ready. One kink to work out: I'm failing this recently added and seemingly (?) unrelated assembly test. It was added in this PR. I'm not sure whether to treat this failure as spurious, and if possible I'd really appreciate input from @lukas-code or someone else who knows the terrain! |
Removing also @rustbot label -S-inactive |
Looks like that assembly test has the wrong |
…est, r=cuviper bump failing assembly & codegen tests from LLVM 14 to LLVM 15 These tests need LLVM 15. Found by `@Robert-Cunningham` in rust-lang#100601 (comment) Passed tests at 006506e93fc80318ebfd7939fe1fd4dc19ecd8cb in https://github.com/rust-lang/rust/actions/runs/3942442730/jobs/6746104740.
…est, r=cuviper bump failing assembly & codegen tests from LLVM 14 to LLVM 15 These tests need LLVM 15. Found by ``@Robert-Cunningham`` in rust-lang#100601 (comment) Passed tests at 006506e93fc80318ebfd7939fe1fd4dc19ecd8cb in https://github.com/rust-lang/rust/actions/runs/3942442730/jobs/6746104740.
…est, r=cuviper bump failing assembly & codegen tests from LLVM 14 to LLVM 15 These tests need LLVM 15. Found by ```@Robert-Cunningham``` in rust-lang#100601 (comment) Passed tests at 006506e93fc80318ebfd7939fe1fd4dc19ecd8cb in https://github.com/rust-lang/rust/actions/runs/3942442730/jobs/6746104740.
☔ The latest upstream changes (presumably #107765) made this pull request unmergeable. Please resolve the merge conflicts. |
visting this PR. Seems there some open comment(s), so tentatively flipping the review switch to @rustbot author |
for id in cx.tcx.impls_in_crate(LOCAL_CRATE) { | ||
let id = ItemId { owner_id: OwnerId { def_id: id.expect_local() } }; |
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.
This could use a helper method in rustc_middle::hir::map
.
Thanks @Robert-Cunningham. One nit (#100601 (comment)). Could you rebase and squash the commits? |
Yes, will do. Thanks! |
Hi @Robert-Cunningham, it's been a while - are you still planning to work on this PR? |
Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks |
This pull request addresses #95092.
impls_in_crate
returns aMap<DefId, Vec<DefId, SimplifiedTypeGen>>
mapping traits to impls and their simplified type. We ultimately keptall_local_trait_impls
around, but it now wrapsimpls_in_crate
and is only responsible for stripping the SimplifiedTypeGen and converting the DefId to a LocalDefId.encode_impls
to useimpls_in_crate
.For the second and fourth ticks, I wasn't able to find many other analyses that iterate through the HIR looking for traits or impls. I'm looking for something like
for item in tcx.hir().items()
, but maybe the iterations referenced in the original PR have a different shape that I'm not used to? It seems like e.g. coherence makes ample use ofimpl_trait_ref()
but never needs to iterate.Unfortunately, we could not remove
traits_in_crate
as suggested in the original issue's comments, since we need that information to generate docs.By default I'll r? @cjgillot , who has been helping me out with lots of questions during this PR :)