Caret pragma on test/lib/LibCodeGenSlow.sol

[thedavidmeister]

Closes #67

What changed

test/lib/LibCodeGenSlow.sol:3 moves from pragma solidity =0.8.25 to
pragma solidity ^0.8.25. It is a library file, and the org convention is ^
for library and abstract files, = for concrete. That one character is the
entire diff against main.

This can regress silently, and no test guards it

There is no test for this change, and there deliberately is not one.

solc is pinned to 0.8.25 in foundry.toml, so widening the accepted range
on one file changes no bytecode, no ABI, no gas and no test outcome. There is
nothing for a test to observe. The consequence is stated plainly: this fix can
regress silently. Someone can re-pin this file to =0.8.25, or add a new
library file that pins, and the suite, forge fmt --check and every CI job in
this repo will stay green and say nothing.

The convention check that would catch that is being rehomed to
rainlanguage/rainix#317
(rainlanguage/rainix#317). It belongs there: the
pragma convention is an org rule spanning many repos, and a rule that every repo
must satisfy is a job for rainix-static, not a Solidity test re-implemented in
each consumer. Until #317 lands, this convention is held by review alone.

What was removed from this PR

This PR previously carried its own repo wide lint. That is gone:

• test/lint/PragmaConvention.t.sol deleted (164 lines, 5 tests). It walked
  src, test and script with vm.readDir, classified each file by its top
  level declaration keyword, and asserted the pragma operator matched. Its
  subject was the repo's source tree as text — hand-rolled static analysis in
  Solidity, which is exactly the shape rainlanguage/rainix#317 exists to
  absorb.
• The three fs_permissions read grants it needed (src, test, script) and
  their explanatory comment are reverted. fs_permissions is back to main's
  block exactly.

The fixer brief driving this fleet of PRs said "every fix ships a test,
verify-by-hand is never acceptable", with no exemption for changes that have no
behaviour. That was wrong and is corrected. It is what produced hand-rolled
static analysis in Solidity across nine PRs, this one among them.

QA

origin/main is merged in (not rebased); the branch predated merged PRs #110
and #124. The only conflict was foundry.toml, resolved by taking main's
ffi = true block and dropping this branch's three read grants.

Everything below ran with nix develop -c, foundry from the flake.

Full suite

nix develop -c forge test

Ran 18 test suites in 2.06s (19.63s CPU time): 142 tests passed, 0 failed, 0 skipped (142 total tests)

origin/main (b422d97) in a clean worktree gives the same 142 tests in 18
suites, which is the expected result: after the strip this branch adds no test
and removes none that main has. Before the strip the branch ran 139 tests in
17 suites against a 134-test main; the five extra tests were the deleted lint
file's, and 5 is the drop.

forge fmt --check

nix develop -c forge fmt --check exits 0 with no diff.

Mutation

Not applicable. The change alters no behaviour under the pinned compiler, so
there is no line whose mutation any test could observe. That is the same fact as
"no test guards it" above, stated from the mutation side.

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 59 seconds

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: 71746696-d32b-44d3-960f-ff4c0add6194

📥 Commits

Reviewing files that changed from the base of the PR and between b422d97 and b1ff797.

📒 Files selected for processing (1)

• test/lib/LibCodeGenSlow.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.}