expt-convert: global_symbols.relationships and .signature are declared but never populated

[phuongddx]

Summary

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:

// cmd/scip/convert.go:427-428
`INSERT INTO global_symbols (symbol, display_name, kind, documentation, enclosing_symbol)
VALUES (?, ?, ?, ?, ?)

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.

Environment

• scip v0.9.0 (latest release) and current main
• Present since the SQLite converter was introduced in 0c0c2b8 (feat: Add conversion to SQLite (experimental) #319)

[phuongddx]

Opened #465 for the relationships half.

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.