Change:
self.borrowed_locals.borrow().analysis().statement_effect(sets, stmt, loc); // If a place is assigned to in a statement, it needs storage for that statement. <del> match stmt.kind { StatementKind::StorageDead(l) => sets.kill(l), StatementKind::Assign(box (ref place, _)) | StatementKind::SetDiscriminant { box ref place, .. } => { </del> <ins> match &stmt.kind { StatementKind::StorageDead(l) => sets.kill(*l), StatementKind::Assign(box (place, _)) | StatementKind::SetDiscriminant { box place, .. } => { </ins> sets.gen(place.local); } <del> StatementKind::InlineAsm(box InlineAsm { ref outputs, .. }) => { </del> <ins> StatementKind::InlineAsm(box InlineAsm { outputs, .. }) => { </ins> for place in &**outputs { sets.gen(place.local); } } <del> _ => (), </del> <ins> // Nothing to do for these. Match exhaustively so this fails to compile when new // variants are added. StatementKind::AscribeUserType(..) | StatementKind::FakeRead(..) | StatementKind::Nop | StatementKind::Retag(..) | StatementKind::StorageLive(..) => {} </ins> } }

Discussion:
I tried this code: I expected to see see the output "Person is Mood", instead, I got a segfault: : <details<summaryBacktrace</summary<p</p</details
Heh, looks like my "fix" for the miscompilation I found while implementing this wasn't actually sufficient. Reduced to: Looking at the MIR, you can see: The first leads to , which stores the resume argument from in the generator state as and advances to the next state (discriminant 3). On the next call it resumes at , which doesn't store the resume argument in the state (it only moves it to ). Here, the argument should have ended up in the generator state as some field. It then sets the discriminant to 4 to resume at . The next call thinks is still live and uses it to call the function. MIR of (minus storage statements):
Hmm, on second thought, it seems weird that is not put in the generator state at all, I would expect the existing transform infrastructure to handle this. cc
Looking at the MIR generated for reduced test case we can see that the writes that should have been to is instead done to the generator : So this seems to be a problem in MIR construction.
Hmm: I assume this isn't correct anymore? ( probably should have been replaced with the newly introduced field in ? )
Well that would explain why the MIR looks wrong.
I suspect this is because doesn't consider terminators as writes.
Thought I'd fix the printing real quick I'll look into the real bug tomorrow or some time next week, but the pass does indeed look wrong now.
I don't know much about rustc internals but it seems these places seem relevant somehow?
Yes, that's the issue I was referring to.
This patch makes the generator layout look more reasonable (actually containing slots for the s), but doesn't fix the crash. In fact, it makes the test miscompile too:
Well, afaict the main issue here is that the transformation which replaces the s with generator struct accesses is run before creating the actual resume function which emits the store of the resume argument to a local which should've been replaced. This happens: before this: I've tested the follwing patch (Hacky, we probably want to use the somehow): (Most of the diff is not relevant to the patch, contains the fix).

And it produces correct MIR code: EDIT: The original code contains a logic bug, every loop iteration a new empty is created , which is probably not intended, instead moving that binding to the outer scope should "fix" it. EDIT: And passes too. EDIT: Also I've just stupidly realized that the unwrap for should probably be avoided too since a local may not live across a suspension point.
I probably would have noticed that if not for that pesky segfault
That's a great start! I've opened a fix (+ cleanup + more docs) based on the same idea in