Uh oh!
There was an error while loading. Please reload this page.
filePrefix stops explaining why the file is committed - #34
Conversation
The four lines about a circular dependency between a contract and its generated file are gone. What remains — SPDX, pragma, AUTOGENERATED ... DO NOT EDIT BY HAND — is true of every generated file in every repo. Generated files are committed. That is a fact about the repo, not a case each file argues to its reader. And the explanation was only ever true of pointers files: an alias lib is committed because it IS the source consumers import, not to break a compile cycle. So filePrefix was unusable for those writers, and the workaround was each of them hand-rolling SPDX and pragma with its own REUSE-Ignore dance — restating this library rather than calling it. Deleting beats parameterising: nothing left in the prefix varies by caller, so there is nothing to pass and every writer can use it. Changes generated output for every consumer — five deleted comment lines per file, no constant touched. All of them pin 0.1.0, which predates the current text anyway, so none regenerates against this until it separately bumps. testFilePrefixExact pins the prefix byte for byte and is updated here; it exists so this lands as a reviewable diff rather than a surprise on someone's next regeneration. This repo's own generated file is regenerated in the same commit.
Warning Review limit reached
Next review available in:43 minutes 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 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 configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
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 |
thedavidmeister
commented
Aug 13, 2026
Reviewed 0308aee: APPROVE — 14 deletions, 2 additions, where both additions are the same surviving line losing the trailing blank that belonged to the deleted paragraph. Diff read in full; I wrote the last commit on this branch myself.
Blast radius, accepted rather than hedged: this changes generated output for every Rulings-conformance:
|
Uh oh!
There was an error while loading. Please reload this page.
…efix rainlanguage/rain.sol.codegen#34 deleted the paragraph in `filePrefix` that explained a generated file is committed because of a circular dependency between a contract and its generated file. That paragraph is why `writeAliasLib` hand-rolled its own header: the claim is true of a snapshot and false of an alias lib, which is committed because it IS the stable source consumers import, so emitting it would have put a false statement into generated output. 0.1.6 is the release carrying that deletion, and with it gone there is nothing left in the prefix that varies by caller. So the hand-rolled SPDX, pragma and AUTOGENERATED lines go, the comment defending them goes, and the `REUSE-Ignore` block that existed only because the SPDX lines were written out by hand goes with it — `reuse lint` is clean without it, 50/50 files. The emitted bytes do not move: `src/lib/LibAddressRegistryDeploy.sol` regenerates byte for byte identical, which is the check that the prefix and the hand-rolled header were the same string. `src/generated/candidate/ AddressRegistry.sol` loses the five deleted comment lines and nothing else — `BYTECODE_HASH`, `DEPLOYED_ADDRESS`, `CREATION_CODE` and `RUNTIME_CODE` are unchanged, so no address or code hash moves and no consumer's pins change. `forge soldeer update` rather than `install`, and the versioned import prefixes in `LibRainDeploySnapshot` move `0.1.4` -> `0.1.6` with the stale remapping and dependency directory dropped. `LibSnapshot.sol` is absent from 0.1.6, which is correct: it moved into this repo as `LibRainDeploySnapshot` in 589686c. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
filePrefix()emits SPDX, pragma, anAUTOGENERATED … DO NOT EDIT BY HANDmarker, and then four lines explaining that the file is committed because of a
circular dependency between a contract and its generated file.
Those four lines go. What remains is true of every generated file in every repo.
Why
We do not need generated files to argue why they are committed. They are
committed — that is a fact about the repo, not a case each file makes to its
reader.
And the explanation was only ever true of pointers files. It is false of the
other generated files repos write: an alias lib like
LibCloneFactoryDeployiscommitted because it IS the source consumers import, not to break a compile
cycle. So
filePrefixwas unusable for those writers, and the workaround waseach of them hand-rolling SPDX and pragma lines with their own
REUSE-Ignoredance — restating the shared library rather than calling it.
Deleting the paragraph is strictly better than parameterising it. Nothing left
in the prefix varies by caller, so there is nothing to pass, and every writer
can use it.
Blast radius
This changes generated output for every consumer of
filePrefix. Eachrepo's committed generated files will differ from what a fresh build produces
until that repo regenerates.
Affected, all verified by reading their build scripts rather than code search
(which under-reports here):
rainlanguage/rain.interpreter—script/Build.solrainlanguage/rain.orderbook—script/Build.solrainlanguage/rain.math.float—script/BuildPointers.solrainlanguage/rain.factory.deploy—script/BuildPointers.solrainlanguage/rain.deploy—script/Build.solS01-Issuer/st0x.deploy—script/BuildPointers.solscript/Build.sol, regenerated in this PRThe fix in each is mechanical: run the build script, commit the diff. Five
deleted comment lines per generated file.
Nothing here is a deployed pin or a published revision. The constants those
files carry — addresses, code hashes, bytecode — are untouched; only a comment
block above them changes. No consumer's imports move and no address changes.
These repos all pin
rain-sol-codegenat0.1.0, which predates the currentfilePrefixtext anyway, so none of them regenerates against this until itseparately bumps. There is no window in which a repo is broken by this and has
not chosen to move.
Sequencing
rainlanguage/rain.deploy#26blocks on this. It needsLibRainDeploySnapshot.writeAliasLibto stop hand-rolling SPDX, pragma and theautogenerated marker — a header this library owns — and it cannot until a
version exists carrying the fixed
filePrefix. So: this merges, autopublishes,#26 bumps to that version and deletes its local header and the
REUSE-Ignoreblock that only exists because the header was hand-rolled.
#26 ships complete or not at all; it is not being split around this.
QA
testFilePrefixExactpins the prefix byte for byte andis updated in this PR — it exists precisely so a change here lands as a
reviewable diff rather than a surprise on someone's next regeneration, and it
fails on the pre-change string.
testFilePrefixNamesNoScriptstill passes,unchanged. Full suite: 9 tests, 4 suites, all pass;
forge fmt --checkclean.surviving string is pinned character for character by
testFilePrefixExact,which is a stronger constraint than a mutation would probe. Verified the test
is discriminating by the fact that it required updating: leaving it untouched
fails against the new prefix.
("circular dependency between the contract and its generated file") that is
checkable against what consumers actually generate — true for pointers files,
false for alias libs such as
rain.factory.deploy'sLibCloneFactoryDeploy,which imports a generated file and is imported by consumers. That divergence
is what makes the text wrong rather than merely verbose.
filePrefixclaiming why a file iscommitted", and the category is every line making that claim — all four, plus
the doc comment describing them, plus this repo's own regenerated output.
Verified by grep: no "committed to the repository" or "circular dependency"
string survives in
src/.