[JSC] timeClip(-0) should produce +0
Created attachment 340272 [details] Patch
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
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
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
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
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
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
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
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
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
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
Created attachment 340289 [details] Patch
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
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
(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.
Comment on attachment 340289 [details] Patch Please add a test
(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.
Committed r231762: <https://trac.webkit.org/changeset/231762>
<rdar://problem/40222300>
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?
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.
Committed r231864: <https://trac.webkit.org/changeset/231864>