brokk_bifrost_python/graph/mod.rs
1//! Python's usage-graph scans: the forward per-target scan
2//! ([`extractor`]/[`hits`]) and the whole-workspace inverted per-file walk
3//! ([`inverted`]), both resolving references through [`resolver`].
4//!
5//! No analyzer handle appears here. `brokk-bifrost-analysis` downcasts once and
6//! hands over a [`PythonGraphSource`] plus the
7//! [`PythonUsageSource`](crate::graph_support::PythonUsageSource) the memoized
8//! Python products come from.
9
10pub mod extractor;
11pub mod hits;
12pub mod inverted;
13pub mod resolver;
14
15use brokk_bifrost_core::analyzer::capabilities::{ImportAnalysisProvider, TypeHierarchyProvider};
16use brokk_bifrost_core::analyzer::{CodeUnitIndex, DefinitionLookupAccess};
17
18/// The *dispatching* analyzer's side of a Python usage-graph scan.
19///
20/// Deliberately not the Python analyzer: in a mixed workspace the query is
21/// issued against a `MultiAnalyzer`, whose `definitions` merges every language's
22/// shards and whose `get_ancestors` crosses language boundaries. The walks
23/// depend on that reach, so this stays separate from the
24/// [`PythonUsageSource`](crate::graph_support::PythonUsageSource) that answers
25/// the Python-only questions.
26///
27/// `definitions` is a callback rather than a handle because the analyzer's
28/// global definition index is built lazily on first access and only
29/// [`resolver::resolve_receiver_type`]'s last fallback reaches it; returning a
30/// handle would force the build at every scan.
31#[derive(Clone, Copy)]
32pub struct PythonGraphSource<'a> {
33 pub index: &'a dyn CodeUnitIndex,
34 pub hierarchy: Option<&'a dyn TypeHierarchyProvider>,
35 pub imports: Option<&'a dyn ImportAnalysisProvider>,
36 pub definitions: &'a DefinitionLookupAccess<'a>,
37}