This is one attempt to fix #741. The approach here is to wrap the iterable in a new root node; that is:

res {
  for (i in List(1, 2)) {
//          ^^^^^^^^^^  now a root node
    i
  }
}

We then store any existing for-generator vars as auxiliary slots inside this root node.

I'm not entirely happy with this approach; one quirk here is that we are creating a deeper stack frame, but cloning the parent stack frame. We need to do this so that we can resolve variables that might be on the outer frame.

Going deeper: the reason we need to copy outer frame slot values is because our lexical scope is all based off of VmObjectLike; we don't have a mechanism for resolving a variable on the outer frame if there is no VmObject to attach a frame to.

However, we don't have this pattern anywhere in the codebase. It's a one-off and feels quite hacky.

Also, creating a new root node adds more interpreter overhead. But the cost there seems palatable; it's unclear to me how much this actually hurts our real world performance.

I can think of two alternatives to this approach:

1. Deep-force the iterable prior to executing each loop. However:
   • This will introduce other regressions (deep-forcing might throw, but for-generators today may not necessarily execute those paths).
   • This is likely terrible for performance (think: iterating over a glob import)
2. Resolve variables at parse-time, within AstBuilder. I think we want to do this eventually, but it's a big effort.