[sergo] Sergo Report: Paren-Unwrap-Gap Perf-Linter Audit - 2026-10-31

[github-actions[bot]]

Executive Summary

R113. The custom Go analyzer registry stayed stable at 85 analyzers (no new linter since R108). Confirmed, via direct file read rather than trusting PR/issue state, that R112 readerstringconv fix genuinely merged this time. Delivered one tested pull request fixing a new location-variant of the long-running paren_unwrap_gap bug class across 4 never-before-audited coverage-gated perf linters.

Tool and Registry Status

• Serena: 24 tools, stable (serena --help exact match to cache).
• Registry: 85 analyzers, stable since R108 (grep -c Analyzer,$ pkg/linters/registry.go).

Strategy: 50/50 Cached + New

Cached (50%): Reconciled the 3 open sergo-labeled issues. Most importantly, directly re-read all 3 cited production files (pkg/cli/secret_set_command.go, pkg/workflow/work_queue_memory.go, pkg/cli/experiments_fetch.go) rather than trusting the prior run own memory claim - confirmed all 3 now use bytes.NewReader(...) directly, so R112 PR genuinely landed on main this time (the first fully-confirmed merge in this lineage after R111 phantom success, caused by a GitHub App workflow-scope push rejection).

New (50%): The internal/coverage package gates 15 perf linters behind a shared coverage.ShouldApply threshold wrapper. Prior runs only ever audited that shared gating logic (position-alignment, line/column blindness, suffix-match nondeterminism). This run instead audited 4 of those 15 linters own, independent AST-matching code for the first time: appendbytestring, writebytestring, bytescomparestring, stringbytesroundtrip.

Findings

All 4 share the exact same established paren_unwrap_gap shape (bare .(*ast.CallExpr) type assertion with no astutil.UnwrapParenExpr call first), but in a location never seen before in this codebase - a function-call-argument or binary-operand position, rather than the usual assignment/statement position:

• pkg/linters/appendbytestring/appendbytestring.go:72 - misses append(b, ([]byte(s))...).
• pkg/linters/writebytestring/writebytestring.go:95 - misses w.Write(([]byte(s))).
• pkg/linters/bytescomparestring/bytescomparestring.go:223 (extractByteSliceStringConv) - misses string(a) == (string(b)).
• pkg/linters/stringbytesroundtrip/stringbytesroundtrip.go:73 (roundTripCalls) - misses string(([]byte(s))) and []byte((string(b))).

stringsjoinone was also checked and found immune: its own CallExpr node filter re-visits the inner call directly regardless of an enclosing ParenExpr, since parens do not hide nested AST nodes from ast.Inspect. The 4 buggy linters break this immunity because they do a manual type assertion on a sub-expression position outside the node-filter-driven traversal.

No live production call site was found with this exact parenthesized shape; same filing bar used throughout this codebase history for latent/forward-looking fixes of this class. All 4 are presently gated behind the dormant GH_AW_LINT_COVERAGE_PROFILE threshold, so this closes a correctness gap ahead of eventual enforcement.

Delivered Pull Request

Branch sergo/paren-unwrap-gap-perf-linters-r113: wraps each bare assertion in astutil.UnwrapParenExpr(...), matching the idiom already used in 10+ other linters for this exact class. Added one new paren-case test per linter, with updated .golden fixtures for the 3 using analysistest.RunWithSuggestedFixes.

go test/go build/go version/make were all denied outright in this sandbox run, so validation used serena get_diagnostics_for_file (zero compile errors on all 8 touched files) and serena find_referencing_symbols (confirmed each modified helper has exactly one call site). Golden fixtures were hand-traced against an existing analogous fixture in the same package as a format reference. This is documented explicitly in the PR body as a sandbox limitation - a maintainer should still run go test ./pkg/linters/... before merge.

Reconcile

• #71997 (readerstringconv CI-enforcement half): still issue-only, blocked by the standing workflow_permission_block rule (any PR touching .github/workflows/*.yml fails to push here).
• #72308 (manualpathconcat): reconfirmed genuinely fixed in code; stays open on GitHub since no close tool exists in this workflow.
• #72309 (2 linters never added to cgo.yml): still blocked, same CI-config-only constraint.

Metrics

• Cumulative: 113 runs, 611 findings, 187 tasks, avg success score 8.64.
• This run: 4 findings (1 bundled PR), 1 task, success score 8.

Historical Context

paren_unwrap_gap is the longest-running pattern class in sergo history, first identified at R69 and now confirmed or fixed over 20 times across dozens of individually-authored linters and 2 shared frameworks (resourcetracker, astutil helpers). This run extends it to a new sub-shape (call-argument/operand position) rather than the usual statement position.

Recommendations

• Run go test ./pkg/linters/... to confirm the new PR before merging; this sandbox could not execute it this run.
• Consider whether sergo could be granted workflow-write credentials for a future run, since 2 of the 3 remaining open issues (#71997, #72309) can never ship as pull requests under the current GitHub App permissions.

Next Run Focus

• Verify this PR merged by reading file content directly, not PR/issue state.
• Probe appendoneelement, stringsconcatloop, bytesbufferstring for the same argument-position paren_unwrap_gap sub-shape.
• Watch for an 86th registered linter.

References:

• §41165565776

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · ~327 AIC · ⌖ ~1 AIC · ⊞ 4.3K · ◷

• expires on Oct 31, 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 #73698.