Next steps for FnDef binder changes (instantiate most FnDef binders)

[addiesh]

View all comments

This change is a part of the ongoing effort to clean up binder/turbofishing behavior in the compiler (#156581).

This PR instantiates binders that were previously created via ty::Binder::dummy() with meaningfully bound vars.

r? oli-obk

Call me Turbofishmael.
Some years ago- never mind how long precisely-
having little or no money in my purse,
and nothing particular to interest me in C++,
I thought I would sail about a little and see the rusty part of the world.

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @oli-obk (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[addiesh]

ohhh no
(context to anyone who got pinged by rustbot: i messed up a rebase. you should be able to ignore this 😅️)

[GuillaumeGomez]

git reflog will be your friend here. 😉

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

@bors r+

[rust-bors]

📌 Commit dd17e77 has been approved by oli-obk

It is now in the queue for this repository.

[JonathanBrouwer]

@bors rollup=iffy
Including this in a special perf-sensitive rollup

[JonathanBrouwer]

Verifying that actual perf results after merge match expected results
@rust-timer build ec3341f

[rust-timer]

Finished benchmarking commit (ec3341f): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@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.3%	[0.2%, 0.4%]	18
Regressions ❌ (secondary)	0.4%	[0.2%, 0.6%]	6
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[-0.2%, 0.4%]	19

Max RSS (memory usage)

Results (primary 0.3%, secondary -1.5%)

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

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.4%, 0.7%]	3
Regressions ❌ (secondary)	0.7%	[0.5%, 0.9%]	2
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-5.9%	[-5.9%, -5.9%]	1
All ❌✅ (primary)	0.3%	[-0.4%, 0.7%]	4

Cycles

Results (primary -0.4%, 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.7%	[0.5%, 0.9%]	2
Regressions ❌ (secondary)	0.9%	[0.5%, 2.2%]	7
Improvements ✅ (primary)	-0.6%	[-1.4%, -0.4%]	7
Improvements ✅ (secondary)	-1.3%	[-2.6%, -0.4%]	5
All ❌✅ (primary)	-0.4%	[-1.4%, 0.9%]	9

Binary size

Results (primary 0.1%, 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.2%	[0.0%, 0.5%]	80
Regressions ❌ (secondary)	0.3%	[0.0%, 0.9%]	49
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.0%]	38
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	51
All ❌✅ (primary)	0.1%	[-0.1%, 0.5%]	118

Bootstrap: 489.577s -> 489.508s (-0.01%)
Artifact size: 390.24 MiB -> 390.20 MiB (-0.01%)

[JonathanBrouwer]

@addiesh@oli-obk
I don't think the perf regression was explicitly acknowledged anywhere.
Is it clear what is causing this regression? Is there anything we can do about it or should we just accept this?

[addiesh]

I'd lean towards calling it noise or just justified, as nothing immediately stands out to me as "this is causing the regressions." My best bet would be the closure I defined as a helper getting inlined, but I'm not sure. I'd want to hear oli's take on the matter since he has more experience than I do.