compute all rpitit of a trait#143783
Conversation
compiler/rustc_ty_utils/src/assoc.rs
Outdated
| } | ||
| } | ||
|
|
||
| fn associated_types_for_impl_traits_in_trait<'tcx>( |
There was a problem hiding this comment.
Is it necessary to remove associated_types_for_impl_traits_in_associated_fn and replace it with this new method?
There was a problem hiding this comment.
I think it would be nice to replace it with a normal function rather than having two queries.
There was a problem hiding this comment.
It can just be an inherent method on TyCtxt<'tcx> and return tcx.associated_types_for_impl_traits_in_trait(tcx.parent(def_id))[&def_id].
There was a problem hiding this comment.
We can then just encode associated_types_for_impl_traits_in_trait on a per-trait basis.
edit: nvm
|
Let's see perf for now @bors2 try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
compute all rpitit of a trait Fixes #143697 r? `@compiler-errors`
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (9304f8a): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -3.3%, secondary 3.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 3.3%, secondary 0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 464.604s -> 463.952s (-0.14%) |
|
I'm still confused why this has so much logic having to do with computing the disambiguator. My understanding is that if we share the same As for the query structure, I think we should probably do the same for computing the associated items for an impl (i.e. do it all at once). We could then perhaps get rid of |
This change cause regression in suggestion quality because: When using disambiguator indices starting solely with trait A {
fn foo() -> impl Bound;
}
impl A for () {
fn foo() -> something_not_impl_Bound {}
- // previous note: required by a bound in `Foo::bar::{anon_assoc#0}`
+ // now: required by a bound in `Foo::{anon_assoc#0}`
} |
|
HIR ty lowering was modified cc @fmease |
|
Update:
|
|
I pushed some cleanups on top of your branch. Specifically,
Do you want to look at these changes and give it a 👍 if you're happy? Then I can approve it for both of us. |
| DefKind::AssocTy, | ||
| Some(data), | ||
| &mut DisambiguatorState::with(impl_local_def_id, data, disambiguated_data.disambiguator), | ||
| disambiguator, |
There was a problem hiding this comment.
good catch, I hadn't considered that point before.
|
These changes appear approvable 👍 . Thanks for your help, I've gained new insights into the usage of these fields. |
|
@bors r+ |
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing bfc046a (parent) -> 288e94c (this PR) Test differencesShow 43 test diffs43 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 288e94c4ba406d612a556520442683d0f1ef5dbb --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (288e94c): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.4%, secondary 2.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -2.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.5%, secondary 0.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 464.174s -> 468.578s (0.95%) |
|
The final result is a bit different than the pre-merge perf. run (some changes were made on top since then). There is a small bootstrap regression, and metadata size has gone up (https://perf.rust-lang.org/compare.html?start=bfc046a4b8d6b57db02540182466e989a9b0fb40&end=288e94c4ba406d612a556520442683d0f1ef5dbb&stat=size%3Acrate_metadata). @compiler-errors Is the metadata increase expected/ok? |
|
In any case, in terms of compile perf., improvements outweigh regressions. @rustbot label: +perf-regression-triaged |
Fixes #143697
r? @compiler-errors