[sergo] Sergo Report: Reconcile-Refile + New Alias-Snapshot Bug - 2026-09-27

[github-actions[bot]]

Executive summary

Run R79 of the ongoing Serena-powered Go static-analysis audit of pkg/linters. Registry held steady at 73 analyzers (no new linter since R74). Reconciled 15 pre-run open issues against current code: 2 auto-expired (closed/not_planned) with their bugs still 100% present in the code, so both were refiled with fresh evidence. New-exploration budget went into a first-ever full read of lenstringzero alias tracking, since the never-solo-audited-linter backlog was fully exhausted last run - found a genuinely new bug class. 3 issues filed this run.

Tool and registry status

• Serena: 24 tools, stable, activate_project OK for go/typescript/bash.
• Registry: grep -c Analyzer, pkg/linters/registry.go = 73, unchanged since R74 (uncheckedsliceindex). No new linter to audit this run.

Strategy: 50/50 cached vs new

Cached component (reconcile): gh api swept the 15 open sergo-labeled issues. 13 were unchanged. Two had auto-expired closed/not_planned since R78:

• bufferresetbeforereuse: per-block state isolation still unfixed (issue 60170 auto-expired, 5th reverse-phantom) #61947 (bufferresetbeforereuse per-block state isolation, itself a 5th-generation refile going back to bufferresetbeforereuse: per-block state isolation misses reuse across if/for/switch boundaries #60170) - re-read the code, the fresh-map-per-BlockStmt plus non-descent-into-nested-control-flow bug is still exactly as filed. Refiled.
• astutil.StringLitValue/IsStringLiteral skip ParenExpr unwrap, silently weakening 5 linters (paren_unwrap_gap) #61948 (astutil.StringLitValue / IsStringLiteral missing ParenExpr unwrap, weakening 5 downstream linters at once) - re-read astutil.go, both helpers are still bare *ast.BasicLit assertions. Refiled.

This is now the pattern for both lineages: the team auto-expires stale issues faster than the underlying one/two-line fixes land, so a periodic refile with re-verified evidence keeps them visible.

New-exploration component: with the never-solo-audited-linter backlog fully drained as of R78, this run pivoted to re-probing an already-known linter for a bug class it had never been checked against. Grepped for map[types.Object] state-tracking helpers across pkg/linters and picked lenstringzero, whose alias-tracking feature (added years ago for the n := len(s); n == 0 idiom) had never had a dedicated bug audit.

Findings

lenstringzero: alias table is a single pass-wide snapshot with no position tracking (new)

collectLenStringAliases walks every file in the package exactly once via ast.Inspect, building one alias map keyed by types.Object, before run() ever examines a single comparison. Every later query (analyzeLenStringExpr, invoked once per matched BinaryExpr) reads that same, already-finalized map - so the map only ever reflects the FINAL state of each variable after all its DEFINE/reassignment/increment events in the file have already happened, never the state at the specific source position of the comparison being checked.

Concrete failure: a variable is defined as len(s), used in a comparison that should be flagged, then reassigned to something unrelated later in the same function. Because the reassignment deletes the alias during the single up-front collection pass (which completes before any comparison is even looked at), the EARLIER, textually-valid comparison is silently never flagged - a false negative. The existing testdata only covers the reassign-then-use order (which happens to produce the right answer for the wrong reason); the use-then-reassign order, which is where the bug actually surfaces, has zero coverage.

Named this pattern class presnapshot_position_blind - distinct from the previously-catalogued block_scope_state_reset (loses state too early, per nested block) and branch_state_merge (conflates sibling branches): this one keeps one global answer for too long, blind to source position entirely.

bufferresetbeforereuse: per-block state isolation (6th reverse-phantom refile)

Same root cause first filed at R63 (#60170): analyzeStraightLineBlock gets fresh write/read maps every call, and collectEvents refuses to descend into nested if/for/switch bodies, so a write-then-read in an outer block never links to a reuse-write inside a nested block. Six confirmed cycles of auto-expire-then-refile now.

astutil.StringLitValue / IsStringLiteral: missing ParenExpr unwrap (2nd reverse-phantom refile)

Both shared helpers still do a bare *ast.BasicLit type assertion. Affects 5 call sites transitively (trimleftright, tolowerequalfold, errstringmatch, fmterrorfnoverbs, errorfwrapv) for a 2-line fix.

Tasks generated (3 issues filed)

1. lenstringzero alias-table position-blindness (new bug, medium effort, needs a flow-sensitive or single-assignment-only redesign of the alias feature).
2. bufferresetbeforereuse per-block isolation refile (small-medium effort, thread state across nested blocks).
3. astutil paren-unwrap refile (small effort, 2-line shared-helper fix).

Metrics this run

• Findings: 5 (2 re-verified reverse-phantoms + 1 new confirmed bug + repo-context evidence gathering)
• Issues created: 3 / 3 max
• Success score: 9/10 (all 3 findings code-verified with concrete repros; zero apostrophe/dedup issues)

Historical context

• Total runs: 79. Total findings: 496. Total tasks: 140. Rolling average success score: 8.77.
• Confirmed reverse-phantom instances across all lineages: 11 (this run adds the 6th bufferresetbeforereuse cycle and the 2nd astutil-paren cycle).
• Never-solo-audited-linter backlog: fully exhausted since R78; new-explore now works by re-probing known-clean linters for untested bug classes, or waiting for the registry to grow.

Recommendations

• Consider a structural fix upstream: linters whose auto-fix/diagnostic PRs keep getting closed not_planned without the underlying code changing suggests these low-priority/latent findings are being triaged out rather than fixed - worth a maintainer decision on whether to wontfix-and-suppress-refiling for the two 6x/2x lineages, or actually schedule the fixes.
• The new presnapshot_position_blind pattern class is worth a deliberate sweep: any other linter using a one-shot whole-file/whole-package pre-collection map (grep for a collect* helper called once before a Preorder/Inspect loop) is a candidate.

Next run focus (R80)

Verify sg79a1/sg79a2/sg79a3 landed; re-tally open issues (expect 16); if the registry grows to 74 analyzers, audit the new linter fresh; otherwise probe other whole-pass-precomputed lookup tables for the presnapshot_position_blind class.

References:

• §36292527250

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · 215 AIC · ⌖ 8.66 AIC · ⊞ 6.9K · ◷

• expires on Sep 27, 2026, 7:59 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by Sergo - Serena Go Expert.

A newer discussion is available at Discussion #63920.