compute all rpitit of a trait #143783

bvanjoi · 2025-07-11T12:13:38Z

bvanjoi · 2025-07-11T12:16:00Z

compiler/rustc_ty_utils/src/assoc.rs

@@ -274,6 +226,54 @@ fn associated_types_for_impl_traits_in_associated_fn(
    }
 }

+fn associated_types_for_impl_traits_in_trait<'tcx>(


Is it necessary to remove associated_types_for_impl_traits_in_associated_fn and replace it with this new method?

I think it would be nice to replace it with a normal function rather than having two queries.

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].

~~We can then just encode associated_types_for_impl_traits_in_trait on a per-trait basis.~~

edit: nvm

compiler-errors · 2025-07-11T16:54:44Z

Let's see perf for now

@bors2 try @rust-timer queue

rust-bors · 2025-07-11T16:54:48Z

⌛ Trying commit 58cefcb with merge 9304f8a…

To cancel the try build, run the command @bors2 try cancel.

compute all rpitit of a trait Fixes #143697 r? `@compiler-errors`

rust-bors · 2025-07-11T19:12:57Z

☀️ Try build successful (CI)
Build commit: 9304f8a (9304f8aa4e3ff369c43ae9f3605aea00a4914433, parent: 855e0fe46e68d94e9f6147531b75ac2d488c548e)

rust-timer · 2025-07-11T20:23:40Z

Finished benchmarking commit (9304f8a): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking 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 @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.3%	[-0.4%, -0.2%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.2%	[-0.4%, 0.1%]	3

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.1%	[1.6%, 4.5%]	5
Improvements ✅ (primary)	-3.3%	[-4.0%, -2.7%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.3%	[-4.0%, -2.7%]	2

Cycles

Results (primary 3.3%, secondary 0.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.3%	[3.3%, 3.3%]	1
Regressions ❌ (secondary)	4.3%	[3.6%, 4.9%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.4%	[-4.6%, -2.6%]	4
All ❌✅ (primary)	3.3%	[3.3%, 3.3%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 464.604s -> 463.952s (-0.14%)
Artifact size: 374.58 MiB -> 374.57 MiB (-0.00%)

compiler-errors · 2025-07-11T20:37:44Z

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 &mut DisambiguatorState when computing all the RPITITs in a trait, then we shouldn't have any conflicts here and that we don't need any additional computation here.

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 associated_types_for_impl_traits_in_associated_fn altogether in favor of a query that does the same at the trait OR impl level.

bvanjoi · 2025-07-12T09:11:51Z

why this has so much logic having to do with computing the disambiguator.

This change cause regression in suggestion quality because:

When using disambiguator indices starting solely with trait_id (instead of the combined (trait_id, associate_method_id)), we encounter:

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}`
}

rustbot · 2025-07-12T18:53:57Z

HIR ty lowering was modified

cc @fmease

bvanjoi · 2025-07-12T18:58:30Z

Update:

Converted associated_types_for_impl_traits_in_trait_or_impl to a query;
Changed associated_types_for_impl_traits_in_associated_fn to a regular function.

compiler-errors · 2025-07-12T19:34:20Z

I pushed some cleanups on top of your branch. Specifically,

No need to do any disambiguator special-behavior. All we need to do is share the disambiguator state between all RPITIT synthesis; then the disambiguator is responsible for dealing with conflicts.
No need to introduce a new AssocTyForImplTraitInTraitOrImpl type -- we can just use UnordSet and adjust the access in associated_item_def_ids to make it compatible with the unorderedness of the set.
Make associated_types_for_impl_traits_in_associated_fn into an inherent method on TyCtxt so it doesn't need to be imported everywhere.

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.

bvanjoi · 2025-07-12T19:43:49Z

compiler/rustc_ty_utils/src/assoc.rs

@@ -366,7 +318,7 @@ fn associated_type_for_impl_trait_in_impl(
        None,
        DefKind::AssocTy,
        Some(data),
-        &mut DisambiguatorState::with(impl_local_def_id, data, disambiguated_data.disambiguator),
+        disambiguator,


good catch, I hadn't considered that point before.

bvanjoi · 2025-07-12T20:01:00Z

These changes appear approvable 👍 .

Thanks for your help, I've gained new insights into the usage of these fields.

compiler-errors · 2025-07-12T21:47:39Z

@bors r+

bors · 2025-07-12T21:47:42Z

📌 Commit 736bfa1 has been approved by compiler-errors

It is now in the queue for this repository.

bors · 2025-07-12T22:09:00Z

⌛ Testing commit 736bfa1 with merge 288e94c...

bors · 2025-07-13T01:10:49Z

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 288e94c to master...

github-actions · 2025-07-13T01:14:20Z

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 differences

Show 43 test diffs

43 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 288e94c4ba406d612a556520442683d0f1ef5dbb --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

x86_64-apple-2: 3030.3s -> 4054.2s (33.8%)
x86_64-apple-1: 5811.1s -> 7663.0s (31.9%)
aarch64-apple: 3776.1s -> 4631.3s (22.6%)
pr-check-2: 2175.1s -> 2601.0s (19.6%)
pr-check-1: 1513.1s -> 1704.6s (12.7%)
i686-gnu-2: 5393.6s -> 6019.9s (11.6%)
i686-gnu-1: 7238.5s -> 8034.9s (11.0%)
x86_64-gnu-llvm-19-1: 3386.6s -> 3755.0s (10.9%)
dist-aarch64-msvc: 5227.8s -> 5791.5s (10.8%)
x86_64-rust-for-linux: 2540.8s -> 2798.3s (10.1%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-07-13T03:14:50Z

Finished benchmarking commit (288e94c): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.1%	[1.1%, 1.1%]	1
Improvements ✅ (primary)	-0.2%	[-0.3%, -0.2%]	9
Improvements ✅ (secondary)	-0.3%	[-0.3%, -0.3%]	4
All ❌✅ (primary)	-0.2%	[-0.3%, -0.2%]	9

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	7.8%	[7.8%, 7.8%]	1
Improvements ✅ (primary)	-1.4%	[-1.7%, -1.1%]	2
Improvements ✅ (secondary)	-2.9%	[-2.9%, -2.9%]	1
All ❌✅ (primary)	-1.4%	[-1.7%, -1.1%]	2

Cycles

Results (primary -2.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.6%	[-2.6%, -2.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.6%	[-2.6%, -2.6%]	1

Binary size

Results (primary 0.5%, secondary 0.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.0%, 1.1%]	121
Regressions ❌ (secondary)	0.8%	[0.0%, 1.5%]	49
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[0.0%, 1.1%]	121

Bootstrap: 464.174s -> 468.578s (0.95%)
Artifact size: 374.70 MiB -> 374.72 MiB (0.00%)

Kobzol · 2025-07-13T07:40:12Z

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?

rustbot assigned compiler-errors Jul 11, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 11, 2025

bvanjoi commented Jul 11, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Jul 11, 2025

Auto merge of #143783 - bvanjoi:issue-143697-2, r=<try>

9304f8a

compute all rpitit of a trait Fixes #143697 r? `@compiler-errors`

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 11, 2025

This comment has been minimized.

Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jul 11, 2025

bvanjoi added 2 commits July 13, 2025 02:52

compute all rpitit of a trait

dc6c330

query RPITIT in a trait or impl

47e15d9

bvanjoi force-pushed the issue-143697-2 branch from 58cefcb to 47e15d9 Compare July 12, 2025 18:53

Clean up implementation of RPITIT assoc item lowering

736bfa1

bvanjoi commented Jul 12, 2025

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 12, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 13, 2025

bors merged commit 288e94c into rust-lang:master Jul 13, 2025
12 checks passed

rustbot added this to the 1.90.0 milestone Jul 13, 2025

bors mentioned this pull request Jul 13, 2025

Retire hir::*ItemRef. #143357

Merged

compute all rpitit of a trait #143783

compute all rpitit of a trait #143783

Uh oh!

Conversation

bvanjoi commented Jul 11, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

compiler-errors Jul 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

compiler-errors commented Jul 11, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Jul 11, 2025

Uh oh!

rust-bors bot commented Jul 11, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Jul 11, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Uh oh!

compiler-errors commented Jul 11, 2025

Uh oh!

bvanjoi commented Jul 12, 2025

Uh oh!

rustbot commented Jul 12, 2025

Uh oh!

bvanjoi commented Jul 12, 2025

Uh oh!

compiler-errors commented Jul 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bvanjoi commented Jul 12, 2025

Uh oh!

compiler-errors commented Jul 12, 2025

Uh oh!

bors commented Jul 12, 2025

Uh oh!

bors commented Jul 12, 2025

Uh oh!

bors commented Jul 13, 2025

Uh oh!

Uh oh!

github-actions bot commented Jul 13, 2025

Test differences

Job duration changes

Uh oh!

rust-timer commented Jul 13, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Uh oh!

Kobzol commented Jul 13, 2025

Uh oh!

Uh oh!

bvanjoi commented Jul 11, 2025 •

edited by rustbot

Loading

compiler-errors Jul 11, 2025 •

edited

Loading

compiler-errors commented Jul 12, 2025 •

edited

Loading