Clean up Scope::CollectUsedVariables.

Clean up Scope::CollectUsedVariables.

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

[Steven, 2011-11-03 12:39:39]

PTAL.

http://codereview.chromium.org/8438071/diff/1/src/liveedit.cc
File src/liveedit.cc (right):

http://codereview.chromium.org/8438071/diff/1/src/liveedit.cc#newcode863
src/liveedit.cc:863: for (int k = 1; k < context_list.length(); k++) {
Why does the iteration start at 1 here? Is this maybe a bug?

[Kevin Millikin (Chromium), 2011-11-03 13:12:20]

LGTM.

http://codereview.chromium.org/8438071/diff/1/src/liveedit.cc
File src/liveedit.cc (right):

http://codereview.chromium.org/8438071/diff/1/src/liveedit.cc#newcode863
src/liveedit.cc:863: for (int k = 1; k < context_list.length(); k++) {
On 2011/11/03 12:39:39, Steven wrote:
> Why does the iteration start at 1 here? Is this maybe a bug?

It does look like a bug.  I'm not even sure whether it's a one or an L.  In any
case, it's more obviously correct to have:

context_list.Sort(&CompareLocal)

and expose CompareLocal from scopes.cc (I'd put CompareLocal in in
variables.{h,cc} if it were me, and I'd rename it to CompareIndex or something).

http://codereview.chromium.org/8438071/diff/1/src/scopeinfo.cc
File src/scopeinfo.cc (right):

http://codereview.chromium.org/8438071/diff/1/src/scopeinfo.cc#newcode58
src/scopeinfo.cc:58: ASSERT(context_locals.length() == context_local_count);
Are these asserts true for the case where some variables are unused?  It seems
like nothing really depends on these invariants, if we just use
stack_locals.length() instead of stack_local_count everywhere below.

[Steven, 2011-11-03 14:55:59]

http://codereview.chromium.org/8438071/diff/1/src/liveedit.cc
File src/liveedit.cc (right):

http://codereview.chromium.org/8438071/diff/1/src/liveedit.cc#newcode863
src/liveedit.cc:863: for (int k = 1; k < context_list.length(); k++) {
On 2011/11/03 13:12:20, Kevin Millikin wrote:
> On 2011/11/03 12:39:39, Steven wrote:
> > Why does the iteration start at 1 here? Is this maybe a bug?
> 
> It does look like a bug.  I'm not even sure whether it's a one or an L.  In
any
> case, it's more obviously correct to have:
> 
> context_list.Sort(&CompareLocal)
> 
> and expose CompareLocal from scopes.cc (I'd put CompareLocal in in
> variables.{h,cc} if it were me, and I'd rename it to CompareIndex or
something).

Done.

http://codereview.chromium.org/8438071/diff/1/src/liveedit.cc#newcode870
src/liveedit.cc:870: context_list[k] = context_list[l];
Honestly this whole code looks like a giant bug to me. This is sort of supposed
to be some kind of selection sort, but here one entry is copied over another one
instead of being swapped or so.

http://codereview.chromium.org/8438071/diff/1/src/scopeinfo.cc
File src/scopeinfo.cc (right):

http://codereview.chromium.org/8438071/diff/1/src/scopeinfo.cc#newcode58
src/scopeinfo.cc:58: ASSERT(context_locals.length() == context_local_count);
Yep. Those counts actually reflect how many times  AllocateHeapSlot /
AllocateStackSlot are called. Unused variables are not allocated so the asserts
should always hold. Will still use stack_locals.length() though.
On 2011/11/03 13:12:20, Kevin Millikin wrote:
> Are these asserts true for the case where some variables are unused?  It seems
> like nothing really depends on these invariants, if we just use
> stack_locals.length() instead of stack_local_count everywhere below.