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::query_token::QueryToken;
17use brokk_bifrost_core::analyzer::{CodeUnitIndex, DefinitionLookupAccess};
18
19/// The *dispatching* analyzer's side of a Python usage-graph scan.
20///
21/// Deliberately not the Python analyzer: in a mixed workspace the query is
22/// issued against a `MultiAnalyzer`, whose `definitions` merges every language's
23/// shards and whose `get_ancestors` crosses language boundaries. The walks
24/// depend on that reach, so this stays separate from the
25/// [`PythonUsageSource`](crate::graph_support::PythonUsageSource) that answers
26/// the Python-only questions.
27///
28/// `definitions` is a callback rather than a handle because the analyzer's
29/// global definition index is built lazily on first access and only
30/// [`resolver::resolve_receiver_type`]'s last fallback reaches it; returning a
31/// handle would force the build at every scan.
32#[derive(Clone, Copy)]
33pub struct PythonGraphSource<'a> {
34 pub index: &'a dyn CodeUnitIndex,
35 pub hierarchy: Option<&'a dyn TypeHierarchyProvider>,
36 pub imports: Option<&'a dyn ImportAnalysisProvider>,
37 pub definitions: &'a DefinitionLookupAccess<'a>,
38 /// Proof that the request scope this per-query bundle serves is open
39 /// (issue #2414 step 3).
40 pub token: QueryToken<'a>,
41}