Just a minor thing: consider if it’d make sense to move most of CodeGenerator.providesScopeCreator it’d into a method on the Block (all parts of the expression except for _es6 env check). Looking at CodeGenerator.providesScopeCreator it’s doing an awful lot of “block.” this and “block.” that.
Other than that, +1. Attila. > On Mar 21, 2016, at 10:23 AM, Hannes Wallnoefer > <hannes.wallnoe...@oracle.com> wrote: > > Please review JDK-8151810: for-in iteration does not provide per-iteration > scope. > > http://cr.openjdk.java.net/~hannesw/8151810/webrev/ > > This issue popped up while I was implementing ES6 for-of statement. It turns > out that like for-of, the ES5 for-in statement needs a per-iteration scope > when used with a lexical declaration which I oversaw in my initial > implementation of ES6 block scope. > > With normal for-statement this is pretty straightforward, because the spec > says that values from the previous iteration are reused in the next > iteration, which means that a const is actually a single const through all > iterations of the loop. This means that we can simply clone the existing > per-iteration scope at the end of the loop, which is what we do. > > However, with for-in/of per iteration scopes are independent of each other. > Therefore, something like "for (const a of [1, 2, 3]) {...}" actually gets a > new const for each iteration. Now we could fake it and use a cloned scope and > reset the const using some magic, but doing that caused all kinds of problems > (weird interaction with const declaration logic and temporal dead zone > detection, unstable scope maps etc). > > So the solution I came up with is that the block that provides the scope for > for-in statements (which is a synthetic block/block statement) registers its > scope creator in case it has one. The for-node can then reuse the scope > creator to create an object with the exact same property map and > uninitialized consts/lets. > > Hannes
