Fix debug information for function arguments of type &str or slice.

[nanguye2496]

Issue details:
When lowering MIR to LLVM IR, the compiler decomposes every &str and slice argument into a data pointer and a usize. Then, the original argument is reconstructed from the pointer and the usize arguments in the body of the function that owns it. Since the original argument is declared in the body of a function, it should be marked as a LocalVariable instead of an ArgumentVairable. This confusion causes MSVC debuggers unable to visualize &str and slice arguments correctly. (See #81894 for more details).

Fix details:
Making sure that the debug variable for every &str and slice argument is marked as LocalVariable instead of ArgumentVariable in computing_per_local_var_debug_info. This change has been verified on VS Code debugger, VS debugger, WinDbg and LLDB.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @varkor (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[bjorn3]

When using DWARF debuginfo, using DW_TAG_formal_parameter instead of DW_TAG_variable makes much more sense. Otherwise debuggers won't show the arguments as arguments. For example for

fn foo(a: &str) {}
fn main() {
    foo("a");
}

Lldb will currently show:

$ lldb ./rust_out
(lldb) target create "./rust_out"
Current executable set to './rust_out' (x86_64).
(lldb) rbreak rust_out
Breakpoint 1: 2 locations.
(lldb) run
Process 4075 launched: './rust_out' (x86_64)
Process 4075 stopped
* thread #1, name = 'rust_out', stop reason = breakpoint 1.1
    frame #0: 0x000055555555932b rust_out`rust_out::main::h405f65324f7b53be at <anon>:1
(lldb) cont
Process 4075 resuming
Process 4075 stopped
* thread #1, name = 'rust_out', stop reason = breakpoint 1.2
    frame #0: 0x000055555555931a rust_out`rust_out::foo::ha632284b5a2f1ab8(a=(data_ptr = "a", length = 1)) at <anon>:1
(lldb)

This PR would remove the a=(data_ptr = "a", length = 1) part.

[nanguye2496]

@bjorn3: Thank you for your feedback. My fix aims to target CodeView symbols only. I wonder what would be the ideal way to fix this issue for both CodeView and DWARF symbols?

[bjorn3]

Maybe you could add a check that the target is windows. (msvc only. I think mingw uses dwarf, but I am not sure)

[nanguye2496]

Maybe you could add a check that the target is windows. (msvc only. I think mingw uses dwarf, but I am not sure)

@bjorn3: I believe the is_like_msvc check should be sufficient? mingw would meet the is_like_windows check but not is_like_msvc?

[bjorn3]

I think so.

[nanguye2496]

I think so.

Alright, I just updated my code accordingly.

[varkor]

@bjorn3 seems to already have taken a look, so it seems convenient to reassign. (Feel free to assign me again if not.)

r? @bjorn3

[bjorn3]

I have absolutely zero knowledge about the format of pdb debuginfo, so I have no idea if this is correct for msvc targets.

r? @varkor

[nanguye2496]

@varkor : Hi, I wonder if there is any further work that should be done for this PR?

[sivadeilra]

I have absolutely zero knowledge about the format of pdb debuginfo, so I have no idea if this is correct for msvc targets.

Hi, @varkor . I'm @nanguye2496 's manager. We are members of the Windows Engineering System, at Microsoft. We have worked with our peers in the Windows Debugger team, and confirmed that this change is correct. Before this commit, the PDB / CodeView records are malformed. This commit fixes that, and allows the debug-spill variable that is created for &str and &[T] arguments to be interpreted correctly by WinDbg and Visual Studio.

We believe there is more work to do in this area, but that this change is a good first step toward improving the experience of debugging Rust code on Windows.

[varkor]

Sorry for the delay; I've been busy with non-Rust priorities for the last few days. The change looks fine to me, thanks!

@bors r+

[bors]

📌 Commit 615fd14 has been approved by varkor

[sivadeilra]

No worries. Thanks!