tail calls: fix copying non-scalar arguments to callee

[RalfJung]

Alternative to #144933: when invoking a tail call with a non-scalar argument, we need to delay freeing the caller's local variables until after the callee is initialized, so that we can copy things from the caller to the callee.

Fixes #144820... but as the FIXMEs in the code show, it's not clear to me whether these are the right semantics.
r? @WaffleLapkin

[rustbot]

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[bors]

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

[folkertdev]

I looked into this some at #144855 (comment). In summary, I believe that a tail call that uses an argument that is PassMode::Indirect { on_stack: false } fundamentally cannot work. That value lives on the caller's stack, and the callee has no space where that argument can be stored. The argument stack value becomes dead upon the call.

Supporting PassMode::Indirect { on_stack: true } should be possible once LLVM supports it on more targets. As of LLVM 21 at least aarch64 and s390x support that, riscv and x86 don't yet.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[RalfJung]

Thanks, I had not seen that issue! What a mess. Whatever rules we come up with should be portable to all targets...

Anyway, that's mostly orthogonal to what we do in the interpreter. Fixing the order in which we copy arguments and deallocate the old locals still makes sense IMO.

[RalfJung]

@WaffleLapkin just a friendly ping -- are you okay with reviewing this or should I find another reviewer?