Fix line numbers for MIR inlined code

[wesleywiser]

should_collapse_debuginfo detects if the specified span is part of a
macro expansion however it does this by checking if the span is anything
other than a normal (non-expanded) kind, then the span sequence is
walked backwards to the root span.

This doesn't work when the MIR inliner inlines code as it creates spans
with expansion information set to ExprKind::Inlined and results in the
line number being attributed to the inline callsite rather than the
normal line number of the inlined code.

Fixes #103068

[rust-highfive]

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

[wesleywiser]

Comparison of panics from the test case before & after this change:

Before

> .\mir-inlined-line-numbers.exe
thread 'main' panicked at 'explicit panic', .\src\test\codegen\mir-inlined-line-numbers.rs:8:5
stack backtrace:
   0: std::panicking::begin_panic<str>
             at /rustc/6b3ede3f7bc502eba7bbd202b4b9312d812adcd7\library\std\src\panicking.rs:607
   1: mir_inlined_line_numbers::bar
             at .\src\test\codegen\mir-inlined-line-numbers.rs:8
   2: mir_inlined_line_numbers::foo
             at .\src\test\codegen\mir-inlined-line-numbers.rs:12
   3: mir_inlined_line_numbers::main
             at .\src\test\codegen\mir-inlined-line-numbers.rs:12
   4: core::ops::function::FnOnce::call_once
             at /rustc/6b3ede3f7bc502eba7bbd202b4b9312d812adcd7\library\core\src\ops\function.rs:251
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

After

> .\mir-inlined-line-numbers.exe
thread 'main' panicked at 'explicit panic', .\src\test\codegen\mir-inlined-line-numbers.rs:8:5
stack backtrace:
   0: std::panicking::begin_panic<str>
             at .\library\std\src\panicking.rs:607
   1: mir_inlined_line_numbers::bar
             at .\src\test\codegen\mir-inlined-line-numbers.rs:8
   2: mir_inlined_line_numbers::foo
             at .\src\test\codegen\mir-inlined-line-numbers.rs:3
   3: mir_inlined_line_numbers::main
             at .\src\test\codegen\mir-inlined-line-numbers.rs:12
   4: core::ops::function::FnOnce::call_once
             at .\library\core\src\ops\function.rs:251
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[wesleywiser]

r? @davidtwco

As I think you might be familiar with this code 🙂

[davidtwco]

@bors r+

[bors]

📌 Commit 34d90a4 has been approved by davidtwco

It is now in the queue for this repository.

[pnkfelix]

discussed with Wesley. Unilaterally backport approving to go into 1.65 beta branch (which will be stable next week).

[wesleywiser]

@bors p=1

We're backporting this to ride the train alongside the MIR inliner being enabled by default.

[bors]

⌛ Testing commit 34d90a4 with merge 9db8c2939a620326d47daadbc8d36abd1cdebb1a...

[bors]

💔 Test failed - checks-actions

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[wesleywiser]

2022-10-28T12:51:18.7606620Z sort: write failed: 'standard output': Broken pipe
2022-10-28T12:51:18.7607419Z 257932	.
2022-10-28T12:51:18.7608062Z sort: write error

Seems spurious?

@bors retry

[bors]

⌛ Testing commit 34d90a4 with merge 77e7b74...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing 77e7b74 to master...

[rust-timer]

Finished benchmarking commit (77e7b74): comparison URL.

Overall result: ❌ regressions - 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.0%	[0.6%, 2.2%]	8
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[0.6%, 2.2%]	8

Max RSS (memory usage)

Results

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)	3.5%	[2.7%, 4.4%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.3%	[-2.3%, -2.3%]	1
All ❌✅ (primary)	3.5%	[2.7%, 4.4%]	2

Cycles

Results

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.5%	[2.5%, 2.5%]	1
Regressions ❌ (secondary)	2.2%	[2.2%, 2.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.5%	[2.5%, 2.5%]	1

[nnethercote]

These perf regressions look real.

[wesleywiser]

I'll spend some time investigating this week.

[wesleywiser]

The regressions are real but expected. Both regex and webrender enable debuginfo generation in release mode. Prior to this change, any inlined code was being incorrectly placed at the line number of the calling function which caused a reduction in the amount of debuginfo generated by LLVM (and given to LLVM by rustc). Fixing that bug causes the debuginfo to be generated with the appropriate line numbers and results in more debuginfo. cachegrind results back this up and show the biggest increases in debuginfo related LLVM functions.

Both of these benchmarks improved considerably when MIR inlining was enabled and even with the regression caused by this fix, we're still showing net wins on these benchmarks.

I couldn't find any other actionable items that might improve these results at this time.