Follow-up fixes to report_return_mismatched_types

[compiler-errors]

Some renames, simplifications, fixes, etc. Follow-ups to #123804. I don't think it totally disentangles this code, but it does remove some of the worst offenders on the "I am so confused" scale (e.g. get_node_fn_decl).

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
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

[fmease]

r? fmease

[bors]

☔ The latest upstream changes (presumably #122385) made this pull request unmergeable. Please resolve the merge conflicts.

[fmease]

Thanks for untangling this code 🙏 I have some notes but otherwise looks good

[fmease]

(get_fn_decl does more than get_node_fn_decl as the former only calls the latter if get_return_block returns Some but that seems more robust anyway)

[fmease]

r=me with my question addressed in one way or another, a rebase & maybe after squashing some of the commits, dunno, as you please

[compiler-errors]

I only saw one actionable request for a change, so I fixed that

@bors r=fmease

[bors]

📌 Commit a2a6fe7 has been approved by fmease

It is now in the queue for this repository.

[bors]

⌛ Testing commit a2a6fe7 with merge e875391...

[bors]

☀️ Test successful - checks-actions
Approved by: fmease
Pushing e875391 to master...

[rust-timer]

Finished benchmarking commit (e875391): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

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

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)	1.1%	[0.6%, 1.8%]	3
Regressions ❌ (secondary)	0.2%	[0.1%, 0.2%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.1%	[-1.1%, -1.1%]	2
All ❌✅ (primary)	1.1%	[0.6%, 1.8%]	3

Max RSS (memory usage)

Results (primary 5.2%, secondary 3.3%)

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

Cycles

Results (primary 2.4%, 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.4%	[1.4%, 3.6%]	3
Regressions ❌ (secondary)	3.2%	[3.1%, 3.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.4%	[1.4%, 3.6%]	3

Binary size

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

Bootstrap: 670.966s -> 669.761s (-0.18%)
Artifact size: 315.42 MiB -> 316.16 MiB (0.23%)

[rylev]

@compiler-errors @fmease seems like the regression in regex caused the typeck query to almost double in time. Perhaps this is worth investigating?

[Mark-Simulacrum]

It looks to me like there's a bunch of new queries, including metadata decoding running. I don't see at a quick skim where there was an intent to deserialize/load more state in order to perform the evaluation here though.

Given that it's limited to just one benchmark though it's not clear whether it's worth investigating. Not marking as triaged though, I think at least a brief look from author would be helpful.

[compiler-errors]

None of this should be being called on the good path? 🤔