You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
expt-convert: global_symbols.relationships and .signature are declared but never populated #464
scip expt-convert declares global_symbols.signature and global_symbols.relationships in its SQLite schema, but insertGlobalSymbols() never writes either column. Both are NULL for every row in every generated database.
This is silently lossy: the resulting database is schema-valid and every query against it succeeds, so a consumer reading relationships gets an empty result that is indistinguishable from "this symbol genuinely has no relationships."
Evidence (cmd/scip/convert.go, main)
The schema declares both columns:
// cmd/scip/convert.go:192-201`CREATE TABLE global_symbols ( id INTEGER PRIMARY KEY, symbol TEXT NOT NULL UNIQUE, display_name TEXT, kind INTEGER, documentation TEXT, signature BLOB, // line 198 — never written enclosing_symbol TEXT, relationships BLOB // line 200 — never written);`
But insertGlobalSymbols() (line 423) inserts only five columns:
There are exactly five insertStmt.Bind* calls in that function, and no reference to symbol.Relationships or symbol.Signature anywhere in the file — even though both are present on scip.SymbolInformation.
Reproduction
scip expt-convert --output index.db index.scip
sqlite3 index.db "SELECT COUNT(*) FROM global_symbols WHERE relationships IS NOT NULL;"# 0
sqlite3 index.db "SELECT COUNT(*) FROM global_symbols WHERE signature IS NOT NULL;"# 0
Both return 0 regardless of the input index, including for indexes whose .scip demonstrably contains relationship data (verifiable with scip print).
Impact
relationships is the only source for implementation/type-definition edges, so any type-hierarchy feature ("go to supertype", "find implementations") built on the SQLite output cannot work at all. Because the column exists and queries succeed, the failure looks like absent data rather than an unimplemented code path — which makes it easy to misattribute to the language indexer that produced the .scip.
Suggested fix
Extend the INSERT in insertGlobalSymbols() to bind symbol.Relationships (serialized consistently with how chunks.occurrences frames its blob) and symbol.Signature. Alternatively, if these columns are intentionally deferred, dropping them from the CREATE TABLE would make the omission explicit rather than silent.
Left signature out deliberately: the column is named signature, but SymbolInformation has no such field — the nearest is Signature signature_documentation = 7. That mapping seems like a maintainer call rather than something to guess at. Happy to fold it in given a preference.
Activity
docs: link upstream issue scip-code/scip#464 in the plan
fix: populate global_symbols.relationships in expt-convert
phuongddx commentedon Jul 26, 2026
Opened #465 for the
relationshipshalf.Left
signatureout deliberately: the column is namedsignature, butSymbolInformationhas no such field — the nearest isSignature signature_documentation = 7. That mapping seems like a maintainer call rather than something to guess at. Happy to fold it in given a preference.