chore: clean-up - #13723
Merged
Merged
Conversation
Contributor
Coverage Report
The above coverage report was generated for the changes in this PR. |
array/uint64array/uint64
Planeshifter
marked this pull request as ready for review
July 28, 2026 16:25
kgryte
approved these changes
Jul 28, 2026
array/uint64
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
Follow-up fixes for commits merged to
developbetween 2026-07-27T14:38:24-07:00 (a8e87a88) and 2026-07-28T04:19:59-07:00 (b0d5d28b).This pull request:
array/uint64:Uint64Array.frominlib/node_modules/@stdlib/array/uint64/lib/main.js(introduced 382f2ca): loop bound waslen(element count) instead oftmp.length(word count), so only the first half of interleaved high/low words got copied and the rest stayed zero-filled. Bound now matches the constructor's iterable branch; existing tests only checked.length, not values, hence the miss.isUint64Array(lib/node_modules/@stdlib/array/uint64/lib/main.js, 382f2ca):typeof value === 'object'now runs before.constructoris dereferenced, soundefinedno longer throws a rawTypeErrorand instead falls through to the documented error path. Same pattern already used inarray/complex128andarray/bool; brings this helper in line.lib/node_modules/@stdlib/array/uint64/benchmark/benchmark.set.jsline 27 required@stdlib/array/float64instead of@stdlib/array/uint32, so the%s::typed_array:setbenchmark was silently timing aFloat64Arraysource rather than aUint32Arraysource. Corrects the require to match the sibling benchmarks in the package.8→*in the@throwscomment continuation ofUint64Array.fromJSDoc,lib/node_modules/@stdlib/array/uint64/lib/main.js:328, regression from 382f2ca.*continuation in thebyteLength/byteOffsetJSDoc blocks inlib/node_modules/@stdlib/array/uint64/lib/main.js(lines 499, 517), introduced in 382f2ca, to comply with the no-multi-line-comment-indentation rule and match the rest of the file.from_array.jsJSDoc introduced in 382f2ca (lib/node_modules/@stdlib/array/uint64/lib/from_array.js:33).indexcallback-arg description introduced in 382f2ca; seelib/node_modules/@stdlib/array/uint64/README.md:214.lib/node_modules/@stdlib/array/uint64/README.md:394andexamples/index.js:39.Related Issues
No.
Questions
No.
Other
Validation. All 25 commits merged to
developin the window were reviewed for bugs and stdlib style-guide compliance (JSDoc format, copyright years, naming, README/repl.txt structure, C style), with new packages compared against established reference packages (array/uint32,array/complex128,number/uint32/base/mul,blas/ext/base/dwxsa,blas/ext/base/dlogspace). Thefrom( iterable )andset( undefined )fixes were verified at runtime (frompreviously returned1, 2, 0, 0, 0for a 5-element iterable; it now returns1, 2, 3, 4, 5). The remaining packages in the window (blas/ext/base/dwxmy,zlogspace,dminheapify,number/uint64/base/mul,number/uint64/base/xor,assert/is-uint64array, ULP test migrations, doc relabelings) checked out clean, including recomputation of documented example values. TheCBLAS_INT sa[2]→int64_t sa[2]change inblas/ext/base/zcartesian-product(49960a0) was confirmed to be a legitimate fix, not a regression. Subjective concerns and anything requiring changes outside the window's diff were deliberately excluded.Checklist
AI Assistance
If you answered "yes" above, how did you use AI assistance?
Disclosure
This PR was written primarily by Claude Code as part of an automated review of commits merged to
developin the last 24 hours. All changes were verified against the repository state, and the behavioral fixes were validated at runtime. A human maintainer will audit before this PR is marked ready for review.Generated by Claude Code