Remove the submodule-era residue — dead `foundry.lock`, `.gitmodules` and `lib/` references in a repo with no submodules

[thedavidmeister]

What foundry.lock is

foundry.lock is Foundry's git submodule lockfile. It records the commit each dependency vendored under lib/ is pinned to, so forge install / forge update can restore identical submodule revisions. It is only meaningful in a repo that vendors dependencies as git submodules.

Why it is dead in this repo

There is no .gitmodules and no lib/ directory on main, and git ls-files --stage on a fresh clone reports zero gitlinks (mode 160000). Dependencies come from soldeer: foundry.toml sets libs = ['dependencies'], and soldeer.lock is the live lockfile for the one package that lands under dependencies/:

• forge-std 1.16.1

foundry.lock meanwhile still carries 1 submodule pin, for a lib/ path that does not exist in the tree:

{
 "lib/forge-std": {
 "rev": "1801b0541f4fda118a10798fd3486bb7051c5dd6"
 }
}

The two contradict each other. 1801b0541f4fda118a10798fd3486bb7051c5dd6 is the v1.14.0 tag of forge-std; the build actually uses 1.16.1, per both foundry.toml [dependencies] and soldeer.lock. Nothing reconciles them, because nothing reads the foundry.lock side.

Submodules also cannot come back: rainix CI runs a no-submodules check that fails on a root .gitmodules or any committed gitlink, so there is no future in which this pin becomes live again.

It is not silent

forge build emits one warning per entry in this file — verified on a fresh clone of main in the pinned rainix#sol-shell (forge 1.7.2-nightly, 43923a4):

Warning: Dependency 'lib/forge-std' not found at expected path

Everything dangling in this repo

foundry.lock is not the only thing the submodule → soldeer migration left behind. Every reference below names a path that does not exist on main. All of it is one removal, not separate work.

The dead lockfile and its references

• foundry.lock — the file itself
• REUSE.toml line 19 — "foundry.lock", in the annotation path list
• .soldeerignore line 16 — /foundry.lock

Submodule paths that no longer exist

• REUSE.toml line 9 — ".gitmodules",. There is no .gitmodules in the tree and no gitlinks.
• .soldeerignore line 6 — .gitmodules, same absent file.
• .soldeerignore line 18 — /lib. There is no lib/ directory. foundry.toml sets libs = ['dependencies'], so forge resolves everything under dependencies/ and never creates lib/.

None of these can come back, for the no-submodules reason above.

Other dangling references found while checking

• .soldeerignore line 23 — /target. This repo has no Rust: no Cargo.toml, no crates/, and target is not in .gitignore. Nothing here produces a target/.

Deliberately not in scope. .soldeerignore also names .DS_Store, .vscode, .pre-commit-config.yaml and the build/publish outputs (/out, /cache, /dependencies, /docs). Those are absent from a clean checkout by design — OS junk, local developer files, or artifacts generated at forge soldeer install / forge build / devShell-entry time and therefore present when soldeer push runs. They are correct ignores and must stay. REUSE.toml line 5's ".audit/**" is live — .audit/scope.json is tracked and both files it names (src/lib/LibCtPop.sol, test/src/lib/LibCtPop.ctpop.t.sol) exist.

Nothing else references any of it. .github/workflows/, flake.nix, foundry.toml, remappings.txt, .gitignore, audit/, test/, slither.config.json and README.md were grepped and are clean. There is no CLAUDE.md, so there is no stale prose describing lib/ submodules to fix here.

No single one of these references blocks its own deletion — reuse lint (the rainix-sol legal job) tolerates annotation paths that do not exist, and a .soldeerignore line for a nonexistent path is a no-op. They are listed so this cleanup lands complete instead of repeating the half-finished pass described below.

Context

This is the tail of an unfinished migration, not a convention.

Pass 1 of this sweep covered the 17 repos that consume rain.solmem via soldeer. Every one of them carried residue, and each now has its own issue. This is pass 2: a further 17 rainlanguage repos with the same dangling entries — rain.deploy, rain.sol.codegen, rain.factory, rainix, rain.factory.deploy, rain.vats, rain.math.saturating, rain.math.binary, rain.pyth, rain.vats.flare, rain.sol.binmaskflag, rain.math.fixedpoint, rain.metadata, rain.verify.interface, rain.lib.typecast, rain.lib.hash, raindex.interface — of which ten still carry a dead foundry.lock: rain.deploy, rain.sol.codegen, rain.math.saturating, rain.math.binary, rain.sol.binmaskflag, rain.math.fixedpoint, rain.metadata, rain.lib.typecast, rain.lib.hash, raindex.interface. This issue covers rain.math.binary only.

Deleting the file was never the whole job. The references outlive it silently, because not one of them fails anything.

rainlanguage/flow and rainlanguage/rain.tier.interface genuinely still use git submodules — live gitlinks, verified — so their .gitmodules and lib/ entries are correct and must be left alone.

This is configuration only. No Solidity source, no deployed bytecode and no audited artifact changes.

Done when

• foundry.lock deleted
• REUSE.toml lines 9 and 19 removed
• .soldeerignore lines 6, 16, 18 and 23 removed
• forge build no longer emits Dependency '...' not found at expected path
• no reference to .gitmodules, lib/ or foundry.lock remains anywhere in the tree outside dependencies/
• CI green (rainix-sol test / static / legal)