Arbitrary self types v2: probe for more methods, take two

[adetaylor]

This is a new version of #127812. Here's what I said last time, which still applies:

This PR is one of the first steps towards arbitrary self types v2, RFC 3519 (#44874). Specifically, it is step 2 of the plan outlined here. That says:

1. Search for potentially conflicting method candidates per the deshadowing part of the RFC. This is the riskiest part - per
   > the production of errors requires us to interrogate more candidates to look for potential conflicts, so this could have a compile-time performance penalty which we should measure
   let's attempt to land this first and see if performance issues show up. If so, it's back to the drawing board.

So - this commit isn't useful in itself but we need to determine its performance and any unexpected compatibility problems. That's what this PR is for. We shouldn't necessarily merge it.

Here's what this PR does.

Rust prioritizes method candidates in this order:

1. By value;
2. By reference;
3. By mutable reference;
4. By const ptr.

Previously, if a suitable candidate was found in one of these earlier categories, Rust wouldn't even move onto probing the other categories.

As part of the arbitrary self types work, we're going to need to change that - even if we choose a method from one of the earlier categories, we will sometimes need to probe later categories to search for methods that we may be shadowing.

This commit adds those extra searches for shadowing, but it does not yet produce an error when such shadowing problems are found. That will come in a subsequent commit, by filling out the 'check_for_shadowing' method.

We're adding the extra searches in a preliminary commit because they are the risky bit. We want to find any functional or performance problems from these extra searches before we proceed with the actual work on arbitrary self types and specifically on extra deshadowing errors.

--

What's different this time relative to #127812? Well, this is a more invasive change to the probing algorithm which hopefully minimizes the amount of work done during the extra probing for shadowed methods. Specifically, we only need to warn about potentially shadowed methods if three conditions are true:

• the shadowed method is not the same as the shadower (different DefIds)
• the potential shadower involves the same self type as the shadowed method
• the potential shadower has been found at a different position along the chain of Receiver traits than the shadowed.

Previously, we checked these conditions only when a potentially shadowed pick was found. We now apply them during the search process, which should minimize the amount of work required.

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[adetaylor]

The first commit in this PR has been raised separately as #128549 since it probably seems a good thing to land anyway, for a slight code simplification.

[adetaylor]

r? @wesleywiser

though it's still a draft PR and not quite ready for review yet. In any case the purpose is performance testing, I'm not saying this is mergable quality.

[adetaylor]

I don't know if I have permission to do this, let's see:

@rust-timer build 7f90c11

[adetaylor]

Well, my dear bot, that's what I thought you'd say :) In that case @wesleywiser I am marking this as "ready for review" but as noted, it's not really mergable-quality yet, it's more to do a performance test to determine if this approach to deshadowing is feasible without significant performance penalty (if so, I will clean things up before merging). So if you wouldn't mind redoing this that'd be much appreciated.

[lqd]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 7f90c11 with merge 317a31d...

[bors]

⌛ Trying commit 7f90c11 with merge aa049af...

[bors]

☀️ Try build successful - checks-actions
Build commit: aa049af (aa049af73ab994dcba850292ad20930a9596d802)

[rust-timer]

Finished benchmarking commit (aa049af): comparison URL.

Overall result: ❌ regressions - no action needed

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 may lead to changes in compiler perf.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

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

Max RSS (memory usage)

Results (primary 0.5%, secondary -3.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.2%	[0.7%, 3.7%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.8%	[-2.8%, -2.8%]	1
Improvements ✅ (secondary)	-3.2%	[-3.2%, -3.2%]	1
All ❌✅ (primary)	0.5%	[-2.8%, 3.7%]	3

Cycles

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

Binary size

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

Bootstrap: 760.03s -> 763.804s (0.50%)
Artifact size: 337.08 MiB -> 337.09 MiB (0.00%)

[adetaylor]

@wesleywiser Hello. Can you suggest someone who might be able to help me interpret these perf results and determine whether they're "OK enough"?

My interpretation is:

• The first version of this PR had 34 primary regressions and 11 secondary regressions and was generally Not OK.
• This version only regresses on six secondary tests, all of which are "many assoc items". The magnitude of the change seems to be similar to recent noise in the benchmark. So I'm hoping this is deemed OK? (I can't see any reason why this benchmark would specifically have tickled the de-shadowing algorithm, so I suspect this slowdown is likely caused by small impacts of passing extra parameters around to record the information required by the de-shadowing algorithm.)

If this looks OK to you, I'll regard step 2 of this plan as completed then move onto step 3. There's no need to merge this PR.

[wesleywiser]

I think the performance results are fine! As you say, there is only one benchmark deemed "significant", it's a secondary benchmark and recent runs on that benchmark have some amount of variance anyway.

[adetaylor]

Thanks - closing this PR then, and I'll move onto the next step!