Run the bindings' library tests here, over this source

[thedavidmeister]

The Rust tests that check library logic lived in rain.math.float.deploy's bindings crate, where they ran over the deployed concrete's pinned rain-math-float package, one release behind this source. They now live here in crates/tests (was crates/constants) and run over test/concrete/TestDecimalFloat.sol compiled from this source:

• TestDecimalFloat.sol has the DecimalFloat ABI over src/; its constructor deploys the log tables (LibTestLogTables, now shared with LogTest) into an immutable, where the deployed concrete requires them at their Zoltu address. TestDecimalFloatHarness.sol has the bindings' harness ABI: packing and the LibLogTable getters.
• crates/tests/build.rs runs forge build (and forge soldeer install when dependencies/ is absent) with the Solidity tree watched, so cargo test is self-contained and never runs over a stale artifact. .cargo/config.toml points the bindings at the two artifacts and selects create mode (Let a consumer run the bindings over its own build of the concrete rain.math.float.deploy#21).
• Moved: 48 tests from the bindings crate's lib.rs (arithmetic, comparisons, conversions, errors, constants), the 15 fuzz_ops proptests against f64, and the 9 log-table tests, which now read the tables from the harness instead of from copies pasted into Rust, plus a check that ALT_TABLE_FLAG matches the library's. The 4 tests of the bindings' own Rust API (Default, serde, hex) stay in the deploy crate.
• The bindings are a git dev-dependency on Let a consumer run the bindings over its own build of the concrete rain.math.float.deploy#21's head until that merges and publishes; then it becomes the crates.io version.

Stacked on #274.

QA

• Discriminating tests: cargo test 76 passed (48 float, 15 fuzz_ops, 10 tables, 3 constants); rainix-rs-static clean; the LogTest-based Solidity suites 25 passed after the LibTestLogTables factoring.
• Mutations applied: add in TestDecimalFloat.sol returning b fails 10 tests (test_add_sub, fuzz_add, test_int_frac_properties, test_inv_prod, …); LibTestLogTables.deploy reverting fails 73 of 76 at EVM construction. The tests run over this source through its constructor, not the crate's committed bytecode.
• Oracle: f64 for fuzz_ops and the table generation, integer series for the constants, algebraic identities (add/sub, mul/div, int+frac, trichotomy) for the rest; nothing read from the code under test.
• Category check: no bindings API is added, so no Rust test reaches log10/pow/sqrt/pow10 yet; the tables immutable is set by the constructor but only the Solidity suite reads it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QyCCzi9WZPhuXcU1hwr2bq

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Team

Run ID: bad82cca-75fa-4106-a932-09fe330034af

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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