foundry.toml's bare [package] warns on every forge invocation, and forge's suggested fix makes it worse #335

foundry.toml opens with a bare [package] section, which forge reads as an
unrecognised profile. Every forge invocation — every test run, every
forge fmt, every CI step — prints:

Warning: Found unknown config section in foundry.toml: [package]
This notation for profiles has been deprecated and may result in the profile not being registered in future versions.
Please use [profile.package] instead or run `forge config --fix`.

In this repo the section is:

[package]
name = "rain-vats"
version = "0.2.0"

version here is the next, unpublished Soldeer version: this repo calls
rainix's rainix-autopublish.yaml, which publishes that version on a content
change and then rewrites the line to the next slot. So the section is both read
and written by the release, and nothing may disturb the version line itself.

Do not run forge config --fix

It renames the section to [profile.package], and that is worse rather than
better: name and version are not foundry profile keys, so one warning
becomes two — Found unknown 'name' config for profile 'package' and the same
for version. Measured on a copy in rain.sol.codegen.

The fix, and it is foundry's own mechanism

[external] and anything under it is exempt from the unknown-section warning
and from forge config --fix. Foundry added it for exactly this case
(foundry-rs/foundry#5866, "require unknown sections be prefixed with
external."; #12723 excluded it from the fixer). It is not in
STANDALONE_SECTIONS, so foundry never merges it into a profile — it is ignored
outright.

-[package]
+[external.package]
 name = "..."
 version = "..."

Keep the version line unindented and first in the section (see the
coordination note below), and add a comment saying the section is another tool's
metadata rather than foundry config. Fix any prose that names [package].version
in the same pass — READMEs commonly do.

Three things that are NOT true, so nobody re-derives them

All measured while fixing this in rain.sol.codegen:

• [package] is not soldeer's manifest. soldeer-core 0.10.1 — the version
  forge 1.7.2-nightly links — contains the string package zero times in
  src/config.rs. It selects foundry.toml because of [dependencies], and
  forge soldeer push takes name~version on the command line.
• [profile.package] would not have broken publishing either. rainix's
  rainix-static/src/soldeer_gate.rs reads the version with
  read_local_version, which walks lines and returns the first one whose
  strip_prefix("version") is followed by =. No section awareness anywhere.
  The autopublish bump sed anchors the same way.
• There is nothing to raise upstream. Foundry already shipped the mechanism.

One coordination note

rainix-static has no TOML dependency at all — serde_json, sha2, zip —
which is why the version read is a line scan. If that is ever hardened into a
real TOML read, it must be pointed at external.package.version rather than
package.version. A TOML parser addresses the nested path as easily as the flat
one, so this is sequencing, not a capability gap: rename first, then teach the
gate. Getting the order wrong fails loudly via fail(...), never a bad publish.

Scope

29 repos carry this, one issue each. rainlanguage/rain.sol.codegen is the
worked precedent — issue
rainlanguage/rain.sol.codegen#114, fixed by
rainlanguage/rain.sol.codegen#143 (+9/−3, two files,
CI green, CodeRabbit reviewed with no findings). Read that PR before starting;
this issue is the same change in this repo.

Verification there, worth repeating here: run rainix's soldeer-gate before and
after with only foundry.toml changed and confirm the published version, the
next version and the content hash are byte-identical, and that forge config is
silent afterwards.