Codify the assumption that %GetArrayKeys can return only a single interval starting at zero

Codify the assumption that %GetArrayKeys can return only a single interval starting at zero

This patch adds comments explaining the interface in runtime.cc and simplifies
all callers given these assumptions (e.g., no need to loop over intervals, or
calculate where the interval starts).

Took care of some unrelated issues in the edited code:
- Fixes one use of [] to InternalArray
- Removed a bunch of comments referring to ES3 which no longer hold in ES5

Committed: https://code.google.com/p/v8/source/detail?r=14125

[adamk, 2013-03-25 21:51:52]

This is step 2 of N. I hoped to be able to clean this up more in step 2, but the
use of %GetArrayKeys in ArraySort are problematic. I really wish
CopyFromPrototypes() and ShadowPrototypeElements() just weren't necessary...

[rossberg, 2013-03-28 12:27:07]

LGTM with comments

https://codereview.chromium.org/13071006/diff/1/src/array.js
File src/array.js (right):

https://codereview.chromium.org/13071006/diff/1/src/array.js#newcode44
src/array.js:44: if (length == 2 && intervals[0] == -1) {
Nit: using === might be more accurate (and marginally more efficient). Same in
other places below.

https://codereview.chromium.org/13071006/diff/1/src/array.js#newcode44
src/array.js:44: if (length == 2 && intervals[0] == -1) {
Do you actually need to test that length is 2? An index of -1 seems unambiguous
under the new invariant.

https://codereview.chromium.org/13071006/diff/1/src/array.js#newcode1254
src/array.js:1254: // A single interval.
Nit: adjust comment ("An interval")

https://codereview.chromium.org/13071006/diff/1/src/array.js#newcode1312
src/array.js:1312: // A single interval.
Same here

[adamk, 2013-03-28 16:39:04]

Switched to returning a number instead of a single interval for the interval
case. Also renamed "intervals" to "indices" everywhere. Let me know what you
think.

[adamk, 2013-04-01 20:17:24]

Does this still look good, with the varying return type?

[rossberg, 2013-04-03 08:37:59]

On 2013/04/01 20:17:24, adamk wrote:
> Does this still look good, with the varying return type?

[Sorry for the dealy, was on vacation.]

Yes, LGTM

Btw, please try to upload patches _before_ rebasing. ;)

[adamk, 2013-04-03 15:38:18]

On 2013/04/03 08:37:59, rossberg wrote:
> On 2013/04/01 20:17:24, adamk wrote:
> > Does this still look good, with the varying return type?
> 
> [Sorry for the dealy, was on vacation.]
> 
> Yes, LGTM
> 
> Btw, please try to upload patches _before_ rebasing. ;)

I try, I try, but this time I was uploading from a different repo than the one
where I'd created my patch, so I didn't know which revision to patch
against...Sorry for the confusion.

[adamk, 2013-04-03 15:52:48]

Committed patchset #2 manually as r14125 (presubmit successful).