Skip to content

Allocate arguments from topmost frame into temporary storage before popping stack frame in init_fn_tail_call #144933

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Aug 5, 2025

When doing a tail call, we pop the topmost frame and then push a new frame to replace it. If we have an argument that is being passed indirectly from an mplace of a local from that old stack frame, then it will be invalidated before we can copy them into the locals of the new stack frame.

THis PR detects arguments that are being indirectly via pointers which point into the allocations of the topmost stack frame's locals. If we find an argument, we copy it into new temporary memory for constructing the new stack frame, and then we deallocate that old memory.

Not totally sure who should review this, since I'm not totally sure if I'm using CTFE correctly 😎 Specifically I don't know if I am implementing the right logic for "does this argument come from an allocation that corresponds to a local in the top stack frame".

r? @WaffleLapkin @RalfJung @oli-obk

Fix #144820

@rustbot
Copy link
Collaborator

rustbot commented Aug 5, 2025

wafflelapkin is currently at their maximum review capacity.
They may take a while to respond.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 5, 2025
@rustbot
Copy link
Collaborator

rustbot commented Aug 5, 2025

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

@WaffleLapkin WaffleLapkin added the F-explicit_tail_calls `#![feature(explicit_tail_calls)]` label Aug 5, 2025
Copy link
Member

@WaffleLapkin WaffleLapkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both Ralf and Oli are on vacations so I guess I'll have to review it for now ^^'

This looks reasonable to me, r=me with/out nits.

Comment on lines +210 to +216
match self.value {
LocalValue::Dead => false,
LocalValue::Live(val) => match val {
Operand::Immediate(_) => false,
Operand::Indirect(_) => true,
},
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
match self.value {
LocalValue::Dead => false,
LocalValue::Live(val) => match val {
Operand::Immediate(_) => false,
Operand::Indirect(_) => true,
},
}
match self.value {
LocalValue::Dead | LocalValue::Live(Operand::Immediate(_)) => false,
LocalValue::Live(Operand::Indirect(_)) => true,
}

Comment on lines +765 to +768
let local_allocs: FxHashSet<_> = frame_locals
.iter()
.filter_map(|local| local.as_mplace_or_imm()?.left()?.0.provenance?.get_alloc_id())
.collect();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you wrap this in std::cell::LazyCell, so that we don't create a hash map if none of the arguments have mplaces?

@RalfJung
Copy link
Member

RalfJung commented Aug 5, 2025

I won't have time to review this during my vacation, but as a quick first note -- I rather strongly object to anything that involves special casing move arguments based on whether they happen to be a local in the caller's stack frame. That kind of ad-hoc special case is surely not something we want in our MIR spec. (Currently the interpreter implements the de-facto spec for tail calls, so what you are suggesting here is a change in the MIR spec.) I suggest we figure out what the spec should be before adding hacks like this to every backend implementing tail calls (ISTM the same hacks would be required in the codegen backend, if it supported tail calls).

It would seem to me that passing a move argument to a tail call when the argument doesn't outlive the callee is simply UB. If you move an argument out of a Box and free the box during the call, surely that is UB. So I think the bug here is in MIR building, not in the interpreter. Fixing the MIR would also nicely fix this for all backends, instead of requiring complicated logic in each of them.

@RalfJung
Copy link
Member

RalfJung commented Aug 5, 2025

I'd appreciate if you could hold off on landing this until I'm back, since this is an unstable feature I hope it's not urgent.

@compiler-errors
Copy link
Member Author

I'll wait until Ralf is back.

I will note that I don't see what this has to do with move arguments. This has to do with arguments that are passed indirectly and how that interacts with the current spec for tail calls.

Right now we pop a stack frame and deinit the locals in that stack frame before initializing a new stack frame for the tail call. If an arg is being passed indirectly from an allocation corresponding to local that has been deinited, then I don't see any way to make that a defined operation.

@WaffleLapkin
Copy link
Member

This is a general tail call problem -- you need to move the indirect ABI arguments somewhere off of the current stack frame. I think this is (one of?) the reason(s?) why we have to have the same signature requirement -- that allows backends to move arguments to the caller (pseudocode):

fn src_tail(arg: /* implicitly passed by ref in the ABI */ String) {
    let local = arg.clone();
    drop(arg);
    become src_tail(local)
}

// ==>>

fn src_tail(arg: /* implicitly passed by ref in the ABI */ String) {
    let local = arg.clone();
    drop(arg);
    write_through_implicit_ref(arg, local);
    become src_tail(arg)
}

I'm not sure we we want to emulate this in miri, but we do have to do something. I agree that we should indeed wait for Ralf to return though ^^'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-explicit_tail_calls `#![feature(explicit_tail_calls)]` S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Miri reports UB for explicit tail call with by-value non-ZST struct parameter
5 participants