handle the special snowflakes that are Integer Indexed Exotic objects

handle the special snowflakes that are Integer Indexed Exotic objects

the implementation doesn't yet throw on strict mode assignment

BUG=

Committed: https://crrev.com/040225a31541c424dc092ba9feefb1c0eee21fc3
Cr-Commit-Position: refs/heads/master@{#27121}

[Toon Verwaest, 2015-03-10 12:01:24]

verwaest@chromium.org changed reviewers:
+ verwaest@chromium.org

[Toon Verwaest, 2015-03-10 12:01:25]

https://codereview.chromium.org/992913002/diff/60001/src/lookup.cc
File src/lookup.cc (right):

https://codereview.chromium.org/992913002/diff/60001/src/lookup.cc#newcode124
src/lookup.cc:124: DCHECK(state_ != LookupIterator::INTEGER_INDEXED_EXOTIC);
DCHECK_NE

https://codereview.chromium.org/992913002/diff/60001/src/lookup.cc#newcode337
src/lookup.cc:337: DCHECK(exotic_index_state_ != ExoticIndexState::kNoIndex);
DCHECK_NE

https://codereview.chromium.org/992913002/diff/60001/src/lookup.cc#newcode340
src/lookup.cc:340: DCHECK(exotic_index_state_ ==
ExoticIndexState::kUninitialized);
DCHECK_EQ

https://codereview.chromium.org/992913002/diff/60001/src/lookup.cc#newcode354
src/lookup.cc:354: AllowHeapAllocation allow;
Arg, reallowing allocation is crazy... that's going  to cause bugs.
Just write a local integer parser instead. The current impl even seems wrong.
E.g., "2e+60" is handled as IntegerIndexedExotic, while I presume it shouldn't
be.

[dcarney, 2015-03-10 13:09:46]

ptal

https://codereview.chromium.org/992913002/diff/60001/src/lookup.cc
File src/lookup.cc (right):

https://codereview.chromium.org/992913002/diff/60001/src/lookup.cc#newcode124
src/lookup.cc:124: DCHECK(state_ != LookupIterator::INTEGER_INDEXED_EXOTIC);
On 2015/03/10 12:01:25, Toon Verwaest wrote:
> DCHECK_NE

Done.

https://codereview.chromium.org/992913002/diff/60001/src/lookup.cc#newcode337
src/lookup.cc:337: DCHECK(exotic_index_state_ != ExoticIndexState::kNoIndex);
On 2015/03/10 12:01:25, Toon Verwaest wrote:
> DCHECK_NE

dcheck not okay with this

https://codereview.chromium.org/992913002/diff/60001/src/lookup.cc#newcode340
src/lookup.cc:340: DCHECK(exotic_index_state_ ==
ExoticIndexState::kUninitialized);
On 2015/03/10 12:01:25, Toon Verwaest wrote:
> DCHECK_EQ

same

https://codereview.chromium.org/992913002/diff/60001/src/lookup.cc#newcode354
src/lookup.cc:354: AllowHeapAllocation allow;
On 2015/03/10 12:01:25, Toon Verwaest wrote:
> Arg, reallowing allocation is crazy... that's going  to cause bugs.
> Just write a local integer parser instead. The current impl even seems wrong.
> E.g., "2e+60" is handled as IntegerIndexedExotic, while I presume it shouldn't
> be.

Done.

[Toon Verwaest, 2015-03-10 14:26:10]

lgtm with some nits

https://codereview.chromium.org/992913002/diff/120001/src/conversions.cc
File src/conversions.cc (right):

https://codereview.chromium.org/992913002/diff/120001/src/conversions.cc#newc...
src/conversions.cc:525: return offset == 2 && offset == to;  // Match just '-0'.
Quite some boilerplate pretending to be in a loop while you're not ... return to
== 2; without ++offset?

https://codereview.chromium.org/992913002/diff/120001/src/conversions.cc#newc...
src/conversions.cc:527: uint64_t acc = 0;
Wrap the entire "fast-path" into
if (!negative) {....}}
And use the case below
while (offset != length) {...}
for negative values. That's probably faster given that you don't need to keep
track of the value, you'll always return "true" for all-decimal-digit negative
values, just like for guaranteed-out-of-32bit-range positive values.

https://codereview.chromium.org/992913002/diff/120001/src/lookup.cc
File src/lookup.cc (right):

https://codereview.chromium.org/992913002/diff/120001/src/lookup.cc#newcode124
src/lookup.cc:124: DCHECK_NE(state_, LookupIterator::INTEGER_INDEXED_EXOTIC);
expected value on the left ... :)

[dcarney, 2015-03-10 15:13:33]

The CQ bit was checked by dcarney@chromium.org

[dcarney, 2015-03-10 15:13:34]

The patchset sent to the CQ was uploaded after l-g-t-m from
verwaest@chromium.org
Link to the patchset: https://codereview.chromium.org/992913002/#ps140001
(title: " ")

[commit-bot: I haz the power, 2015-03-10 15:14:45]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/992913002/140001

[dcarney, 2015-03-10 15:17:02]

The CQ bit was unchecked by dcarney@chromium.org

[dcarney, 2015-03-10 15:34:27]

The CQ bit was checked by dcarney@chromium.org

[dcarney, 2015-03-10 15:34:28]

The patchset sent to the CQ was uploaded after l-g-t-m from
verwaest@chromium.org
Link to the patchset: https://codereview.chromium.org/992913002/#ps160001
(title: " ")

[commit-bot: I haz the power, 2015-03-10 15:35:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/992913002/160001

[commit-bot: I haz the power, 2015-03-10 15:56:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-10 15:56:27]

Try jobs failed on following builders:
  v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/1118)

[dcarney, 2015-03-10 19:09:47]

The CQ bit was checked by dcarney@chromium.org

[commit-bot: I haz the power, 2015-03-10 19:09:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/992913002/160001

[commit-bot: I haz the power, 2015-03-10 19:11:17]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2015-03-10 19:11:32]

Patchset 9 (id:??) landed as
https://crrev.com/040225a31541c424dc092ba9feefb1c0eee21fc3
Cr-Commit-Position: refs/heads/master@{#27121}