Just opening for discussion, PR is incoming
Rust seems to need a different implementation strategy than the current clean-room resolvers. For many languages, codebase-memory can reconstruct enough type and import semantics from tree-sitter plus per-language registries. For Rust, that approach is likely to fail on the cases users care about most: macro_rules!, derive/proc macros, build-script generated code, cfg/features, trait dispatch, associated functions, generics, and cross-crate workspace resolution. To avoid false graph edges, I think we should lean on rust-analyzer semantics directly rather than trying to reimplement that machinery in C.
The proposed shape is a small, vendorable Rust library built on pinned ra_ap_* rust-analyzer crates, exposing a stable generic C ABI. The C indexer would continue owning the graph pipeline and mapping, while the Rust library would load a Cargo workspace once, resolve call targets in batches, and return source/target file/range evidence with confidence and provenance. External/std/core/unresolved/ambiguous targets would produce diagnostics or no edge, not guessed edges. Proc macros and build scripts would be explicit configuration choices, because they are necessary for accuracy in real Rust projects but have security/performance implications.
I have a prototype along these lines already: generic RustAnalyzer* ABI, generated C header, prefix install/pkg-config smoke test, RA-backed fixture coverage for direct/method/trait/generic/macro-related calls, and conservative no-edge handling for unsafe/generated ambiguity. The intent is to contribute this as an integration path rather than force Rust-specific internals into codebase-memory: CBM adapts its existing file/call/definition records into the ABI, receives resolved call evidence back, and inserts graph edges only when the returned target maps to a stable local/workspace definition.
To that end I created this: https://github.com/casualjim/cbm-rust-analyzer
Just opening for discussion, PR is incoming
Rust seems to need a different implementation strategy than the current clean-room resolvers. For many languages, codebase-memory can reconstruct enough type and import semantics from tree-sitter plus per-language registries. For Rust, that approach is likely to fail on the cases users care about most: macro_rules!, derive/proc macros, build-script generated code, cfg/features, trait dispatch, associated functions, generics, and cross-crate workspace resolution. To avoid false graph edges, I think we should lean on rust-analyzer semantics directly rather than trying to reimplement that machinery in C.
The proposed shape is a small, vendorable Rust library built on pinned ra_ap_* rust-analyzer crates, exposing a stable generic C ABI. The C indexer would continue owning the graph pipeline and mapping, while the Rust library would load a Cargo workspace once, resolve call targets in batches, and return source/target file/range evidence with confidence and provenance. External/std/core/unresolved/ambiguous targets would produce diagnostics or no edge, not guessed edges. Proc macros and build scripts would be explicit configuration choices, because they are necessary for accuracy in real Rust projects but have security/performance implications.
I have a prototype along these lines already: generic RustAnalyzer* ABI, generated C header, prefix install/pkg-config smoke test, RA-backed fixture coverage for direct/method/trait/generic/macro-related calls, and conservative no-edge handling for unsafe/generated ambiguity. The intent is to contribute this as an integration path rather than force Rust-specific internals into codebase-memory: CBM adapts its existing file/call/definition records into the ABI, receives resolved call evidence back, and inserts graph edges only when the returned target maps to a stable local/workspace definition.
To that end I created this: https://github.com/casualjim/cbm-rust-analyzer