Bump rain-math-binary 0.1.1 -> 0.1.3

[thedavidmeister]

Bumps the Soldeer dependency rain-math-binary from 0.1.1 to 0.1.3.

The 0.1.1 -> 0.1.3 delta in that library is NatSpec/comment-only in
src/lib/LibCtPop.sol — there is no behavioural change, so this is a
mechanical version move.

This repo uses version-suffixed Soldeer remappings, so the version string
appears in remappings.txt and inside every import that names the package.
That form is deliberate and is preserved here — the only change is 0.1.1 ->
0.1.3 in place. No unversioned alias was introduced and no version suffix was
collapsed away.

BLOCKED — this cannot compile yet, and CI is expected to be red

This PR is blocked upstream on rain-interpreter-interface and will not go
green until that package is republished against rain-math-binary 0.1.3. It
is staged here so the mechanical work is on the record; it is not ready to land.

foundry.toml sets [soldeer] recursive_deps = false, so rainlang keeps a flat
dependency set and rainlang's own remappings.txt is what has to satisfy the
hard-coded versioned imports inside its dependencies. rain-interpreter-interface-0.1.0
— which this repo pins — imports rain-math-binary-0.1.1 from compiled src/,
not just from its tests:

• dependencies/rain-interpreter-interface-0.1.0/src/lib/parse/LibParseMeta.sol:5
• dependencies/rain-interpreter-interface-0.1.0/src/lib/codegen/LibGenParseMeta.sol:13

Both are squarely on rainlang's compile path — src/lib/parse/LibParse.sol:23
imports LibParseMeta, and script/Build.sol:18 imports LibGenParseMeta —
so once the rain-math-binary-0.1.1/ remapping is gone these imports dangle and
forge build fails. The latest published rain-interpreter-interface (0.1.2)
still pins rain-math-binary 0.1.1, so no combination of currently published
versions resolves this today.

(rain-extrospection-0.1.1 also references rain-math-binary-0.1.1, but only
from its own test/ tree, which this repo does not compile. It is not part of
the block.)

Follow-up required before this is mergeable: once rainlang.interface
republishes rain-interpreter-interface against rain-math-binary 0.1.3, a
follow-up commit on this branch bumps rain-interpreter-interface to that new
version (and moves its version-suffixed remapping and imports the same way this
PR moves rain-math-binary's). CI should be expected to go green only after
that commit.

Files changed

File	Change
foundry.toml	"rain-math-binary" = "0.1.1" -> "0.1.3"
remappings.txt	rain-math-binary-0.1.1/=dependencies/rain-math-binary-0.1.1/ -> -0.1.3/ on both sides
soldeer.lock	regenerated by forge soldeer update (version, url, checksum, integrity)
src/lib/op/bitwise/LibOpBitwiseCountOnes.sol	LibCtPop import -> rain-math-binary-0.1.3/
test/src/lib/op/bitwise/LibOpBitwiseCountOnes.t.sol	LibCtPop import -> rain-math-binary-0.1.3/
test/src/lib/parse/LibParseState.constantValueBloom.t.sol	LibCtPop import -> rain-math-binary-0.1.3/

6 files changed, 9 insertions(+), 9 deletions(-). Nothing else is touched — no
unrelated lint fixes, no refactors, no other dependency bumps.

QA

• Discriminating tests: n/a - this diff adds no behaviour and therefore no new
  test. It moves a version string in foundry.toml, remappings.txt,
  soldeer.lock and three import lines; the upstream 0.1.1 -> 0.1.3 delta
  is NatSpec/comment-only in src/lib/LibCtPop.sol. The existing
  LibOpBitwiseCountOnes and LibParseState.constantValueBloom suites are the
  coverage for LibCtPop. Not verified locally - see the delegation note below.
• Mutations applied: n/a - no logic changed, so there is no line to mutate. The
  equivalent falsification for a remapping bump is that a wrong or stale version
  path fails to resolve at compile time rather than surviving silently. I ran
  that check by grep rather than by compiler, and it is exactly what surfaced
  the block documented above: sweeping for rain-math-binary-0.1.1 across
  dependencies/ found the two live rain-interpreter-interface-0.1.0 src/
  imports that this bump strands. A green compile is therefore not achievable
  from this diff alone.
• Oracle: the published Soldeer registry, not this repo. forge soldeer update
  resolved 0.1.3 independently and wrote the url, checksum and integrity into
  soldeer.lock; I did not hand-edit any of those three values. The claim that
  the upstream delta is comment-only comes from the library source, not from
  anything in this diff. The block was confirmed by reading the dependency
  source on disk at the two line numbers cited above.
• Category check: the ask is bump rain-math-binary 0.1.1 -> 0.1.3 and move
  every place the version-suffixed remapping names it; covered foundry.toml,
  remappings.txt, soldeer.lock, and all three .sol imports, verified by a
  whole-tree grep returning zero rain-math-binary-0.1.1 hits in tracked files.
  Deliberately not covered: occurrences inside gitignored dependencies/, which
  are published upstream artifacts and are the subject of the block, not
  something to edit; and the pre-existing stale rain-deploy-0.1.2 /
  rain-extrospection-0.1.0 remapping lines, which are out of scope for this
  bump and are left exactly as found.

Verification of this change is delegated to CI. I did not run the test suite
locally for this diff, and I am not claiming a local green. CI is expected to be
RED, for the upstream reason stated in the BLOCKED section above — not for a
defect in this diff.

What I actually ran locally:

• nix develop -c forge soldeer install — exit 0. Used only to populate
  dependencies/ before the bump.
• nix develop -c forge soldeer update — exit 0. Output: Updated lockfile,
  Updated remappings, Done updating!. This regenerated soldeer.lock to
  0.1.3 (new url 0_1_3_19-07-2026_19:05:36_rain.math.zip, new checksum and
  integrity). There is no foundry.lock in this repo, so soldeer.lock is the
  only lockfile in the diff. Note that soldeer update appends a remapping
  rather than replacing one — it left both the 0.1.1 and 0.1.3 lines in
  remappings.txt, and I deleted the stale 0.1.1 line by hand so exactly one
  rain-math-binary remapping remains.
• git commit ran the repo's installed pre-commit hooks: taplo Passed,
  no-consumer-prettier Passed, all other hooks skipped (no matching files).
• Grep sweeps over the tree, which are the only correctness claims I am making
  directly: zero occurrences of rain-math-binary-0.1.1 remain in tracked
  files — sources, tests, config, lockfile, docs, scripts and .github/
  workflows all clean; and the surviving occurrences under gitignored
  dependencies/ are the upstream ones documented in the BLOCKED section.

What I did NOT run, and which CI is expected to cover:

• forge build / forge test (rainix-sol-test). A baseline run on unmodified
  main was started but was deliberately killed before producing a result, so I
  have no baseline pass/fail counts and cannot distinguish pre-existing red
  from anything this diff might introduce.
• slither ., forge fmt --check, rainix-sol-single-contract
  (rainix-sol-static).
• copy-artifacts regeneration. Because the upstream delta is comments-only,
  and this repo sets bytecode_hash = "none" with cbor_metadata = false, the
  compiled bytecode should be unchanged once the block clears, so the committed
  src/generated/*.pointers.sol and meta/ artifacts should still be current.
• .gas-snapshot was not regenerated. No CI job in rainix-sol or
  copy-artifacts checks it, so it should not gate this PR.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: c828ade9-9def-415b-b1e2-9eddc7bd7cd3

📥 Commits

Reviewing files that changed from the base of the PR and between a6b7ad7 and f486aa3.

⛔ Files ignored due to path filters (1)

• soldeer.lock is excluded by !**/*.lock

📒 Files selected for processing (5)

• foundry.toml
• remappings.txt
• src/lib/op/bitwise/LibOpBitwiseCountOnes.sol
• test/src/lib/op/bitwise/LibOpBitwiseCountOnes.t.sol
• test/src/lib/parse/LibParseState.constantValueBloom.t.sol

---

📝 Walkthrough

Walkthrough

The PR updates all listed rain-math-binary and LibCtPop references from version 0.1.1 to 0.1.3 in Foundry configuration, remappings, production code, and tests.

Changes

Dependency upgrade

Layer / File(s)	Summary
Update dependency references foundry.toml, remappings.txt, src/lib/op/bitwise/LibOpBitwiseCountOnes.sol, test/src/lib/op/bitwise/LibOpBitwiseCountOnes.t.sol, test/src/lib/parse/LibParseState.constantValueBloom.t.sol	The configuration, production import, and test imports now reference rain-math-binary version 0.1.3.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Mergeability Score: ⚪ Minimal · up to f486a

This is a localized dependency-version and import-path update with lockfile regeneration and no stated behavior change. Dependency resolution succeeded and stale version references were removed; no actionable merge-blocking risk remains beyond normal CI checks.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the primary change: updating the rain-math-binary dependency from version 0.1.1 to 0.1.3.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch bump-rain-math-binary-0.1.3

---

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.}

[thedavidmeister]

🤖 ai:producer
Design-question: The rain-math-binary 0.1.1 -> 0.1.3 bump cannot be landed by any change to this PR, and a human should decide whether it is worth landing at all. Mechanism: foundry.toml sets recursive_deps = false, so this repo's remappings must satisfy version-suffixed imports hardcoded inside its dependencies, and rain-interpreter-interface hardcodes 'rain-math-binary-0.1.1/src/lib/LibCtPop.sol'. The newest published interface (0.1.2, published 2026-06-15) still hardcodes 0.1.1 and cannot do otherwise, since rain-math-binary 0.1.2/0.1.3 were published 2026-07-17/19. Soldeer keys dependencies by package name, so both versions cannot be installed at once. Landing this therefore needs a 3-deep release cascade: rainlang.interface publishes a new rain-interpreter-interface against 0.1.3, then this PR bumps the interface too, then rainlang republishes for any consumer pinning it. Cost/benefit that should drive the ruling: a recursive diff of the published 0.1.1 and 0.1.3 packages shows the entire delta is documentation - README.md, REUSE.toml, a new .audit/ dir, and three NatSpec tag additions in LibCtPop.sol. No Solidity source behaviour differs and bytecode impact is nil. So the cascade is three levels of releases across seven PRs (this one plus rain.pyth#32, rain.merkle#16, rain.flare#205, rain.erc4626.words#261, raindex#2831, rain.dia#66) to land comments. Question: sequence the cascade, or close the cluster?

[thedavidmeister]

👤 human
Ruled f486aa3: design — Ruled: sequence the cascade. Misrouted as a design question — nothing here needs permission. A dependency upgrade behind a version-suffixed interface is routine producer work, and each step is an ordinary PR whose merge is human-gated like any other.

[thedavidmeister]

Rework note @f486aa33107f8dd515318a252c604778bde18ba8: Work the upgrade through in dependency order. Do not close the cluster and do not re-flag for a cost ruling: the payload being documentation does not change that the versions have to move, and the same cascade is owed on the next release whether or not this one lands.

Order: 1) rainlang.interface — bump rain-math-binary to 0.1.3 there and open the PR; merging publishes a new rain-interpreter-interface via autopublish. 2) This PR — add a follow-up commit bumping rain-interpreter-interface to that new version, moving its version-suffixed remapping and imports exactly as this diff moves rain-math-binary's. CI goes green at that point, not before. 3) rainlang republishes on merge for its own consumers. 4) The six siblings — rain.pyth#32, rain.merkle#16, rain.flare#205, rain.erc4626.words#261, raindex#2831, rain.dia#66 — take the new versions in turn.

Each step is one PR. Where a step is blocked on a publish that has not happened yet, that is ai:blocked-on with the typed --blocked-by ref, not a design question.

Keep the version-suffixed import form throughout; do not introduce an unversioned alias or collapse a suffix to route around the flat dependency set. recursive_deps = false is what makes this repo's own remappings responsible for satisfying its dependencies' hardcoded imports, and that is the constraint the sequence exists to respect.