test: pin pow round-trip second-leg revert#233
Conversation
Add a dedicated concrete test `testRoundTripSecondLegRevert` next to `testRoundTripFuzzPow` that constructs the exact counterexample surfaced by fuzzing (a = bytes32(1), b = 0xea5a...9e13). It asserts the first leg `a.pow(b)` succeeds and the round-trip leg `c.pow(b.inv())` reverts with the exact `WithTargetExponentOverflow(...)` selector and args. The fuzz test absorbs this revert in a try/catch as "can't round-trip this input". This named test pins which leg reverts and with which error so a regression that shifts the revert boundary surfaces in a named test instead of being silently swallowed by the fuzz catch. Fixes #209 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 24 minutes and 39 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
Reviewed fd88461: pin the pow round-trip second-leg ExponentOverflow revert with an exact counterexample; mutation-validated discriminating test (not enshrining). All checks green. LGTM. |
|
@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:
Review Effort: Would have taken 5-10 minutes Examples:
Medium (M)Characteristics:
Review Effort: Would have taken 15-30 minutes Examples:
Large (L)Characteristics:
Review Effort: Would have taken 45+ minutes Examples:
Additional Factors to ConsiderWhen deciding between sizes, also consider:
Notes:
|
Summary
Adds a dedicated concrete test
testRoundTripSecondLegRevertnext totestRoundTripFuzzPowintest/src/lib/LibDecimalFloat.pow.t.sol, pinning the pow round-trip second-leg revert path that the fuzz test currently absorbs in a try/catch.The test constructs the exact counterexample surfaced by fuzzing:
a = bytes32(1),b = bytes32(0xea5a58dfdcc79c60ac38b8284569e4519fda5eaaffec2a3d22027a4af1969e13)and asserts:
a.pow(b)succeeds.c.pow(b.inv())reverts with the exactWithTargetExponentOverflow(2696051936649033486196409040598252262955326698850935392994226984449, 363177628, 0)selector and args.Why
A tiny coefficient combined with the large inverted exponent produces an unrepresentable rescale target during the round-trip. The fuzz test treats this as "can't round-trip this input" and silently catches it. This named test pins exactly which leg reverts and with which error, so a regression that shifts the revert boundary (which inputs revert vs round-trip cleanly) surfaces in a named test instead of being absorbed by the fuzz catch.
Verification
forge test --mt testRoundTripSecondLegRevert→ PASS (the asserted error selector and args match the live revert exactly).test/src/lib/LibDecimalFloat.pow.t.solsuite → 9 passed, includingtestRoundTripFuzzPow(5096 runs).forge test→ 452 passed; the only 5 failures are the pre-existingtestProdDeployment*fork tests that require live RPC env vars (ARBITRUM_RPC_URLetc.) not set in the local sandbox — unrelated to this change (which is test-only and touches no source).Fixes #209
🤖 Generated with Claude Code