pub trait LanguagePlugin: Sync {
// Required methods
fn name(&self) -> &str;
fn detect(&self, workspace: &Path, input: &PluginInput) -> bool;
fn levels(&self) -> Vec<Level>;
fn analyze(&self, workspace: &Path, input: &PluginInput) -> Result<Graph>;
// Provided methods
fn config(&self) -> Table { ... }
fn metrics(&self, _graph: &Graph) -> Vec<(String, MetricInputs)> { ... }
fn function_units(&self, _graph: &Graph) -> Vec<(Node, MetricInputs)> { ... }
fn versions(
&self,
_workspace: &Path,
_input: &PluginInput,
) -> Vec<(String, String)> { ... }
fn roots(&self, _workspace: &Path) -> Vec<(String, String)> { ... }
fn presets(&self, _input: &PluginInput) -> Vec<Preset> { ... }
fn metric_specs(
&self,
defaults: BTreeMap<String, AttributeSpec>,
) -> BTreeMap<String, AttributeSpec> { ... }
fn report_overrides(&self) -> ReportOverride { ... }
}Required Methods§
Sourcefn name(&self) -> &str
fn name(&self) -> &str
Canonical name, e.g. "rust". Used by --plugin and recorded in the
snapshot. Each plugin has exactly one name (js and ts are separate).
Sourcefn detect(&self, workspace: &Path, input: &PluginInput) -> bool
fn detect(&self, workspace: &Path, input: &PluginInput) -> bool
Can this plugin parse workspace (honoring input)?
Sourcefn levels(&self) -> Vec<Level>
fn levels(&self) -> Vec<Level>
Levels this plugin can produce, each carrying its edge-kind / attribute / node-kind / cycle-kind semantics.
Sourcefn analyze(&self, workspace: &Path, input: &PluginInput) -> Result<Graph>
fn analyze(&self, workspace: &Path, input: &PluginInput) -> Result<Graph>
Parse the workspace into the file-level graph. Structure only: nodes
(with their structural attributes) + edges. Metrics are added downstream.
When input.ignore_tests is set, the plugin must drop its own test files
here (it knows the language’s conventions).
Provided Methods§
Sourcefn config(&self) -> Table
fn config(&self) -> Table
The plugin’s fully-merged config table (its inheritance chain
defaults.toml ⊕ [base] ⊕ <lang>.toml). Surfaced for --export-full-config
so a user can inspect every effective parameter. Default: empty (a stub /
test plugin with no config file).
Sourcefn metrics(&self, _graph: &Graph) -> Vec<(String, MetricInputs)>
fn metrics(&self, _graph: &Graph) -> Vec<(String, MetricInputs)>
Measure this language’s per-file complexity tier-1 counts and return
them keyed by file node id (an absolute path). The plugin parses each of
its own files (by node.id) with its own grammar and engine, returning a
MetricInputs per file; it does not write them. The orchestrator
runs the tier-2 registry and writes every metric onto the node — so the
plugin needs no dependency on the graph/enrichment crate. Default: none (a
plugin that ships no metric engine).
Sourcefn function_units(&self, _graph: &Graph) -> Vec<(Node, MetricInputs)>
fn function_units(&self, _graph: &Graph) -> Vec<(Node, MetricInputs)>
Function-level metric units — one per sub-file unit (function / method /
closure) — for the optional functions graph level. Each returned pair is
the unit’s Node (its per-language kind, name, and parent = its
file node’s id, but no metrics yet) plus the unit’s measured
MetricInputs; the orchestrator writes the metrics onto the node. graph
is the just-parsed file graph with absolute file-path ids, so a plugin
reads each file by node.id. Only called when the level is enabled;
default: none (a plugin that ships no function-level support).
Sourcefn versions(
&self,
_workspace: &Path,
_input: &PluginInput,
) -> Vec<(String, String)>
fn versions( &self, _workspace: &Path, _input: &PluginInput, ) -> Vec<(String, String)>
Toolchain versions to record in the snapshot, e.g. [("rustc", "1.88.0")].
Sourcefn roots(&self, _workspace: &Path) -> Vec<(String, String)>
fn roots(&self, _workspace: &Path) -> Vec<(String, String)>
Named external-path roots for this language, as (name, absolute_path)
pairs, used to shorten node ids in the snapshot (a path under a root is
rewritten to {name}/…). These are language-specific — e.g. Rust
returns cargo / registry / rustup / rust-src; a Python plugin would
return its virtualenv / site-packages; JS/TS would return node_modules.
The orchestrator always adds the generic target root itself, so a plugin
returns only its own toolchain/dependency locations. Default: none.
This keeps language/toolchain knowledge inside the plugin instead of the
language-agnostic orchestrator (mirrors versions).
Sourcefn presets(&self, _input: &PluginInput) -> Vec<Preset>
fn presets(&self, _input: &PluginInput) -> Vec<Preset>
The Prompt-Generator presets for this language. A plugin builds them from
its own config (the common catalog in defaults.toml merged with the
language’s <lang>.toml, with each doc_url resolved). Default: none (a
plugin that ships no presets).
Sourcefn metric_specs(
&self,
defaults: BTreeMap<String, AttributeSpec>,
) -> BTreeMap<String, AttributeSpec>
fn metric_specs( &self, defaults: BTreeMap<String, AttributeSpec>, ) -> BTreeMap<String, AttributeSpec>
Transform the orchestrator’s language-neutral default complexity metric
specs (key → AttributeSpec, from code-ranker-graph’s metric_specs)
for this language. Default: pass them through unchanged. A plugin may reword
a description to add language-specific nuance (e.g. Rust noting that
sloc / lloc / cloc / blank exclude inline #[cfg(test)] items) — so
the shared catalog stays neutral and each language refines only what differs.
Sourcefn report_overrides(&self) -> ReportOverride
fn report_overrides(&self) -> ReportOverride
Per-language patches over the global report lists — the table columns,
the card-featured metrics, and the JSON stats keys (all inherited from
the metric catalog). A language adds its own metric (e.g. Rust unsafe),
drops some, or reorders, via its <lang>.toml [report] section. The
orchestrator applies the patch over the catalog defaults, then prunes to
keys present. Default: no override (use the catalog lists as-is).
Dyn Compatibility§
This trait is dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety".