Module function_hotspots 

function-hotspots analysis — repo-wide function-level hotspot ranking.

Every hotspot-family analysis (hotspots, hotspot-velocity, code-health) is FILE-granularity: a 2000-line file with one genuinely hot function looks identical to one with uniform low-grade churn. This analysis ranks HEAD-live functions by the same revs × cognitive-style score hotspots uses, so the two are comparable in spirit.

Data sources — no tree-sitter reparse. HEAD function/method spans come from entities (path, name, kind, start_line, end_line), already populated at ingest; entities.rev_introduced/rev_last_seen are degenerate (always head_rev — a single HEAD-only appender), so this answers “hot now,” not “was hot historically.” Per-function complexity at HEAD comes from complexity_metrics. Revision history comes from hunks (rev, path, new_start, new_lines).

Hunk↔span overlap. The overlap predicate is the exact one crate::analyses::function_xray already applies for a single --target file, transliterated to SQL so it can run as a repo-wide join instead of a per-target Rust loop: a hunk touching [new_start, new_start + new_lines) overlaps a function span [start_line, end_line] when new_start <= end_line AND new_start + new_lines > start_line; a pure deletion (new_lines = 0) attributes to the span whose range contains the anchor line (start_line <= new_start <= end_line). See function_xray::hunk_overlaps for the canonical Rust form and its unit tests covering every edge case.

Rename limitation (same as function-xray). The join is hunks.path = entities.path — the current HEAD-relative path. hunks is keyed on the literal path recorded at commit time, and rewriting it through the rename-aware lineage CTE (crate::analyses::lineage::rewrite) would only affect changes/ changes_lineage references, not hunks itself, so opting in would do nothing here — a file’s pre-rename history is not attributed, matching function-xray’s documented caveat exactly.

Approximate attribution. Like function-xray, hunk line numbers are historical (recorded at commit time) while the span is the function’s CURRENT (HEAD) location — line numbers drift as intervening commits insert/remove lines above a function, so attribution is an approximation, not an exact replay. This mirrors function-xray’s documented limitation.

Score formula — identical shape to crate::analyses::hotspots:

  function_hotspot_score(f) = percentile_rank(revs)
                             × percentile_rank(cognitive)
                             × (100 − cognitive_health) / 4

where cognitive_health = 100 × (1 − 0.40 × normalize(cognitive)), normalize divides by the max cognitive complexity across all HEAD-live functions. Output range [0, 10], same scale as hotspots.hotspot_score — see hotspots.rs’s module doc for the full derivation of the / 4 divisor and the [60, 100] range of cognitive_health.

Research basis: Gall et al. ICSM 2003 (HistoryFinder, function-level churn) + Tornhill 2018 (Software Design X-Rays, the file-level hotspot score this mirrors).

Structs

FunctionHotspotRow

One HEAD-live function/method, ranked by the hotspots-style score.

Functions

run_function_hotspots