Tracked by: #134, #163, #164 Discovered while validating #329.
Problem
The Home/Bun private ABI scanner recognizes extern fn but not the equally valid explicit extern "c" fn spelling. As a result, pinned consumer declarations such as Bun__JSValue__deserialize are absent from both inventories, while the C-export classifier correctly rejects the implementation as unclassified. CI also does not currently run the aggregate c-api-audit, so the drift escaped the #323 acceptance matrix.
Scope
- Teach the comment/string-aware scanner to parse explicit C linkage without weakening declaration boundaries.
- Add scanner self-tests for
extern fn,extern "c" fn, comments/strings, multiline declarations, and non-C link names. - Regenerate the pinned Home and Bun inventories from their exact source revisions.
- Keep
Bun__JSValue__deserializeclassified as a real private consumer declaration, not an exception whitelist. - Add the aggregate C-API/private-export audit to CI if it is not already covered by an equivalent gate.
- Refresh ABI counts and documentation.
Acceptance
- Both inventories contain the exact deserialize declaration and digest from their pinned sources.
zig build c-api-audit, Home/Bun private audits, and scanner self-tests pass.- CI prevents future exported-but-uninventoried ABI symbols.