Upgrade Number constructor to ES6.

Upgrade Number constructor to ES6.

Add missing constants, predicates and functions to the Number
constructor to have it offer what ES6 now specifies.

That is, extend it with:

 * isInteger(), isSafeInteger()
 * parseInt(), parseFloat()
 * EPSILON, MIN_SAFE_INTEGER, MAX_SAFE_INTEGER

LOG=N
R=
BUG=v8:3082
Committed: https://code.google.com/p/v8/source/detail?r=18480

[sof, 2014-01-04 16:46:53]

At your leisure, please take a look.

[Michael Starzinger, 2014-01-07 16:08:00]

Technically this is looking good. I just have a few comments. 

But unfortunately I am not sure whether we can expose that to the web without
putting it behind the Harmony flag. I am afraid of spontaneous web-breakage.
Andreas, opinions on that?

https://codereview.chromium.org/124573002/diff/1/src/v8natives.js
File src/v8natives.js (right):

https://codereview.chromium.org/124573002/diff/1/src/v8natives.js#newcode85
src/v8natives.js:85: %OptimizeObjectForAddingMultipleProperties(object,
constants.length);
I think constants.length should be divided by 2 (i.e. SHR by 1) because each
constant takes up two elements in the array.

https://codereview.chromium.org/124573002/diff/1/src/v8natives.js#newcode1659
src/v8natives.js:1659: return $Math.abs(integral) <= $Number.MAX_SAFE_INTEGER;
Better call "MathAbs" directly here, as "$Math.abs" might have been
monkey-patched in the meantime.

https://codereview.chromium.org/124573002/diff/1/src/v8natives.js#newcode1692
src/v8natives.js:1692: "MAX_SAFE_INTEGER", two_pow_53_1,
I think it is fine to inline "%_MathPow(2, 53) - 1" here as it's easier to read
and the SetUpNumber() method is only executed at snapshot creation time anyways.

https://codereview.chromium.org/124573002/diff/1/test/mjsunit/parse-int-float.js
File test/mjsunit/parse-int-float.js (right):

https://codereview.chromium.org/124573002/diff/1/test/mjsunit/parse-int-float...
test/mjsunit/parse-int-float.js:122: assertEquals(Number.parseFloat('0.1'),
parseFloat('0.1'));
The spec requires "Number.parseFloat" and "parseFloat" to be the same function
object. I think we get that right, but can we add a test in that regard?

// Test that some properties refer to the same function object.
assertSame(Number.parseInt, parseInt);
assertSame(Number.parseFloat, parseFloat);

[rossberg, 2014-01-07 17:20:34]

On 2014/01/07 16:08:00, Michael Starzinger wrote:
> Technically this is looking good. I just have a few comments. 
> 
> But unfortunately I am not sure whether we can expose that to the web without
> putting it behind the Harmony flag. I am afraid of spontaneous web-breakage.
> Andreas, opinions on that?

This seems very low risk, and I believe Mozilla implements it already. So I
think we can avoid the flag this time.

[Michael Starzinger, 2014-01-07 17:35:25]

On 2014/01/07 17:20:34, rossberg wrote:
> On 2014/01/07 16:08:00, Michael Starzinger wrote:
> > Technically this is looking good. I just have a few comments. 
> > 
> > But unfortunately I am not sure whether we can expose that to the web
without
> > putting it behind the Harmony flag. I am afraid of spontaneous web-breakage.
> > Andreas, opinions on that?
> 
> This seems very low risk, and I believe Mozilla implements it already. So I
> think we can avoid the flag this time.

After my offline discussion with Andreas he convinced me that these changes are
low risk and I am fine with landing this as it is (after comments are
addressed). Out of curiosity I just checked, Mozilla implements the following:
- Number.isInteger
- Number.parseInt
- Number.parseFloat
- Number.EPSILON

The following properties are not present though:
- Number.isSafeInteger
- Number.MIN_SAFE_INTEGER
- Number.MAX_SAFE_INTEGER

On a side note, the following does not hold with Firefox nightly.
Number.parseInt === parseInt

[sof, 2014-01-07 21:36:29]

https://codereview.chromium.org/124573002/diff/1/src/v8natives.js
File src/v8natives.js (right):

https://codereview.chromium.org/124573002/diff/1/src/v8natives.js#newcode85
src/v8natives.js:85: %OptimizeObjectForAddingMultipleProperties(object,
constants.length);
On 2014/01/07 16:08:00, Michael Starzinger wrote:
> I think constants.length should be divided by 2 (i.e. SHR by 1) because each
> constant takes up two elements in the array.

Oops, quite right. Done.

https://codereview.chromium.org/124573002/diff/1/src/v8natives.js#newcode1659
src/v8natives.js:1659: return $Math.abs(integral) <= $Number.MAX_SAFE_INTEGER;
On 2014/01/07 16:08:00, Michael Starzinger wrote:
> Better call "MathAbs" directly here, as "$Math.abs" might have been
> monkey-patched in the meantime.

Done.

https://codereview.chromium.org/124573002/diff/1/src/v8natives.js#newcode1692
src/v8natives.js:1692: "MAX_SAFE_INTEGER", two_pow_53_1,
On 2014/01/07 16:08:00, Michael Starzinger wrote:
> I think it is fine to inline "%_MathPow(2, 53) - 1" here as it's easier to
read
> and the SetUpNumber() method is only executed at snapshot creation time
anyways.

Done, fewer magic values.

https://codereview.chromium.org/124573002/diff/1/test/mjsunit/parse-int-float.js
File test/mjsunit/parse-int-float.js (right):

https://codereview.chromium.org/124573002/diff/1/test/mjsunit/parse-int-float...
test/mjsunit/parse-int-float.js:122: assertEquals(Number.parseFloat('0.1'),
parseFloat('0.1'));
On 2014/01/07 16:08:00, Michael Starzinger wrote:
> The spec requires "Number.parseFloat" and "parseFloat" to be the same
function
> object. I think we get that right, but can we add a test in that regard?
> 
> // Test that some properties refer to the same function object.
> assertSame(Number.parseInt, parseInt);
> assertSame(Number.parseFloat, parseFloat);

Added

[sof, 2014-01-07 21:44:55]

On 2014/01/07 17:35:25, Michael Starzinger wrote:
> On 2014/01/07 17:20:34, rossberg wrote:
> > On 2014/01/07 16:08:00, Michael Starzinger wrote:
> > > Technically this is looking good. I just have a few comments. 
> > > 
> > > But unfortunately I am not sure whether we can expose that to the web
> without
> > > putting it behind the Harmony flag. I am afraid of spontaneous
web-breakage.
> > > Andreas, opinions on that?
> > 
> > This seems very low risk, and I believe Mozilla implements it already. So I
> > think we can avoid the flag this time.
> 
> After my offline discussion with Andreas he convinced me that these changes
are
> low risk and I am fine with landing this as it is (after comments are
> addressed).

ok, thanks for that - the "non-flagged" presence of e.g. Number.isFinite() was
my direct cue for not putting them behind a flag. Extra properties on this
constructor is unlikely to upset existing code, but extra safety that others are
shipping these extensions also.

 Out of curiosity I just checked, Mozilla implements the following:
> - Number.isInteger
> - Number.parseInt
> - Number.parseFloat
> - Number.EPSILON
> 
> The following properties are not present though:
> - Number.isSafeInteger
> - Number.MIN_SAFE_INTEGER
> - Number.MAX_SAFE_INTEGER
> 
> On a side note, the following does not hold with Firefox nightly.
> Number.parseInt === parseInt

The "safe integer" addition is the most recent, I believe.

[Michael Starzinger, 2014-01-08 08:48:35]

LGTM. I will land this.