Add a query for resolving an impl item from the trait item#90639
Add a query for resolving an impl item from the trait item#90639bors merged 6 commits intorust-lang:masterfrom
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 |
cjgillot
left a comment
There was a problem hiding this comment.
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.
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.
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: