fix: properly compare TypedArrays of all types
#15178
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for jestjs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
SimenB
commented
Jul 11, 2024
| const a = Uint8Array.from([2, 4]).buffer; | ||
| const b = Uint16Array.from([1, 7]).buffer; | ||
| expect(arrayBufferEquality(a, b)).not.toBeTruthy(); | ||
| expect(arrayBufferEquality(a, b)).toBe(false); |
Member
Author
There was a problem hiding this comment.
this was a separate bug - it returned undefined, not false since Uint16Array.from([1, 7]).buffer instanceOf ArrayBuffer for some reason is `false.
SimenB
commented
Jul 11, 2024
| let dataViewB = b; | ||
|
|
||
| if (a instanceof ArrayBuffer && b instanceof ArrayBuffer) { | ||
| if (isArrayBuffer(a) && isArrayBuffer(b)) { |
Member
Author
There was a problem hiding this comment.
this is to fix https://github.com/jestjs/jest/pull/15178/files#r1673797042
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This partially addresses #15176, in that it
toEqualcall drop from 500ms to 100ms (due to us not using the iterator, but iterating "normally" which is 5x faster)toStrictEqualit drops to 3-4 ms, comparable tolodashimplementation (without the changes in this PR, there is no difference betweentoEqualandtoStrictEqual)There might be a case for us to include
arrayBufferEqualityin the custom matchers we use intoEqualhere:jest/packages/expect/src/matchers.ts
Lines 626 to 629 in 76514a8
In that case,
toEqualalso drops down to 3-4 ms runtime.Test plan
Tests added