[import-bytes] add initial tests for import bytes proposal#4648
[import-bytes] add initial tests for import bytes proposal#4648
Conversation
| import value from './bytes-from-empty-FIXTURE.bin' with { type: 'bytes' }; | ||
|
|
||
| assert(value instanceof Uint8Array); | ||
| assert(value.buffer instanceof ArrayBuffer); |
There was a problem hiding this comment.
there should be some kind of assertion that it's immutable (not sure what that'd look like tho)
same throughout
There was a problem hiding this comment.
The lines below are checking for immutable (asserts that an error is thrown on resize and also on transfer)
assert.throws(TypeError, function() {
value.buffer.resize(0);
});
assert.throws(TypeError, function() {
value.buffer.transfer();
});Let me know if there is a better way to check for immutability.
There was a problem hiding this comment.
Directly call the immutable accessor property https://tc39.es/proposal-immutable-arraybuffer/#sec-get-arraybuffer.prototype.immutable ?
There was a problem hiding this comment.
Interesting. I don't see any existing tests for ArrayBuffer.prototype.immutable.
I was basing this new test on the existing tests here:
There was a problem hiding this comment.
I went ahead and added the new assertion in cafcddc
There was a problem hiding this comment.
Interesting. I don't see any existing tests for
ArrayBuffer.prototype.immutable.
Still in PR, alas.
|
Note, the empty file is failing because fixture files need to contain the string |
|
@ptomato Thanks! I updated the fixtures to use underscores and that solved the However, I ran into another error. So I pushed some changes to the python code to ignore binary files. I see there are still a few engines on circleci that are failing. Please let me know how to proceed, thanks! |
|
@styfle instead of hardcoding binary extensions I think it'd be better to just skip cleaning any files with The CI jobs are timing out because they are detecting hundreds of tests as different in this PR than from main. Probably if you rebase on the latest state of the main branch, that'll go away. |
cafcddc to
25407a1
Compare
ptomato
left a comment
There was a problem hiding this comment.
👍 on the modifications to the test generator, everything else generally looks good.
| assert.sameValue(value.buffer.byteLength, 16); | ||
| assert.sameValue(value.buffer.immutable, true); | ||
|
|
||
| assert.compareArray( |
There was a problem hiding this comment.
This will fail, no? Comments won't be stripped from the JS file?
There was a problem hiding this comment.
The comments are only here for the human reader to make it clear that each byte represents a character in the js file that was imported, in this case:
var foo = 'bar'It should work just fine. Am I misunderstanding you?
There was a problem hiding this comment.
By my reading, the imported byte array should contain the UTF-8 encoding of
// Copyright (C) 2025 @styfle. All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.
var foo = 'bar'
and not
var foo = 'bar'
but this test expects the latter.
There was a problem hiding this comment.
I understand now, thanks!
You're right, I pushed commit fdc288c to remove it but then lint fails.
Is there a recommended way to disable lint on the FIXTURE files?
There was a problem hiding this comment.
I think I figured it out. I pushed ac5338b to disable license checks on files containing _FIXTURE in the name.
There was a problem hiding this comment.
Might be nicer to go the other way and include the bytes of the comment here instead of messing with the lint rules.
There was a problem hiding this comment.
I considered that but I figured I would fix it for everyone since fixture files are not source code.
It seems like this was the first fixture file to be js perhaps?
There was a problem hiding this comment.
On the contrary, fixture files are source code and this is not the first JS fixture file. JS fixture files are used extensively in other importing tests.
I think the best course of action is to keep the license header and include the bytes of the comment in the test, as annoying as that may be.
(You could say that it's ridiculous to license var foo = 'bar' and you would be right, but we don't want to get into the weeds of "is this JS file big enough to merit a license header". All JS files just need to have either the license header or the public domain declaration.)
There was a problem hiding this comment.
Ok I reverted those commits and pushed a change to read all the bytes 👍
Please take another look.
ptomato
left a comment
There was a problem hiding this comment.
Thanks!
It occurs to me that these tests will fail if checked out on Windows with git configured for core.autocrlf = true. (The 0x0a bytes will get replaced with 0x0d 0x0a on disk)
Do we need to specify in INTERPRETING.md that test262 consumers must not have core.autocrlf = true in their gitconfig?
|
Not really. The rule of thumb I've been trying to stick to is: if it's small, or has 2 reviews already, or is urgent for plenary, I merge it; otherwise, I leave a couple of days to see if anyone else comments. |
|
👋 Hi, I'm an automated AI code review bot. I ran some checks on this PR and found 2 points that might be worth attention (could be false positives, please use your judgment):
If you find these suggestions disruptive, you can reply "stop" , and I'll automatically skip this repository in the future. |
lies
Seems to be legit, @styfle PTAL? |
Uh oh!
There was an error while loading. Please reload this page.