Bug 185589 – [JSC] timeClip(-0) should produce +0

• Component: New Bugs
• Status: RESOLVED FIXED

[Yusuke Suzuki]

[JSC] timeClip(-0) should produce +0

[Yusuke Suzuki]

Created attachment 340272 [details]
Patch

[EWS Watchlist]

Comment on attachment 340272 [details]
Patch

Attachment 340272 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/7670542

New failing tests:
sputnik/Implementation_Diagnostics/S15.9.1.14_D1.html

[EWS Watchlist]

Created attachment 340273 [details]
Archive of layout-test-results from ews101 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-sierra  Platform: Mac OS X 10.12.6

[EWS Watchlist]

Comment on attachment 340272 [details]
Patch

Attachment 340272 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/7670552

New failing tests:
sputnik/Implementation_Diagnostics/S15.9.1.14_D1.html

[EWS Watchlist]

Created attachment 340274 [details]
Archive of layout-test-results from ews107 for mac-sierra-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-sierra-wk2  Platform: Mac OS X 10.12.6

[EWS Watchlist]

Comment on attachment 340272 [details]
Patch

Attachment 340272 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/7670558

New failing tests:
sputnik/Implementation_Diagnostics/S15.9.1.14_D1.html

[EWS Watchlist]

Created attachment 340275 [details]
Archive of layout-test-results from ews113 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews113  Port: mac-sierra  Platform: Mac OS X 10.12.6

[EWS Watchlist]

Comment on attachment 340272 [details]
Patch

Attachment 340272 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/7670589

New failing tests:
sputnik/Implementation_Diagnostics/S15.9.1.14_D1.html

[EWS Watchlist]

Created attachment 340276 [details]
Archive of layout-test-results from ews126 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews126  Port: ios-simulator-wk2  Platform: Mac OS X 10.13.4

[EWS Watchlist]

Comment on attachment 340272 [details]
Patch

Attachment 340272 [details] did not pass win-ews (win):
Output: http://webkit-queues.webkit.org/results/7670677

New failing tests:
sputnik/Implementation_Diagnostics/S15.9.1.14_D1.html

[EWS Watchlist]

Created attachment 340277 [details]
Archive of layout-test-results from ews201 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews201  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Yusuke Suzuki]

Created attachment 340289 [details]
Patch

[EWS Watchlist]

Comment on attachment 340289 [details]
Patch

Attachment 340289 [details] did not pass win-ews (win):
Output: http://webkit-queues.webkit.org/results/7674124

New failing tests:
http/tests/security/canvas-remote-read-remote-video-localhost.html

[EWS Watchlist]

Created attachment 340293 [details]
Archive of layout-test-results from ews200 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews200  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Yusuke Suzuki]

(In reply to Build Bot from comment #13)
> Comment on attachment 340289 [details]
> Patch
> 
> Attachment 340289 [details] did not pass win-ews (win):
> Output: http://webkit-queues.webkit.org/results/7674124
> 
> New failing tests:
> http/tests/security/canvas-remote-read-remote-video-localhost.html

It is not related to this change.

[Saam Barati]

Comment on attachment 340289 [details]
Patch

Please add a test

[Yusuke Suzuki]

(In reply to Saam Barati from comment #16)
> Comment on attachment 340289 [details]
> Patch
> 
> Please add a test

Thank you for your review!
I've added a stress test for this, which is separate from sputnik and test262's ones.

[Yusuke Suzuki]

Committed r231762: <https://trac.webkit.org/changeset/231762>

[Radar WebKit Bug Importer]

<rdar://problem/40222300>

[Darin Adler]

Comment on attachment 340289 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=340289&action=review

> Source/WTF/wtf/DateMath.cpp:1159
>          return std::numeric_limits<double>::quiet_NaN();

Not critical, but I think that the isfinite test is not needed. We could remove it without having any effect on test results except the code should be a tiny bit faster.

> Source/WTF/wtf/DateMath.cpp:1162
>      if (fabs(t) > maxECMAScriptTime)
>          return std::numeric_limits<double>::quiet_NaN();
> -    return trunc(t);
> +    return trunc(t) + 0.0;

If this was written recently we would probably be using std::abs and std::trunc.

I am also wondering if this gives the right result for values just a tiny bit larger than maxECMAScriptTime: in other words, should they be truncated first and then checked rather than checked first and then truncated?

[Yusuke Suzuki]

Comment on attachment 340289 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=340289&action=review

>> Source/WTF/wtf/DateMath.cpp:1159
>>          return std::numeric_limits<double>::quiet_NaN();
> 
> Not critical, but I think that the isfinite test is not needed. We could remove it without having any effect on test results except the code should be a tiny bit faster.

I was considering about NaN case, but it seems that NaN can work with the following code. Nice catch. I'll remove this.

>> Source/WTF/wtf/DateMath.cpp:1162
>> +    return trunc(t) + 0.0;
> 
> If this was written recently we would probably be using std::abs and std::trunc.
> 
> I am also wondering if this gives the right result for values just a tiny bit larger than maxECMAScriptTime: in other words, should they be truncated first and then checked rather than checked first and then truncated?

Using std::abs and std::trunc sounds fine. I'll do it in a follow-up change.

I think this order is OK since this is corresponding to the spec https://tc39.github.io/ecma262/#sec-timeclip.
I believe that the rationale behind this is if t is larger than maxECMAScriptTime, even if it can be trunc-ed to maxECMAScriptTime, it returns NaN since the original value was actually larger than maxECMAScriptTime.

[Yusuke Suzuki]

Committed r231864: <https://trac.webkit.org/changeset/231864>