chore: scope forge-lint disables for the 37 findings on main

[thedavidmeister]

forge lint -D warnings reports 37 findings on unmodified main and fails the rainix-sol / static job. Every one of the 37 is a false positive or a construct the surrounding test deliberately asserts, so each gets a scoped //forge-lint: disable-next-line(<rule>) and a one-line reason. No behaviour, and no code, changes: the diff is 74 added comment lines and nothing else.

QA

• Discriminating tests: forge lint -D warnings in github:rainlanguage/rainix/8657b83b68f41957ab85da91132c3f652c1f32c0#sol-shell is the gate and the test. Fails on base: 37 findings, exit 1. Passes here: 0 findings, exit 0. forge test (128 passed, 17 suites), forge fmt --check, slither . (0 results) and rainix-sol-single-contract all pass on both sides, confirming the diff is inert.
• Mutations applied: every directive in the four touched files was neutralised one at a time and lint re-run, 38 runs (37 added plus the one already at LibGenParseMeta.buildMeta.t.sol:52). Each produced exactly 1 finding, of the expected rule, at the exact line that directive guards: 38 pass, 0 fail. So no directive is redundant and none is silencing a neighbour. Scoping check: three directives, one per rule, were repointed at a different rule id — boolean-cst->unsafe-typecast at LibParseMeta.sol:163, incorrect-shift->boolean-cst at buildMeta.t.sol:25, unsafe-typecast->incorrect-shift at sourceRelativeOffset.t.sol:105. All three let the original finding straight back through, so these are per-rule disables and not blanket ones.
• Oracle: the rules' own published definitions, not the tool's output. incorrect-shift is documented as a Yul shl/shr argument-order check; none of its three sites is Yul. For the shift in buildMeta.t.sol the test is its own oracle — the next line asserts META_ITEM_MASK == type(uint32).max, which a transposed shift could not satisfy. For the 32-byte literals the oracle is solc, which rejects an over-wide literal at compile time. Precedent as a second reader: the org already carries these exact disables for these exact shapes (see per-finding table).
• Category check: the ask is the 37 forge lint -D warnings findings on main, each decided as fix-or-disable and said which; covered, all 37 below. The other red gate on main, pre-commit run --all-files, is chore: apply pre-commit formatting to main #139 and is not touched here.

Why main has never been through this

rainix added forge lint -D warnings to the shared rainix-sol-static workflow at 2026-09-15T20:59Z. main's last run was 2026-09-15T17:16Z (#137). A fresh clone of unmodified main reproduces all 37.

The decision on each finding

Zero of the 37 are real. Each line below says why, and names where the org already made the same call.

boolean-cst x3 — src/lib/parse/LibParseMeta.sol:162, 179, 184 — false positive, disabled.

The three are return (false, 0), return (true, index) and return (false, 0), the three exits of lookupWord, which is declared returns (bool, uint256). The org bans named returns, so the found/not-found flag can only be written as a literal in the return tuple — there is no other spelling. boolean-cst exists to catch a boolean constant standing where a condition belongs (if (x == true), require(true), a constant operand of &&/||); a return value is not a condition operand. Each of the three is the sole exit of a distinct control path and the paired uint256 is meaningful at each (0 is the documented not-found value, index is read from the matched item), so nothing here is dead, tautological or unreachable. rain.lib.memkv/test/lib/LibMemoryKVSlow.sol has the identical shape — exists returning (bool, uint256) — already carrying this disable.

incorrect-shift x3 — LibGenParseMeta.buildMeta.t.sol:24, LibParseMeta.lookupWord.t.sol:123, 132 — false positive, disabled.

The rule documents itself as a Yul check: it warns when the first argument to a Yul shl/shr is dynamic and the second is a literal, because shr(value, 8) shifts the literal. None of the three sites is Yul. All three are Solidity's <<, whose operand order is fixed by the language as value-then-amount and cannot be transposed, in the canonical single-bit idiom 1 << n:

• lookupWord.t.sol:123 — if (shifted == (1 << i)) walks bit positions to find the one bit wordBitmapped set. wordBitmapped builds that value as Yul shl(byte(0, hashed), 1), the same one-bit shape.
• lookupWord.t.sol:132 — 1 << fakeBitPos builds a one-bit expansion.
• buildMeta.t.sol:24 — (1 << (META_ITEM_SIZE * 8)) - 1 is 0xFFFFFFFF. The order is pinned by the test itself: the very next line asserts META_ITEM_MASK == type(uint32).max, and transposed operands would give (4 * 8) << 1 = 64, - 1 = 63. Both assertions cannot hold unless the order is the one written.

rainlang/test/src/lib/parse/LibParseSlow.sol disables this rule for the same 1 << <dynamic> idiom.

unsafe-typecast x27 — bytes32("<literal>") — false positive, disabled.

lookupWord.t.sol:26, 27, 28, 46, 61, 89, 160, 161, 162, 176, 180, 188, 192, 197, 204, 207, 208, 209, 286, 329 and buildMeta.t.sol:178, 179, 180, 211, 219, 228, 229. Each is an explicit conversion of a string literal to bytes32. solc validates the width at compile time — a literal wider than 32 bytes is a compile error, not a silent truncation — and every one of the 27 is 3 to 9 ASCII characters. There is no runtime value for the cast to truncate. rainlang/test/src/lib/parse/LibParse.parseWord.t.sol carries this disable for the same shape, reasoned as "Casting a small literal is safe to typecast."

unsafe-typecast x2 — LibParseMeta.lookupWord.t.sol:154, 257 — false positive, disabled.

Both are uint8(x & 0xFF): the operand is masked to 8 bits in the same expression, so the cast is width-preserving. Worth noting the rule is inconsistent here rather than wrong about safety — the sibling lines two and three above each of these, uint8((x >> 16) & 0xFF) and uint8((x >> 8) & 0xFF), are equally safe and are not flagged. Only the flagged pair needs a directive.

unsafe-typecast x1 — LibBytecode.sourceRelativeOffset.t.sol:104 — false positive, disabled.

bytes1(uint8(offset >> 8)) where offset is a uint16 fuzz parameter, so the shifted value is at most 0xFF.

unsafe-typecast x1 — LibBytecode.sourceRelativeOffset.t.sol:105 — real truncation, deliberate, disabled.

bytes1(uint8(offset)) on the same uint16 genuinely drops the high byte, and that is the point: line 104 writes the high byte and line 105 the low byte of a 16-bit big-endian offset. This is the one finding where silencing could hide something, so it is the one to check hardest — and it cannot, because the test exists to catch exactly that. testSourceRelativeOffsetHighByteReference assumes offset >= 0x100 to force a non-zero high byte, then asserts sourceRelativeOffset returns the full offset and agrees with LibBytecodeSlow. A wrong truncation fails two assertions two lines down. This repo already carries the identical pattern and reasoning at test/abstract/BytecodeTest.sol:65-70.

Merge order

rainix-sol / static runs forge lint before pre-commit, and main is red at both. Neither fix can be green alone: this branch clears lint and then fails at pre-commit, #139 clears pre-commit but never reaches it because lint fails first. Whichever lands first therefore merges with static red at the step the other PR fixes. #139 goes first, then this rebases onto it and runs fully green before merging.

🤖 Generated with Claude Code

https://claude.ai/code/session_01V8ViHcKLVk2YoS2joH4HdN

[coderabbitai]

Warning

Review limit reached

Next included review available in 22 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

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

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: cf8e9462-b127-46b4-81dd-5224fe069ea5

📥 Commits

Reviewing files that changed from the base of the PR and between 9d5d96d and bdf7e8b.

📒 Files selected for processing (4)

• src/lib/parse/LibParseMeta.sol
• test/src/lib/bytecode/LibBytecode.sourceRelativeOffset.t.sol
• test/src/lib/codegen/LibGenParseMeta.buildMeta.t.sol
• test/src/lib/parse/LibParseMeta.lookupWord.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.}

[github-actions]

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

• Simple bug fixes, typos, or minor refactoring
• Single-purpose changes affecting 1-2 files
• Documentation updates
• Configuration tweaks
• Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

• Fix typo in variable name
• Update README with new instructions
• Adjust configuration values
• Simple one-line bug fixes
• Import statement cleanup

Medium (M)

Characteristics:

• Feature additions or enhancements
• Refactoring that touches multiple files but maintains existing behavior
• Breaking changes with backward compatibility
• Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

• Add new feature or component
• Refactor common utility functions
• Update dependencies with minor breaking changes
• Add new component with tests
• Performance optimizations
• More complex bug fixes

Large (L)

Characteristics:

• Major feature implementations
• Breaking changes or API redesigns
• Complex refactoring across multiple modules
• New architectural patterns or significant design changes
• Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

• Complete new feature with frontend/backend changes
• Protocol upgrades or breaking changes
• Major architectural refactoring
• Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

• Test coverage impact: More comprehensive test changes lean toward larger classification
• Risk level: Changes to critical systems bump up a size category
• Team familiarity: Novel patterns or technologies increase complexity

Notes:

• the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
• the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
• do not include any additional text, only the size classification
• your assessment comment must not include tips or additional sections
• do NOT tag me or anyone else on your comment