Pass the whole GenericArgs to Interner::for_each_relevant_impl()

[ChayimFriedman2]

Pass the whole GenericArgs to Interner::for_each_relevant_impl()

And not just the self type.

rustc does not make use of this, but rust-analyzer needs it to support impls in the same block as args, see https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/non.20local.20impls.20for.20generic.20args/with/593629693.

I'm not entirely sure this covers all cases (e.g. an unnormalized alias), and want feedback from a types team member.

r? types

[fmease]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: f3ca1e1 (f3ca1e1620d490fd13130ed418f39f03c99ffd2d, parent: 3e353d7353b0cd6fa4eefd5c882457cc2708184c)

[rust-timer]

Finished benchmarking commit (f3ca1e1): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@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
Regressions ❌ (secondary)	0.0%	[0.0%, 0.1%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	2
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary 3.9%)

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.9%	[3.9%, 3.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary 0.0%)

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)	4.1%	[4.1%, 4.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.0%, secondary 0.1%)

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

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	3
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	3

Bootstrap: 497.449s -> 499.373s (0.39%)
Artifact size: 397.06 MiB -> 395.13 MiB (-0.49%)

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[oli-obk]

How does this help rust-analyzer in finding impls inside fn bodies?

[ChayimFriedman2]

Basically, instead of considering the block of the trait and Self only, it considers the block for any generic arg in the impl search.

[fmease]

At the risk of stating the obvious, in rustc, IINM for_each_relevant_impl is only used as a performance optimization to avoid running type relating / unification against all impls ever. It returns an overapproximation of relevant impls to be properly filtered later on.

I assume that you also only use for_each_relevant_impl as a jumping-off point in r-a and noticed that your type-relating is slowing you down tremendously when passing all impls, even ones nested inside bodies, to for_each_relevant_impl and so you want trim down the initial results?

[ChayimFriedman2]

rust-analyzer has different treatment for impls in bodies, for both performance and incrementality reasons we can't access all impls literally. We special case const _ impls, and need for_each_relevant_impl() to determine impls from which bodies to add. This was this way even before we used the next solver, FWIW, and is why rustc started warning on non local impls.

[lcnr]

pass in the TraitRef instead

View changes since the review

[ChayimFriedman2]

The reason I didn't is that for some predicates (normalization) retrieving the trait predicate requires knowing what args belong to the parent trait which require calling the interner, which might have a performance effect.

[lcnr]

nit, with that one, lgtm

View changes since this review

[lcnr]

I'm not entirely sure this covers all cases (e.g. an unnormalized alias), and want feedback from a types team member.

currently switching the new solver back to eager norm, at which point all args of the trait_ref will be fully normalized