Update stacked: cabal 3.18.1.0 + vim 9.2.0818 - #496

build.sh passed --bootstrap-sources ../hadrian-bootstrap-sources-9.8.1.tar.gz
with the version hard-coded, so moving build.ncl to 9.12.2 left this
pointing at a file that no longer gets fetched:

  FileNotFoundError: '/build/hadrian-bootstrap-sources-9.8.1.tar.gz'

That is the THIRD copy of this version in the package — url, sha256, and
this argument — and the third consecutive failure from the same cause:
first the url alone was moved (plan lacked `component`), then the sha256
was left behind (HashMismatch), now the build.sh argument. Each fix
revealed the next copy, one ~50s build at a time.

So this removes the copy rather than updating it. The version lives in
build.ncl's url + sha256, which are already coupled and checksum-verified;
build.sh now globs for whatever was fetched. It fails loudly unless the
glob matches exactly one existing file, so an ambiguous /build can never
silently select the wrong bootstrap plan.

Also verified the remaining build.sh patches against the real 9.14.1
source tree rather than waiting for the build to find out — all five
guards still match:

  State.hs `import Data.List ( ... sortOn )`      line 114  ✓
  State.hs `let preload1 = nonDetKeysUniqMap ...` line 1682 ✓
  ghc-pkg  `confs = map (path </>) $ filter ...`  line 940  ✓
  ghc-pkg  `import Data.List ( group, sort, ... )` line 78  ✓ (sort in scope)
  hp2ps    `extern void *realloc();`              ABSENT

The hp2ps line is gone in 9.14.1 (fixed upstream), so that `sed -i` is now
a silent no-op — harmless, since it is unguarded, but it can be dropped
once this lands.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

GHC 9.14.1 BUILT — ~111 minutes, clean. The bundle then failed in cabal:

  File "/build/update_bootstrap_json.py", line 7
  FileNotFoundError: 'bootstrap/linux-9.8.2.json'

cabal's bootstrap/ directory ships a fixed set of linux-<ghc>.json plans per
cabal RELEASE; it does not track the GHC we build with. cabal 3.18.1.0 ships
9.6.7 / 9.8.4 / 9.10.3 / 9.12.4 — the 9.8.2 named here existed only in older
cabals, so bumping cabal broke it via a bare FileNotFoundError out of our own
script.

Which plan matters less than it looks: update_bootstrap_json.py REPLACES the
`builtin` list with the real `ghc-pkg list` output, so the compiler-package
half adapts to whatever GHC is on PATH. The base plan supplies the
`dependencies`, so this takes the newest available (9.12.4).

Adds a guard that lists the plans cabal actually ships and says what to do,
because the failure mode is otherwise a Python traceback about a missing file
with no hint that the set is version-dependent. Fourth instance of this exact
shape in this package family today (ghc url, ghc sha256, ghc build.sh arg, now
this): a version hardcoded in one place while the thing it names moved.

Note packages/cabal/build.sh:31-32 still seds `Cabal-syntax ^>= 3.12.1.0`,
pinned to the OLD cabal. At 3.18.1.0 those patterns match nothing, so they are
silent no-ops rather than errors. Left alone deliberately — whether that
constraint relaxation is still needed is a question the build answers, and
changing two things at once would make the answer ambiguous.

GHC is now cached, so re-runs exercise cabal without repaying the ~2h compile.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

With the base plan moved to cabal 3.18.1.0's linux-9.12.4.json, the
bootstrap got further and then failed configuring HTTP-4000.4.1:

  subprocess.CalledProcessError: [.../dists/HTTP-4000.4.1/setup/Setup]
      'configure' ...
  retry: 'bootstrap.py -w /usr/bin/ghc -d bootstrap/linux-actual.json'
      failed after 4 attempts

HTTP-4000.4.1 is not what the plan asks for — it is what WE pinned.

update_bootstrap_json.py carried ~12 hand-pinned versions + Hackage
hashes. They existed because the base plan was linux-9.8.2.json and its
dependencies really were too old for the GHC we build with (the original
comment says exactly that). Against a plan four GHC generations newer,
every one of them inverted into a DOWNGRADE, with stale hashes:

  HTTP              plan 4000.5.0 -> pinned 4000.4.1   <- the failure
  hashable          plan 1.5.1.0  -> pinned 1.4.7.0
  random            plan 1.3.1    -> pinned 1.2.1.2
  tar               plan 0.7.1.0  -> pinned 0.6.3.0
  splitmix          plan 0.1.3.2  -> pinned 0.1.1
  async, zlib, hackage-security   -> all older than the plan

So the version pins are gone. The plan that ships WITH a cabal release is
the set that release was tested against; re-deriving it by hand is how it
drifts, and it drifted silently the moment cabal moved. Anything actually
needed should now fail loudly rather than be pre-empted by a guess.

zlib's FLAGS survive, because they are not a version pin: they select the
system zlib over the copy bundled in the Haskell package, which is a
property of our sandbox rather than of any zlib version. The `builtin`
rewrite from `ghc-pkg list` is untouched — that is what adapts the plan
to whichever GHC is on PATH, and it is why the base plan's GHC version
matters less than its name suggests.

Verified offline against the real linux-9.12.4.json before spending
another ~5 min build: HTTP stays at 4000.5.0, zlib keeps its flags at the
plan's 0.7.1.1, and builtin still rewrites.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

GHC 9.14.1 built cleanly (~111 min) and cabal 3.18.1.0 built after it.
tamarin-prover then could not resolve:

  rejecting: tagged-0.8.10  (lts-pinned.config requires ==0.8.9)
  rejecting: tagged-0.8.9   (conflict: template-haskell==2.24.0.0,
                             tagged => template-haskell >=2.11 && <2.24)

Not a packaging bug — ecosystem timing. tamarin pins Stackage
LTS 24.50, and:

  lts-24.51 (newest LTS)        -> ghc-9.10.3
  nightly-2026-07-21 (today)    -> ghc-9.12.4

NO Stackage snapshot supports GHC 9.14. Building tamarin against it means
hand-resolving aeson/tagged/wai-extra/yesod-static/fclabels ourselves,
i.e. maintaining a bespoke snapshot. Staying on LTS is the right call, and
LTS 24.51 is 9.10.3 — exactly what main already ships.

So ghc and ghc-bootstrap revert to main. The bundle keeps what does not
depend on the new compiler:

  cabal 3.18.1.0  (bootstrap plan retargeted to linux-9.10.3.json,
                   which cabal 3.18.1.0 ships)
  vim   9.2.0818

The cabal dep-pin removal stands: verified against the 9.10.3 plan, our
old hand-pins are still downgrades there (HTTP 4000.5.0 -> 4000.4.1,
hashable 1.5.1.0 -> 1.4.7.0, random 1.3.1 -> 1.2.1.2, tar 0.7.1.0 ->
0.6.3.0, splitmix 0.1.3.2 -> 0.1.1).

Work not wasted, just deferred: the libffi flag, the hadrian
bootstrap-sources glob, and the ghc-bootstrap 9.12.2 pairing are all
recorded in this PR's history and apply unchanged whenever GHC does move.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>