[sergo] Sergo Report: STABLE-77 reconcile + deferinloop range-over-func false positive - 2026-10-10 #67337

Run: R92 - Registry: 77 analyzers (stable, no delta since R89) - Serena: 24 tools (stable, exact match)

Executive summary

Reconciled 5 open sergo-labeled issues against current code - all still accurate, zero reverse-phantom flips, and sg91a1 (filed last run) confirmed landed as a real open issue. With the internal/coverage new-explore vein now exhausted (per last runs own recommendation), this run picked a fresh never-before-audited linter, deferinloop, and found a genuine false-positive gap: it does not account for Go 1.23+ range-over-func semantics, where defer inside the loop body actually does run per iteration - the opposite of what this linters diagnostic claims.

Tool / registry status

• Serena: activate_project, delete_memory, edit_memory, find_declaration, find_implementations, find_referencing_symbols, find_symbol, get_current_config, get_diagnostics_for_file, get_symbols_overview, initial_instructions, insert_after_symbol, insert_before_symbol, list_memories, onboarding, open_dashboard, read_memory, rename_memory, rename_symbol, replace_in_files, replace_symbol_body, safe_delete_symbol, search_for_pattern, write_memory - 24 tools, identical to cached snapshot.
• Linter registry (pkg/linters/registry.go): 77 analyzers, no delta since R89.

Strategy split (50/50)

Cached reuse (50%): Re-verified all 5 currently open sergo issues via direct code read rather than trusting labels:

• contextcancelnotdeferred still enforced on native CI only - wasm LINTER_FLAGS omission unfixed (issue 55932 auto-expired, 2nd oc #65753 (sg87a1) contextcancelnotdeferred: wasm LINTER_FLAGS still omits it - confirmed unfixed
• globwalkignorederror + strconvparseignorederror: shared matcher still misses bare ExprStmt discards (3rd occurrence, sibling fix #66009 (sg88a1) globwalkignorederror/strconvparseignorederror: nodeFilter still AssignStmt-only - confirmed unfixed
• reflectdeepequalusage: function-value alias bypasses detection, gap documented by its own test fixture #66436 (sg89a1) reflectdeepequalusage: function-value-alias gap still present - confirmed unfixed
• coverage.hitCount is column-blind: multiple same-line coverage blocks silently pick the wrong hit count, undermining perf-linter #66773 (sg90a1) internal/coverage.hitCount: still line-only/column-blind - confirmed unfixed
• coverage.findProfile: suffix-match over unordered map can nondeterministically return the wrong files profile #67102 (sg91a1) internal/coverage.findProfile: still first-suffix-match-wins, no longest-match preference - confirmed unfixed

All 5 landed exactly as filed, zero reverse-phantom closures this run.

New exploration (50%): First-ever audit of pkg/linters/deferinloop/deferinloop.go. Its isInsideLoop helper classifies any defer inside a for/range loop body as a leak risk purely by AST node kind, with no reference to type information.

Findings

deferinloop false-positives on range-over-func loops (filed as #67336)

• isInsideLoop (deferinloop.go:69-83) walks enclosing nodes and returns true on the first *ast.ForStmt/*ast.RangeStmt, false on the first *ast.FuncLit - identical treatment for every RangeStmt regardless of what is being ranged over.
• This repos go.mod pins go 1.26.9, which fully supports range-over-func iterators (Go 1.23+). Per the language spec/design, a for v := range someFunc loop body compiles to an implicit per-iteration function literal - so a defer inside it genuinely executes at the end of each iteration, not when the enclosing function returns. That is the exact opposite of this linters diagnostic text, and the opposite of every other RangeStmt case.
• No existing testdata covers this shape, and no live call site was found in pkg/ today (only a comment referencing iter.Seq overhead) - a latent/forward-looking correctness gap rather than a currently-firing false positive, consistent with the filing bar used for the two most recent coverage-package findings.
• Fix path: thread pass.TypesInfo into isInsideLoop and check rangeStmt.X underlying type for *types.Signature, reusing the TypeOf pattern already used elsewhere in astutil.go.

Generated tasks

1. Fix deferinloop range-over-func false positive (small effort) - add a type check in isInsideLoop, add a range-over-func testdata case, confirm no regression on existing slice/classic-for/FuncLit-boundary cases.

Metrics

• Findings this run: 6 (5 cached-vein reconfirmations + 1 new)
• Issues created: 1 (deferinloop: range-over-func (Go 1.23+ iterators) false-positives defer-does-not-run-per-iteration, which is backwards for that #67336) - 8th consecutive single-issue run (depth-over-padding pattern: R73/R81/R87-R92)
• Tasks generated: 1
• Success score: 8/10

Historical context

• 92 total runs, 560 cumulative findings, 159 cumulative tasks, 8.71 average success score.
• sergo-strategies.jsonl was at 101050 bytes pre-run (already past the usual one-line-prune buffer) - pruned 2 oldest entries instead of 1 to make room; sergo-tools-list.json (49 KB) was pruned for the first time (oldest 2 run-notes removed) to keep its growth in check.

Recommendations / next-run focus

• Verify deferinloop: range-over-func (Go 1.23+ iterators) false-positives defer-does-not-run-per-iteration, which is backwards for that #67336 lands as filed; re-tally opens next run (expect 6 unless bulk-closed).
• If the registry grows to 78 analyzers, audit the new linter fresh.
• Consider checking deferinloops handling of range-over-int (for range n, Go 1.22+) - that case is not a func-iterator and defer behaves normally there, so it should still correctly flag; not yet verified.
• Check sergo-strategies.jsonl size before appending next run and prune as many oldest lines as needed (one prune is no longer reliably sufficient).

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · 314.9 AIC · ⊞ 5.2K · ◷

• expires on Oct 10, 2026, 8:04 PM UTC-08:00