Nimony

The road to Nim 3

nifpools

nimony/src/lib/nifpools.nim

nifpools — nifcore plus the process-global literal/tag pools and the NifLineInfo bridge that nimsem/hexer are architected around. This is the module the frontend imports (usually via nifprelude); lengc-style code that manages its own pools imports nifcore/nifcoreparse directly. The Nim compiler's IC modules use the classic surface in nifstreams.nim instead.

Two model bridges do the real work:

1. Global pool. The frontend is architected around ONE global pool (every intern table) + globalTags + lineMan; nifcore scopes pools per-TokenBuf. We bridge by threading the globals through every createTokenBuf, so ids are comparable across buffers. nifcore's Pool.strings/syms/filenames are plain BiTable[_,string]s, so pool.strings[id] is direct field access; symbols go through the sym* accessors in nifcore (#2457).

2. Line info. The frontend speaks nifcore's NifLineInfo struct directly: .info reads decode the token's LineInfoLit suffix, the info-carrying builders re-attach it via appendLineInfo. The classic PackedLineInfo/lineMan bridge is gone from the frontend; it survives only in nifstreams.nim for the frozen Nim-compiler side. NoLineInfo is kept as the frontend's name for NoNifLineInfo.

Inline literals need no bridge: nifcore stores int/uint/float inline and code reads intVal/uintVal/floatVal directly.

The rest of the module is real API on top of nifcore: info-carrying builders (addParLe/buildTree/copyInto/add*Lit), safe node predicates (isTagLit & friends), raw-token accessors for the CF listing (int28Token/getInt28, symId/strId/tagId on NifToken), skip intents for the pass validator, and parse/render entry points.