Fix the ScopeIterator reimplemantation.

The ScopeIterator uses recorded scope position - as detailed in scopes.h - and
source code positions it gets from the program counter to recreate the scope
chain by reparsing the function or program.

This CL includes the following changes
* Adds source code positions for the assignment added by the rewriter.
* Run the preparser over global code first.
* Use the ScopeType from the ScopeInfo to determine if the code being debugged
  is eval, function or global code instead of looking up the '.result' symbol.

TEST=mjsunit/debug-stepout-scope.js

Committed: http://code.google.com/p/v8/source/detail?r=10076

[Steven, 2011-11-17 14:55:45]

PTAL.

[Rico, 2011-11-17 17:29:58]

LGTM, but consider having lasse take a look as well

[Lasse Reichstein, 2011-11-18 14:12:52]

If our scopes differ depending on whether we preparse or not, they are broken.
Preparsing should be an optimization only. If we have preparser data, great, we
use it. If not, we may or may no create SOME of it ourselves. The
"PartialPreParser" could easily diverge more from the full one, and start
collecting other things that are useful when run immediately before the normal
parse.

You can't predict whether we had preparser data for the original parse. The
browser might have supplied it or not.

http://codereview.chromium.org/8590027/diff/1/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/8590027/diff/1/src/runtime.cc#newcode11247
src/runtime.cc:11247: pre_data = ParserApi::PartialPreParse(source, NULL,
flags);
Why preparse? Is it for speed?

Maybe only do it if the source is larger than 1K, as we do in the normal
parsing.

http://codereview.chromium.org/8590027/diff/1/test/mjsunit/debug-stepout-scop...
File test/mjsunit/debug-stepout-scope.js (right):

http://codereview.chromium.org/8590027/diff/1/test/mjsunit/debug-stepout-scop...
test/mjsunit/debug-stepout-scope.js:175: break invalid_break_label;
Don't add tests like this. 
It should be an early error, so eventually the preparser will detect it and the
test will fail.
If anything, it should be in the bugs/ directory.

[Steven, 2011-11-18 16:53:19]

http://codereview.chromium.org/8590027/diff/1/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/8590027/diff/1/src/runtime.cc#newcode11247
src/runtime.cc:11247: pre_data = ParserApi::PartialPreParse(source, NULL,
flags);
Initially this was only for mimicking the behaviour of the initial parse. But
indeed we don't have the information anymore if the browser provided preparse
data. I can leave it in for speed but also delete it.

I rewrote this part, so that it simply does not provide information about stack
allocated variables when reparsing fails and refrains from crashing in release
mode.

On 2011/11/18 14:12:52, Lasse Reichstein wrote:
> Why preparse? Is it for speed?
> 
> Maybe only do it if the source is larger than 1K, as we do in the normal
> parsing.

http://codereview.chromium.org/8590027/diff/1/test/mjsunit/debug-stepout-scop...
File test/mjsunit/debug-stepout-scope.js (right):

http://codereview.chromium.org/8590027/diff/1/test/mjsunit/debug-stepout-scop...
test/mjsunit/debug-stepout-scope.js:175: break invalid_break_label;
Moved it to the bugs/ directory.

On 2011/11/18 14:12:52, Lasse Reichstein wrote:
> Don't add tests like this. 
> It should be an early error, so eventually the preparser will detect it and
the
> test will fail.
> If anything, it should be in the bugs/ directory.

[Steven, 2011-11-24 13:49:03]

I merged the changes from http://codereview.chromium.org/8585001/ into this
issue.

Patch set 3 reapplies the ScopeIterator implementation and patch set 4 includes
the new changes.

PTAL.

[Lasse Reichstein, 2011-11-28 11:51:36]

LGTM.

http://codereview.chromium.org/8590027/diff/9002/src/compiler.cc
File src/compiler.cc (right):

http://codereview.chromium.org/8590027/diff/9002/src/compiler.cc#newcode495
src/compiler.cc:495: pre_data = ParserApi::PartialPreParse(source, extension,
flags);
You can just skip creating preparser data now.
The parser will handle lazy functions effectively in the absence of pre_data now
(using the preparser's function-body-parser instead of its own). It'll be faster
than preparsing the entire script first, so preparser data is only an advantage
if it's been created offline (so you can skip the function body entirely).