Problem
The pinned Home and Bun private-JSC inventories currently classify JSFunctionCall from jsc/FFI.zig as a pending zig-js export. That declaration describes the symbol generated into each runtime-compiled FFI module, not a symbol imported from JavaScriptCore or zig-js. The consumer emits the definition, relocates the module, and resolves it with getSymbol("JSFunctionCall").
Counting it as a pending private ABI symbol makes the compatibility gate demand an incorrect duplicate provider and contradicts the Bun inventory boundary, which already excludes generated bindings.
Scope
- Add an explicit consumer-provided/generated classification to the shared private-ABI scanner.
- Classify
JSFunctionCall consistently in the Home and Bun pinned inventories.
- Keep it in the declaration inventory for provenance while excluding it from pending zig-js implementation counts.
- Add regression coverage to prevent exports from overriding this classification.
- Update ABI docs, README counts, and parent issue evidence.
Acceptance criteria
- Home and Bun audits report one fewer pending private import without adding a
JSFunctionCall export.
- The stored declaration remains revision-pinned and digest-checked.
- Documentation explains why this is consumer-provided rather than implemented by zig-js.
- Focused ABI audits pass.
Problem
The pinned Home and Bun private-JSC inventories currently classify
JSFunctionCallfromjsc/FFI.zigas a pending zig-js export. That declaration describes the symbol generated into each runtime-compiled FFI module, not a symbol imported from JavaScriptCore or zig-js. The consumer emits the definition, relocates the module, and resolves it withgetSymbol("JSFunctionCall").Counting it as a pending private ABI symbol makes the compatibility gate demand an incorrect duplicate provider and contradicts the Bun inventory boundary, which already excludes generated bindings.
Scope
JSFunctionCallconsistently in the Home and Bun pinned inventories.Acceptance criteria
JSFunctionCallexport.