bors 154ae32a55 Auto merge of #114643 - dpaoliello:inlinedebuginfo, r=wesleywiser
Use the same DISubprogram for each instance of the same inlined function within a caller

# Issue Details:
The call to `panic` within a function like `Option::unwrap` is translated to LLVM as a `tail call` (as it will never return), when multiple calls to the same function like this is inlined LLVM will notice the common `tail call` block (i.e., loading the same panic string + location info and then calling `panic`) and merge them together.

When merging these instructions together, LLVM will also attempt to merge the debug locations as well, but this fails (i.e., debug info is dropped) as Rust emits a new `DISubprogram` at each inline site thus LLVM doesn't recognize that these are actually the same function and so thinks that there isn't a common debug location.

As an example of this when building for x86_64 Windows (note the lack of `.cv_loc` before the call to `panic`, thus it will be attributed to the same line at the `addq` instruction):

```
	.cv_loc	0 1 23 0                        # src\lib.rs:23:0
	addq	$40, %rsp
	retq
	leaq	.Lalloc_f570dea0a53168780ce9a91e67646421(%rip), %rcx
	leaq	.Lalloc_629ace53b7e5b76aaa810d549cc84ea3(%rip), %r8
	movl	$43, %edx
	callq	_ZN4core9panicking5panic17h12e60b9063f6dee8E
	int3
```

# Fix Details:
Cache the `DISubprogram` emitted for each inlined function instance within a caller so that this can be reused if that instance is encountered again, this also requires caching the `DILexicalBlock` and `DIVariable` objects to avoid creating duplicates.

After this change the above assembly now looks like:

```
	.cv_loc	0 1 23 0                        # src\lib.rs:23:0
	addq	$40, %rsp
	retq
	.cv_inline_site_id 5 within 0 inlined_at 1 0 0
	.cv_inline_site_id 6 within 5 inlined_at 1 12 0
	.cv_loc	6 2 935 0                       # library\core\src\option.rs:935:0
	leaq	.Lalloc_5f55955de67e57c79064b537689facea(%rip), %rcx
	leaq	.Lalloc_e741d4de8cb5801e1fd7a6c6795c1559(%rip), %r8
	movl	$43, %edx
	callq	_ZN4core9panicking5panic17hde1558f32d5b1c04E
	int3
```
2023-08-22 20:15:29 +00:00
..
2023-03-20 10:25:29 +00:00
2023-07-27 14:44:13 -07:00
2023-01-17 16:23:22 +01:00
2023-07-29 18:34:41 -07:00
2023-08-15 11:33:45 +02:00
2023-07-29 18:34:41 -07:00
2023-07-27 14:44:13 -07:00
2023-08-07 14:11:03 +02:00
2023-01-11 20:42:13 -05:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-05-03 22:09:33 -07:00
2023-07-27 14:44:13 -07:00
2023-05-11 14:35:10 +00:00
2023-07-27 14:44:13 -07:00
2023-07-08 15:38:40 +02:00
2023-01-17 16:23:22 +01:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-05-08 03:55:41 -07:00
2023-04-17 09:16:07 +02:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-08-17 18:28:33 +00:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-08 15:38:40 +02:00
2023-07-27 14:44:13 -07:00
2023-01-17 16:23:22 +01:00

The files here use the LLVM FileCheck framework, documented at https://llvm.org/docs/CommandGuide/FileCheck.html.

One extension worth noting is the use of revisions as custom prefixes for FileCheck. If your codegen test has different behavior based on the chosen target or different compiler flags that you want to exercise, you can use a revisions annotation, like so:

// revisions: aaa bbb
// [bbb] compile-flags: --flags-for-bbb

After specifying those variations, you can write different expected, or explicitly unexpected output by using <prefix>-SAME: and <prefix>-NOT:, like so:

// CHECK: expected code
// aaa-SAME: emitted-only-for-aaa
// aaa-NOT:                        emitted-only-for-bbb
// bbb-NOT:  emitted-only-for-aaa
// bbb-SAME:                       emitted-only-for-bbb