Delete the "load-bearing" filler

[thedavidmeister]

Removes the banned load-bearing filler from this repo's committed source.

The phrase rates a finding instead of stating one, and the reader can do the rating.
Where the surrounding sentence already named the consequence, the phrase is simply
deleted; otherwise it is replaced by the consequence it was standing in for. No
substitute rating word ("crucial", "key", "critical", "the crux", "significant",
"notably") was introduced anywhere in the diff.

Closes nothing — no issue exists for this. Part of an org-wide sweep; one PR per
affected repo. GitHub code search finds only some of the forms, so the sweep was run
against fresh clones of all 151 org repos, matching load[-_ ]?bearing case-insensitively
plus a check for the phrase wrapped across two comment lines.

Occurrences removed

File	Count
test/src/lib/implementation/LibDecimalFloatImplementation.internals.t.sol	1

QA

• Discriminating tests: n/a — nothing in the diff changes behaviour, so there is no
  behaviour for a test to discriminate.
• Mutations applied: n/a — the diff is comments and prose only. mutation-probe mutates
  source lines and asks whether the suite kills them; this diff changes no source line,
  so every mutant it could generate is a mutant of code this PR did not touch.
• Oracle: the code each comment describes. Every rewrite states the consequence the
  phrase was gesturing at, read off the surrounding implementation rather than invented.
• Category check: the request is "remove every occurrence from committed source";
  this repo's occurrences are all removed and a re-grep over the branch finds none.

Summary by CodeRabbit

• Documentation
  • Clarified the decimal floating-point exponent boundary, including the valid -80 case and the overflow behavior at -81.

[coderabbitai]

Warning

Review limit reached

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

Next review available in:57 minutes

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.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: f61e0bf5-b3d8-42cd-a476-675fd1294409

📥 Commits

Reviewing files that changed from the base of the PR and between dfebe17 and 246a22a.

📒 Files selected for processing (1)

• test/src/lib/implementation/LibDecimalFloatImplementation.internals.t.sol

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: e4eb2dc2-4f85-4846-9bf1-d804c6609223

📥 Commits

Reviewing files that changed from the base of the PR and between d3fb611 and dfebe17.

📒 Files selected for processing (1)

• test/src/lib/implementation/LibDecimalFloatImplementation.internals.t.sol

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

Walkthrough

The change clarifies test comments for the mantissa4 exponent boundary. It documents that exponent -80 uses 10^76, while exponent -81 would overflow when computing 10^77. No executable behavior changed.

Changes

Mantissa4 boundary clarification

Layer / File(s)	Summary
Clarify exponent boundary test/src/lib/implementation/LibDecimalFloatImplementation.internals.t.sol	Updated comments to describe the exponent < -80 boundary and the int256 overflow at exponent -81.

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

Merge Risk:⚪ Minimal · up to dfebe

This localized comment-only cleanup removes the banned phrase without changing code behavior, configuration, or runtime outcomes; no actionable merge-blocking risk remains.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the removal of the banned phrase from the comment.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.)
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.

✨ 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 chore/drop-filler-phrase

---

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]

The four red checks here are pre-existing on main, not caused by this diff

This PR changes one doc comment in
test/src/lib/implementation/LibDecimalFloatImplementation.internals.t.sol. To
show the failures are not its doing, I pushed the unmodified base commit
(d3fb611, current origin/main) to a scratch branch so the identical
workflows ran against it today, on the same @main shared rainix workflows.

Job for job, the base and this PR produce the same result:

Job	unmodified main	this PR
copy-artifacts / copy-artifacts	failure	fail
rainix-sol / static / static	failure	fail
rainix-sol / test / test	failure	fail
rs-static / rs-static	failure	fail
rainix-sol / legal / legal	success	pass
rs-test / rs-test (macos-latest)	success	pass
rs-test / rs-test (ubuntu-latest)	success	pass
rs-wasm / rs-wasm	success	pass

Baseline runs on the unmodified commit:

• copy-artifacts — https://github.com/rainlanguage/rain.math.float/actions/runs/32499299507
• rainix-rs-static — https://github.com/rainlanguage/rain.math.float/actions/runs/32499299395
• rainix-sol — https://github.com/rainlanguage/rain.math.float/actions/runs/32499299642
• rainix-rs-test (green) — https://github.com/rainlanguage/rain.math.float/actions/runs/32499299359
• rainix-rs-wasm (green) — https://github.com/rainlanguage/rain.math.float/actions/runs/32499299382

The causes, none of which this diff touches:

• rs-static — the no-ignored-tests gate reports
  ./test/src/lib/deploy/LibDecimalFloatDeployTaggedConstants.t.sol:24: vm.skip(true).
• copy-artifacts — src/generated/ is committed but script/Build.sol was not found, so the committed sources cannot be currency checked here.
• rainix-sol static and test fail on the same repo state.

rainix-rs-static and rainix-sol have also been red on main in every run
back to at least 2026-07-14, so this is a standing condition rather than
something that started today. Fixing it is separate work and does not belong in
a prose sweep; flagging it here so it is on the record.

The scratch branch has been deleted; the run records above outlive it.