Skip to content

Latest commit

 

History

History
32 lines (21 loc) · 1.75 KB

File metadata and controls

32 lines (21 loc) · 1.75 KB

Cross-File Resolution

After parsing, many call edges, type relations, and references contain unresolved names (just the text from the source code). The resolution pipeline matches these to actual symbol IDs in the database.

Resolution Order

A 6-step first-match-wins algorithm:

  1. Explicit imports — the file imports the exact qualified name
  2. Wildcard imports — the file has a wildcard import matching the name's package
  3. Same package — the target symbol is in the same package as the calling file
  4. Qualified name — the name matches a symbol's full qualified name directly
  5. Unique name — only one symbol with that unqualified name exists in the index
  6. Pending — no match found; stored in pending_resolution for retry after more files are indexed

When Resolution Runs

  • Initial index: resolution is deferred until all files are parsed, then runs once globally
  • Incremental update: after a file is re-parsed, resolution runs for that file's edges, then re-resolves any pending entries that might now match
  • Bulk mode (--bulk): resolution runs as SQL batch operations across all files at once

Re-Resolution

When new files are added or existing files change:

  1. re_resolve() retries all pending_resolution entries
  2. re_resolve_imports() fixes unresolved import edges
  3. Dependent files (those with edges pointing into changed symbols) are marked stale and re-indexed (up to depth 2)

Edge Preservation

Symbol diffing (store/diff.rs) matches existing and new symbols by (qualified_name, kind), disambiguating overloads by arity then parameter types. Matched symbols keep their DB IDs, so cross-file edges from other files survive re-indexing. Only edges from the modified file are wiped and rebuilt.