compute all rpitit of a trait

[bvanjoi]

Fixes #143697

r? @compiler-errors

[bvanjoi]

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

[compiler-errors]

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

[compiler-errors]

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

[compiler-errors]

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

edit: nvm

[compiler-errors]

Let's see perf for now

@bors2 try @rust-timer queue

[rust-bors]

⌛ Trying commit 58cefcb with merge 9304f8a…

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

[rust-bors]

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

[rust-timer]

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]

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]

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