Change:
Local::new(1) } <del> /// Generator have not been resumed yet </del> <ins> /// Generator has not been resumed yet. </ins> const UNRESUMED: usize = GeneratorSubsts::UNRESUMED; <del> /// Generator has returned / is completed </del> <ins> /// Generator has returned / is completed. </ins> const RETURNED: usize = GeneratorSubsts::RETURNED; <del> /// Generator has been poisoned </del> <ins> /// Generator has panicked and is poisoned. </ins> const POISONED: usize = GeneratorSubsts::POISONED; <ins> /// A `yield` point in the generator. </ins> struct SuspensionPoint<'tcx> { <ins> /// State discriminant used when suspending or resuming at this point. </ins> state: usize, <ins> /// The block to jump to after resumption. </ins> resume: BasicBlock, <ins> /// Where to move the resume argument after resumption. </ins> resume_arg: Place<'tcx>, <ins> /// Which block to jump to if the generator is dropped in this state. </ins> drop: Option<BasicBlock>, <ins> /// Set of locals that have live storage while at this suspension point. </ins> storage_liveness: liveness::LiveVarSet, }

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