Missing coverage: Resizable / GrowableSharedArrayBuffers: testing that the TypedArray.prototype functions do the right thing

[marjakh]

The existing tests (e.g., built-ins/TypedArray/prototype//return-abrupt-from-this-out-of-bounds.js ) only test whether an error is or isn't thrown.

We should also test:

• That the return value is correct
• That the expected side effect happened (e.g., with fill)
• That the callback was called the correct amount of times with the correct parameters (for functions which take a callback, e.g., filter)
• That the index computations happened correctly (for functions which take some kind of an index parameter which can also be negative, e.g., includes) (Note: interesting case is that the AB was resized before the index computation happens - then we should use the original length, not the update length.)

cc @jugglinmike

[jugglinmike]

Thanks for the report! As the names of those tests suggest, they are intentionally limited to verifying the abrupt completion introduced by the Resizable Arraybuffer proposal. I believe the other semantics you've mentioned are already covered by other tests since they are observable from ECMAScript code today (but I'd be glad to learn about any cases where that's not true).

I can appreciate how in some implementations, some of those same behaviors might utilize distinctive code paths in the context of a resized ArrayBuffer. From that perspective, new tests that only differed in their use of a resized ArrayBuffer could potentially identify novel defects.

That said, it's not clear to me which cases would be specifically interesting to a plurality of implementations. As a non-implementer, my naive approach would be to duplicate ALL of the existing tests, simply adding code to resize the underlying buffers! This would be very difficult to maintain, particularly given the special care Test262 needs to take to support the proposal's optional semantics. And despite our efforts, I expect most of the new tests would not uncover distinctive bugs.

To verify whether resizable ArrayBuffers correctly interact with the existing semantics, I'd need an better picture of why some cases are more interesting than others. I imagine other contributors would need to learn this, as well. Could you help me understand?

[marjakh]

Thanks for looking into this!

Strictly speaking, the other semantics aren't covered by other tests, afaics, since they never pass TypedArrays with resizable / growable backing to the function under test.

A VM might reasonably implement resizable-backing-TypedArrays with a completely separate object type (so that there are TypedArrays and resizable-backing-TypedArrays and those are fully separate) and thus have bugs in the basic functionality. Even if the VM doesn't implement resizable-backing-TypedArrays as separate objects, we'll still have somewhat separate code paths for normal TypedArrays and resizable-backing-TypedArrays. So I think it's relevant for test262 to include tests which test that TypedArray.prototype operations yield the correct results.

E.g., one actual bug I had in V8 was the the "is detached" check in some TypedArray.prototype.foo function was not working correctly for resizable-backing TypedArrays. The existing test262 which passes a detached TypedArray to TypedArray.prototype.foo would've caught it if it had been extended to test resizable-backing-TypedArrays too.

Extending the existing tests by making the backing (Shared)ArrayBuffer configurable might be a relevant option here. That could be done without duplicating the test, e.g., mimicking the way the tests are currently extended to different TypedArray kinds (UINT8, INT8,..). Just using a resizable-backing-TA (but never actually resizing it in the test) would be a good first step.

Adding tests which resize and check that the results after resizing are still correct would be the next step, and that too is relevant IMO, especially for length-tracking TypedArrays. There we might reasonably have bugs like "even if it was resized, we still used the original length" or some other problems in computing the new length.