codegen: be more explicit about setting giving names to allocas.

[eddyb]

This is a follow-up to #64149 and a prerequisite for the codegen side of #56231.

Moving to set_var_name everywhere will allow better integration with MIR variable debuginfo, I suspect (we could block the PR on finding out, I don't care too much about landing this first).

In this PR I removed some miscellaneous hardcoded names (which is why I had to fix a test), but if we want to keep them I could use set_var_name (it could end up being confusing, though, if there's a Rust variable with the same name).

Something I noticed while doing this is that we give arguments:

• debuginfo (makes sense, allows for printing arguments in backtraces)
• arg0, arg1, etc. LLVM IR names (leftover from early MIR days?!)
  • I'm not sure we should keep this
  • we can make it use the _1, _2, etc. MIR local indices (EDIT: see codegen: use "_N" (like for other locals) instead of "argN", for argument names. #64435)
  • should we use _123 etc. as LLVM IR names for unnamed locals in general?

r? @rkruppe

[hanna-kruppe]

My gut feeling is that some of these hardcoded names are potentially helpful. But others seem like useless cruft and the benefit of the others is marginal, so I'm perfectly fine with losing them all for the sake of simplicity. FWIW if we ever reintroduce some names for non-source-level-things, the confusion with Rust variables could be avoided by a naming scheme that can't collide (e.g., prefixing with $).

Regarding naming other MIR locals, I don't care too much for arguments specifically but I could imagine it's occasionally useful to have LLVM IR names that indicate which MIR local (if any) an LLVM-level alloca or SSA value corresponds to. I don't think it's high priority though, and it should be done with care so that the artificial fallback name doesn't override the meaningful source-level name.

One thing I'm not entirely clear about is the future relation between set_var_name and debuginfo. I've been assuming set_var_name would grow into something that sets the value names and also emits debuginfo, and this change would be clearly helpful then. But there's a few places (such as those discussed above) where we might want to name an LLVM value without attaching debuginfo, since they have no real source level meaning. Is that going to be an issue?

In any case, this diff LGTM so @bors r+

[bors]

📌 Commit e9214a1 has been approved by rkruppe

[eddyb]

But there's a few places (such as those discussed above) where we might want to name an LLVM value without attaching debuginfo, since they have no real source level meaning. Is that going to be an issue?

No, so far I don't couple them that tightly in any of my WIP branches/plans.
Instead, I have a helper with handles debuginfo + (LLVM IR) name for a given MIR local, and everything else can just call set_var_name directly if needed (I guess that function could be renamed).

[eddyb]

@bors r- (included in #64435)