`moduleId` threw away the index `bif.load` hands it and rebuilt an equivalent
one by walking the module's ENTIRE token stream, allocating a string per
`SymbolDef` — once per module, per backend process. That was 909ms of a 10.1s
cold `--ic:on` build. Taking the carried index instead: 220ms, and the build
drops to 9.4s.
`bif.store` already builds that index in one forward traversal at write time
(`bif.buildIndex`) and writes it into the file, and `bif.load` reads it back
with `pos` already a TOKEN index of the declaration's enclosing tag — the very
thing the rescan recomputed. The comment claiming the file's offsets are
"meaningless once the file is parsed" was true of the older byte-offset
`readEmbeddedIndex`; it stopped being true when `bif` started storing token
positions.
The two agree BY CONSTRUCTION, and the reason is worth stating because "the
file has an index" would not be enough on its own: the writer filters with
`bif.isGlobalSymbol(name, dottedSuffix)`, every `storeBif` call site passes
`"." & extractModuleSuffix(path)` — the same suffix the reader forms — and the
visibility rule is the same test on the same token.
Checked rather than argued, all the same. The old rescan stays as
`rescanPosIndex` behind `-d:icIndexCheck`, which compares the two entry by
entry on every module load: a full build agrees exactly (11220 entries for the
system module alone), and sabotaging the comparison makes it fire, so the clean
run says something.
`ensureSemBuf` had the same rescan for the `.s.bif` companion; it uses the
carried index too.
Verified: both configurations build; `tests/ic` 40/40; 67/67 generated `.c`
byte-identical to before, and cursor still identical to `PNode`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FMyRHByv7hhaQJ4Pa1bHbE
2605cd3213