I don't think getting this thing wrapped up will take too much more work.
http://gwt-code-reviews.appspot.com/47816/diff/1/5 File dev/core/src/com/google/gwt/dev/js/JsStackEmulator.java (right): http://gwt-code-reviews.appspot.com/47816/diff/1/5#newcode132 Line 132: // $stack[$stackDepth = stackIndex] = currentFunction The assignment into $stack is from an earlier version of the code. It should be unnecessary. http://gwt-code-reviews.appspot.com/47816/diff/1/5#newcode184 Line 184: * the stack depth. I think that popping in a finally block is necessary only when you have a return statement in there. Maybe the "exitingEarly" variable should be called "exitBlockExitsFunctionNormally". The amended pattern is that a pop is necessary anywhere normal flow control might exit the function. function foo() { try { if (maybe) { return; } } finally { // maybe function exits and pops here } otherCodePossiblyExecuted(); // definitely pop here } I agree that there is no real reason to have special handling for throw statements since the code has to handle native exceptions anyway. Both catch and finally blocks should reset their stack depth. http://gwt-code-reviews.appspot.com/47816/diff/1/5#newcode204 Line 204: * arbitrary point. "exception" -> "unconditional flow control change" "arbitrary" -> "within the associated try block" http://gwt-code-reviews.appspot.com/47816/diff/1/5#newcode360 Line 360: earlyExitNames.remove(exitBlock); It should; this has no cleanup effect as written http://gwt-code-reviews.appspot.com/47816/diff/1/5#newcode400 Line 400: // Don't need a pop after a throw or break statement This is an optimization and I am taking advantage of the looser JS syntax. This could be made better with a visitor that will find all reachable code and then treating the implicit "return undefined" at the end of the block as just another normal exit path. http://gwt-code-reviews.appspot.com/47816/diff/1/5#newcode620 Line 620: // Same location; ignore > To correct this, a simple way > would be to add paranoid extra line-number updaters for for loops and while > statements. Makes sense. http://gwt-code-reviews.appspot.com/47816 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
