-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Add a query for resolving an impl item from the trait item #90639
Conversation
r? @oli-obk (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
a7a8b8e
to
9612151
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 96121514f93fd7bcf6507d9f04503656387680bf with merge 43062b0944a88c99e00100158c147d67e34081c0... |
☀️ Try build successful - checks-actions |
Queued 43062b0944a88c99e00100158c147d67e34081c0 with parent 0d1754e, future comparison URL. |
Finished benchmarking commit (43062b0944a88c99e00100158c147d67e34081c0): comparison url. Summary: This change led to large relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
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 seems like there is an unfortunate recomputation of typeck
. Do you have an idea where it comes from?
The three first commits look good. Can they be merged independently?
I have the impression this PR introduces queries for two separate things:
- first a query to translate impl item <-> trait item;
- second a query for associated_item_lookup.
Should their effect be assessed independently?
The recomputation probably comes from the |
…jgillot Assoc item cleanup This removes some fields from ObligationCauseCode Split out of rust-lang#90639
Just in case: |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 9d625bc with merge b4a612688e5135afb476f64bbe2508f028fe9268... |
☀️ Try build successful - checks-actions |
Queued b4a612688e5135afb476f64bbe2508f028fe9268 with parent e012a19, future comparison URL. |
Finished benchmarking commit (b4a612688e5135afb476f64bbe2508f028fe9268): comparison url. Summary: This change led to small relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. @bors rollup=never |
Perf looks good. |
@bors r+ |
📌 Commit 9d625bc has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (488acf8): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Hmm, not sure why the summary included the doc improvements before but not now. The doc improvements are still there though. |
let is_implemented = ancestors | ||
.leaf_def(tcx, trait_item.ident, trait_item.kind) | ||
.map(|node_item| !node_item.defining_node.is_from_trait()) | ||
.unwrap_or(false); | ||
.leaf_def(tcx, trait_item_id) | ||
.map_or(false, |node_item| node_item.item.defaultness.has_value()); |
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.
I think this changed values of is_implemented
. Previously it was true
only if it's implemented in this implementation (and was false
when there were a default impl in the trait). Is this intended? (this broke #92164 and not I'm figuring out how to fix it)
(the first screenshot from e012a19 commit, just before these changes, the second is after these changes; I've added a debug!
in this loop)
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.
And if this was intended, how can I specifically check that this item is implemented manually in a given impl (ie it doesn't use default implementation from the trait)?
…atthewjasper Link impl items to corresponding trait items in late resolver. Hygienically linking trait impl items to declarations in the trait can be done directly by the late resolver. In fact, it is already done to diagnose unknown items. This PR uses this resolution work and stores the `DefId` of the trait item in the HIR. This avoids having to do this resolution manually later. r? `@matthewjasper` Related to rust-lang#90639. The added `trait_item_id` field can be moved to `ImplItemRef` to be used directly by your PR.
This makes finding the item in an impl that implements a given trait item a query. This is for a few reasons: