-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add more Float16Array cases, and tests for Math.f16round #4017
Conversation
6233b23
to
0175d96
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started reviewing this but didn't finish. Here's what I have so far.
0 | ||
0, // 0 | ||
1, // 2049 | ||
3, // 2051 | ||
0, // 0.00006103515625 | ||
0, // 0.00006097555160522461 | ||
0, // 5.960464477539063e-8 | ||
0, // 2.9802322387695312e-8 | ||
0, // 2.980232238769532e-8 | ||
0, // 8.940696716308594e-8 | ||
0, // 1.4901161193847656e-7 | ||
0, // 1.490116119384766e-7 | ||
224, // 65504 | ||
240, // 65520 | ||
239, // 65519.99999999999 | ||
0, // 0.000061005353927612305 | ||
0 // 0.0000610053539276123 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't check how this is specified, but presumably these are equal to truncate(value) modulo 256, with the appropriate sign modifications for signed int8?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup (though as I say in the OP the values for the non-float16 cases are derived by doing the conversions on existing engines on the assumption they're correct, rather than by hand).
assert.sameValue(DataView.prototype.getFloat16.length, 1); | ||
|
||
verifyNotEnumerable(DataView.prototype.getFloat16, "length"); | ||
verifyNotWritable(DataView.prototype.getFloat16, "length"); | ||
verifyConfigurable(DataView.prototype.getFloat16, "length"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're trying to prefer verifyProperty
over the individual functions in new tests (command applies to other tests of property descriptors as well)
assert.sameValue(DataView.prototype.getFloat16.length, 1); | |
verifyNotEnumerable(DataView.prototype.getFloat16, "length"); | |
verifyNotWritable(DataView.prototype.getFloat16, "length"); | |
verifyConfigurable(DataView.prototype.getFloat16, "length"); | |
verifyProperty(DataView.prototype.getFloat16, "length", { | |
value: 1, | |
enumerable: false, | |
writable: false, | |
configurable: true, | |
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just copied these over from getFloat32
. Would you prefer to use verifyProperty
even if it means inconsistency between getFloat16
and all the other dataview methods? Or I can update the other dataview methods as part of this PR and achieve consistency that way, alternatively.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, if you feel like doing the extra cleanup work to update the other dataview methods, great! That would be very kind of you and much appreciated. But it's not a requirement as far as I'm concerned.
I do prefer that we don't introduce new tests using APIs that we're trying to phase out, even if it means temporary inconsistency. If we preferred consistency, it'd mean more and more work for the person eventually doing the cleanup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened #4023. I'll update whichever PR lands second to match the other.
|
||
assert.throws(TypeError, () => { | ||
let dv = new DataView(new ArrayBuffer(16)); new dv.getFloat16(0, 0); | ||
}, '`let dv = new DataView(new ArrayBuffer(16)); new dv.getFloat16(0, 0)` throws TypeError'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: I know the other not-a-constructor tests have these autogenerated assert messages, but let's not add more 😝
Could I suggest "DataView.prototype.getFloat16 should not be a constructor" and "Constructing DataView.prototype.getFloat16 should throw TypeError"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Would you also like me to update the tests I copied this from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened #4024.
assert.sameValue( | ||
typeof ArrayBuffer.prototype.resize, | ||
'function', | ||
'implements ArrayBuffer.prototype.resize' | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this necessary if we have the feature flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just copied this from the existing getFloat32
test. I don't think it's necessary but I would prefer the new tests match existing ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correctness lgtm. I don't have much of an opinion on the style of these tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I finished the rest of the review. All good with me, and many thanks for doing this. As for verifyProperty
, I'd prefer if we could use verifyProperty
in the new tests but I wouldn't block on it.
assert.throws(TypeError, function() { | ||
getFloat16.call({}); | ||
}, "{}"); | ||
|
||
assert.throws(TypeError, function() { | ||
getFloat16.call([]); | ||
}, "[]"); | ||
|
||
var ab = new ArrayBuffer(1); | ||
assert.throws(TypeError, function() { | ||
getFloat16.call(ab); | ||
}, "ArrayBuffer"); | ||
|
||
var ta = new Int8Array(); | ||
assert.throws(TypeError, function() { | ||
getFloat16.call(ta); | ||
}, "TypedArray"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just as a note to myself on future reads of this file and the following one, it's OK that the .call()
calls don't have plausible arguments because ToIndex(undefined) is 0.
(It's a common pattern elsewhere in the test corpus that these kinds of tests for RequireInternalSlot throwing forget to provide arguments, and in some of those cases the TypeArray might be coming from the missing argument if the implementation fails to include the test for the wrong receiver. That's not the case here. If you feel like adding them for readability, that's fine with me; also fine if you don't.)
var result; | ||
|
||
result = sample.setFloat16(0, 42, true); // 01010001 01000000 | ||
assert.sameValue(result, undefined, "returns undefined #1"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems sufficient to test that the return value is undefined in the following test, which is specifically for that purpose. (However, fine to just leave this in. Not a blocker.)
b37e7f3
to
1d0670c
Compare
@ptomato Should be. I rebased and re-ran my scripts from those PRs to make the same changes here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's time then! Really appreciate the extra cleanup work as well.
assert(!isConstructor(Math.f16round), "Math.f16round is not a constructor"); | ||
|
||
assert.throws(TypeError, function () { | ||
new Math.fround(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed this while working on the Ladybird browser project, isn't this supposed to be new Math.f16round()
instead of new Math.fround()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good catch. Do you want to make a PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! If someone else beats me to it, no issue either way.
Followup to #3849. Fixes #3828. (
Edit: actually I need the dataview methods also, which I'll try to get to soon. Doesn't invalidate these, it's just that more tests are needed.Done.)The structure of the TypedArray tests is such that you can't easily add tests for just one kind of typed array, so the values I'm adding need to be included in the "expected" lists for each of the typed array types. I automated that rather than doing all those by hand, but I did confirm the three major browser engines all agree (for the non-float16 cases; for the float16 ones I used conversion code I wrote and checked against other sources).
For the get/setFloat16 tests, I just copied the get/setFloat32 tests and modified as appropriate.