Name unsafeExtend's arrays and the sentinel tuple size, and point the matrix tests at their subject

[thedavidmeister]

Closes #95

Verified against main first

Checked at 9a238f4, and everything the issue claims still stood:

• src/lib/LibUint256Array.sol and src/lib/LibBytes32Array.sol declared unsafeExtend(T[] memory b, T[] memory e), the doc block above them named the same two values base_/extend_, and the inner Yul helper named them base/extend. Three names for two values, on the function whose whole safety contract is which argument gets mutated.
• src/lib/LibStackSentinel.sol declared consumeSentinelTuples(..., uint256 n).
• test/src/lib/LibUint256Matrix.matrixFrom.t.sol:11 declared contract LibUint256ArrayMatrixFromTest and test/src/lib/LibBytes32Matrix.matrixFrom.t.sol:11 declared contract LibBytes32ArrayMatrixFromTest, so --match-contract LibUint256Matrix never ran either suite.
• The issue's "checked and clean" half also still holds: no state or immutable variables anywhere, and no underscored local or parameter in any first-party .sol.

Main has since moved to 7620643, merged in here.

What changed

unsafeExtend: b/e -> baseArray/extendArray in both array libraries, doc block and @param tags following the declaration.

Not base/extend as the issue proposed — the inner Yul helper's parameters already hold those names and solc rejects the collision:

Error (6578): Cannot access local Solidity variables from inside an inline assembly function.

on every base/extend reference in the helper body. The helper keeps its own names: on the copy path its base is newBase, a fresh copy, not the caller's array.

consumeSentinelTuples: n -> tupleSize, matching ZeroSentinelTupleSize and LibStackSentinel.tupleSizeWrap.t.sol. The NatSpec and the two inline comments that named n follow it, and their paragraphs are rewrapped, so the diff on those lines is wider than the rename.

Test contracts renamed to LibUint256MatrixMatrixFromTest and LibBytes32MatrixMatrixFromTest.

arrayFrom(uint256 a, uint256 b, ...) is untouched — the issue rules the positional slots out of scope.

Renames and comment text only; no behaviour changed.

Mutation table

All runs below are on the merge commit. Baseline there: nix develop -c forge test = 34 suites, 353 tests passed, 0 failed, and nix develop -c forge fmt --check clean. Every row carries its test count, so no row is a zero-match filter faking a survivor.

#	Mutation	Run	Result
M1	LibUint256Array.unsafeExtend: extendInline(baseArray, extendArray) -> extendInline(extendArray, baseArray)	full suite, 353 tests	KILLED, 7 failed: testExtendInline, testExtendAllocate, testExtendAllocateDebug, testExtendInlineAllocatesExactly, testExtendAllocateAllocatesExactly, testExtendInlineDoesNotWritePastFreeMemoryPointer, testExtendInlineEmptyExtendKeepsBasePointer
M2	LibBytes32Array.unsafeExtend: same argument swap	full suite, 353 tests	KILLED, same 7
M3	LibStackSentinel: uint256 size = tupleSize * 0x20 -> * 0x40	full suite, 353 tests	KILLED, 11 failed, incl. testConsumeSentinelTuplesMultiSize, testConsumeSentinelTuplesSharedSubWordOffset, testConsumeSentinelTuplesNegativeStrideCannotSucceedSilently
M4	LibStackSentinel: if (tupleSize == 0) -> if (tupleSize == 1)	full suite, 353 tests	KILLED, 9 failed, incl. testConsumeSentinelTuplesNZeroError, testConsumeSentinelTuplesNZeroErrorPrecedence, testConsumeSentinelTuplesBelowLower
M5a	LibUint256Matrix: mstore(add(matrix, 0x60), c) -> ..., b), hitting the 3+ argument matrixFrom overloads that no other matrix suite calls	--match-contract LibUint256Matrix, this branch: 6 suites, 41 tests	KILLED, 1 failed: testMatrixFromABC
M5b	same mutation, test contract renamed back to main's LibUint256ArrayMatrixFromTest	same filter: 5 suites, 32 tests	SURVIVED — the matrixFrom suite is outside the filter, its 9 tests never run
M6a	LibBytes32Matrix: same mutation	--match-contract LibBytes32Matrix, this branch: 6 suites, 41 tests	KILLED, 1 failed: testMatrixFromABC
M6b	same mutation, test contract renamed back to main's LibBytes32ArrayMatrixFromTest	same filter: 5 suites, 32 tests	SURVIVED

M5b/M6b are the finding itself: on main that filter silently drops a whole suite, and a real defect in matrixFrom walks through it green.

Overlap

#136 (issue #84) rewrites the same unsafeExtend doc block to say b/e, matching main's declaration. This renames the declaration instead, so whichever lands second merges main in and keeps the declared names.

QA

• Discriminating tests: no new tests — this is a rename. The existing LibUint256MatrixMatrixFromTest/LibBytes32MatrixMatrixFromTest suites become discriminating under --match-contract LibUint256Matrix/LibBytes32Matrix for the first time: M5b/M6b show the same mutant surviving that filter under main's contract names (32 tests run) and dying under the new names (41 tests run, testMatrixFromABC fails).
• Mutations applied: extendInline(baseArray, extendArray) -> extendInline(extendArray, baseArray) in LibUint256Array -> killed by testExtendInline +6; same in LibBytes32Array -> killed by the same 7; uint256 size = tupleSize * 0x20 -> * 0x40 -> killed by testConsumeSentinelTuplesMultiSize +10; if (tupleSize == 0) -> if (tupleSize == 1) -> killed by testConsumeSentinelTuplesNZeroError +8; mstore(add(matrix, 0x60), c) -> ..., b) in both matrix libraries -> killed by testMatrixFromABC under the new contract names, survives under main's.
• Oracle: the issue's naming rule plus the compiler. The renames are behaviour-preserving by construction, so the oracle for "nothing moved" is the unmutated suite (353 tests, 0 failed) and the four src mutations above, each of which still dies exactly where it died before the rename. forge fmt --check is the formatting oracle.
• Category check: issue asks (a) rename the two misnamed matrix test contracts, (b) rename b/e on unsafeExtend in both array libraries with the @param tags and inner call site, (c) rename n on consumeSentinelTuples. Covered a, b, c. (b) lands as baseArray/extendArray rather than the issue's proposed base/extend, which solc rejects (error 6578) against the inner Yul helper's own parameters. The issue's explicit non-finding (arrayFrom's positional a..h) is left alone.

[coderabbitai]

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 57 minutes

Limit details: You’ve used all 1 included review currently available under your plan.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: a3ec43ef-689d-4a12-a787-f3157a7fe866

📥 Commits

Reviewing files that changed from the base of the PR and between b74081b and 80873e6.

📒 Files selected for processing (5)

• src/lib/LibBytes32Array.sol
• src/lib/LibStackSentinel.sol
• src/lib/LibUint256Array.sol
• test/src/lib/LibBytes32Matrix.matrixFrom.t.sol
• test/src/lib/LibUint256Matrix.matrixFrom.t.sol

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}