brokk_bifrost_ruby/graph/
mod.rs

1//! Ruby's usage-graph scans: the per-symbol forward scan
2//! ([`extractor`]/[`hits`]) and the whole-workspace inverted per-file walk
3//! ([`inverted`]), both resolving references through [`resolver`] -- the shared
4//! Ruby resolution library the definition route also reads.
5//!
6//! No analyzer handle appears here. `brokk-bifrost-analysis` downcasts once and
7//! hands over a [`RubyGraphSource`] plus the
8//! [`RubySource`](crate::graph_support::RubySource) the memoized Ruby products
9//! come from.
10
11pub mod extractor;
12pub mod hits;
13pub mod inverted;
14pub mod resolver;
15pub mod syntax;
16
17use brokk_bifrost_core::analyzer::{CodeUnitIndex, DefinitionLookupAccess};
18
19/// The *dispatching* analyzer's side of a Ruby usage-graph scan.
20///
21/// Deliberately not the Ruby analyzer, for the reason recorded on
22/// `PythonGraphSource`: in a mixed workspace the query is issued against a
23/// `MultiAnalyzer`, whose `definitions` merges every language's shards and whose
24/// enclosing-unit lookup crosses language boundaries. The walks depend on that
25/// reach, so this stays separate from the
26/// [`RubySource`](crate::graph_support::RubySource) that answers the Ruby-only
27/// questions.
28///
29/// `definitions` is a callback rather than a handle because the analyzer's
30/// global definition index is built lazily on first access and only the
31/// factory-return inference in [`extractor`] reaches it; the diagnostics pass
32/// builds a [`resolver::RubySemanticIndex`] and never touches it at all, so
33/// returning a handle would force the build there too.
34#[derive(Clone, Copy)]
35pub struct RubyGraphSource<'a> {
36    pub index: &'a dyn CodeUnitIndex,
37    pub definitions: &'a DefinitionLookupAccess<'a>,
38}
brokk_bifrost_ruby/graph/mod.rs

brokk_bifrost_ruby/graph/
mod.rs
