Fix 'illegal access' in Date constructor edge case

Fix 'illegal access' in Date constructor edge case

In a rare edge case, a difference in checks between C++ and
JavaScript lead to an 'illegal access' being thrown by the Date
constructor. This patch harmonizes the checks from both sides.
It's possible that slightly larger dates could be permitted,
as the ECMAScript 2015 specification indicates that +287396-10-12
would be a permissible date in the note in
http://tc39.github.io/ecma262/#sec-extended-years
This patch does not revisit the limit, only clears up the
inconsistency.

BUG=v8:4640
R=cbruni
LOG=Y

Committed: https://crrev.com/a9c791009b747b9f518e3801d665ca8c5969b1d1
Cr-Commit-Position: refs/heads/master@{#33068}

[Dan Ehrenberg, 2015-12-23 06:25:02]

The CQ bit was checked by littledan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-23 06:25:10]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1545883003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1545883003/1

[commit-bot: I haz the power, 2015-12-23 06:38:06]

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

[commit-bot: I haz the power, 2015-12-23 06:38:06]

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

[Dan Ehrenberg, 2015-12-23 06:49:56]

The CQ bit was checked by littledan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-23 06:50:04]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1545883003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1545883003/20001

[commit-bot: I haz the power, 2015-12-23 07:02:29]

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

[commit-bot: I haz the power, 2015-12-23 07:02:29]

Dry run: Try jobs failed on following builders:
  v8_linux_nodcheck_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel/build...)

[Camillo Bruni, 2015-12-23 14:46:08]

LGTM with comments.

https://codereview.chromium.org/1545883003/diff/20001/src/js/macros.py
File src/js/macros.py (right):

https://codereview.chromium.org/1545883003/diff/20001/src/js/macros.py#newcod...
src/js/macros.py:193: # Limit which is MAX_TIME_MS + msPerMonth.
Please update the comment.

https://codereview.chromium.org/1545883003/diff/20001/src/js/macros.py#newcod...
src/js/macros.py:194: define MAX_TIME_BEFORE_UTC = 8640000000000000;
DateCache::kMaxTimeBeforeUTCInMs is 
8640000864000000, you set it to
8640000000000000, and previously it was
8640002592000000, so to me that does not clear the inconsistency :P it just puts
us on the safe side.

Could we add a cctest to somehow ensure that these constants are in sync?

[Dan Ehrenberg, 2015-12-24 04:39:39]

The CQ bit was checked by littledan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-24 04:39:45]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1545883003/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1545883003/60001

[commit-bot: I haz the power, 2015-12-24 05:21:41]

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

[commit-bot: I haz the power, 2015-12-24 05:21:42]

Dry run: This issue passed the CQ dry run.

[Dan Ehrenberg, 2015-12-25 01:00:49]

https://codereview.chromium.org/1545883003/diff/20001/src/js/macros.py
File src/js/macros.py (right):

https://codereview.chromium.org/1545883003/diff/20001/src/js/macros.py#newcod...
src/js/macros.py:193: # Limit which is MAX_TIME_MS + msPerMonth.
On 2015/12/23 at 14:46:08, cbruni wrote:
> Please update the comment.

Following more investigation, I decided to keep the JS how it was (test262 tests
seem to verify this particular threshold) and update the C++ side, so this
comment is accurate again.

https://codereview.chromium.org/1545883003/diff/20001/src/js/macros.py#newcod...
src/js/macros.py:194: define MAX_TIME_BEFORE_UTC = 8640000000000000;
On 2015/12/23 at 14:46:08, cbruni wrote:
> DateCache::kMaxTimeBeforeUTCInMs is 
> 8640000864000000, you set it to
> 8640000000000000, and previously it was
> 8640002592000000, so to me that does not clear the inconsistency :P it just
puts us on the safe side.
> 
> Could we add a cctest to somehow ensure that these constants are in sync?

Oops, you're right. But do you have a good idea for how to write a test which
gets at both a C++ constant and a macro (when the macro expansion system is
written in Python)?

[Dan Ehrenberg, 2015-12-30 23:12:20]

The CQ bit was checked by littledan@chromium.org

[Dan Ehrenberg, 2015-12-30 23:12:21]

The patchset sent to the CQ was uploaded after l-g-t-m from cbruni@chromium.org
Link to the patchset: https://codereview.chromium.org/1545883003/#ps60001
(title: "Switch back to the original JS limit, which is now vindicated, with
additional tests")

[commit-bot: I haz the power, 2015-12-30 23:12:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1545883003/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1545883003/60001

[commit-bot: I haz the power, 2015-12-30 23:54:31]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-12-30 23:55:05]

Description was changed from

==========
Fix 'illegal access' in Date constructor edge case

In a rare edge case, a difference in checks between C++ and
JavaScript lead to an 'illegal access' being thrown by the Date
constructor. This patch harmonizes the checks from both sides.
It's possible that slightly larger dates could be permitted,
as the ECMAScript 2015 specification indicates that +287396-10-12
would be a permissible date in the note in
http://tc39.github.io/ecma262/#sec-extended-years
This patch does not revisit the limit, only clears up the
inconsistency.

BUG=v8:4640
R=cbruni
LOG=Y
==========

to

==========
Fix 'illegal access' in Date constructor edge case

In a rare edge case, a difference in checks between C++ and
JavaScript lead to an 'illegal access' being thrown by the Date
constructor. This patch harmonizes the checks from both sides.
It's possible that slightly larger dates could be permitted,
as the ECMAScript 2015 specification indicates that +287396-10-12
would be a permissible date in the note in
http://tc39.github.io/ecma262/#sec-extended-years
This patch does not revisit the limit, only clears up the
inconsistency.

BUG=v8:4640
R=cbruni
LOG=Y

Committed: https://crrev.com/a9c791009b747b9f518e3801d665ca8c5969b1d1
Cr-Commit-Position: refs/heads/master@{#33068}
==========

[commit-bot: I haz the power, 2015-12-30 23:55:06]

Patchset 4 (id:??) landed as
https://crrev.com/a9c791009b747b9f518e3801d665ca8c5969b1d1
Cr-Commit-Position: refs/heads/master@{#33068}