You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This run picked up after a 12-run cache gap (only the 3 most recent strategy entries are retained under the bounded-context policy, so the last cached run was R60 on 2026-07-08, but issue numbering and the registry size show ~60 runs actually happened in between). Registry size jumped from 43 to 64 analyzers. One new, high-confidence, previously-unfiled bug was found and filed: seenmapbool's :=-branch candidate gate is more restrictive than its own var-branch, causing false negatives for map[string]bool-as-set variables assigned from anything other than a literal make()/composite literal.
1 issue filed. No duplicates found (sergo-labeled issues were all closed pre-run).
Tool Cache & Registry Update
Serena LSP: stable at 23 tools, no change.
Architecture change discovered: cmd/linters/main.go no longer lists analyzers directly — it now simply calls multichecker.Main(linters.All()...). The old registry-size detector (grep -c Analyzer cmd/linters/main.go) is now dead and was silently returning stale/wrong deltas.
New detector adopted: count pkg/linters/registry.go's allAnalyzers slice (64 entries) against pkg/linters/doc.go's "All N active analyzers" header (also 64 — matched).
Confirmed sg60a1 landed: writebytestring.go now contains the isExactString check (lines 128, 149-152) wrapping named-string RHS values in string(...) before emitting io.WriteString, matching the recommended fix.
50% proven-strategy reuse: repeated the historically productive approach of auditing SuggestedFix compile-correctness and syntactic-vs-type-resolved matching across a broad swath of linters (the vein that has produced most prior findings: FuncLit scope-boundary bugs, syntactic package-identity bugs, autofix-doesn't-compile bugs).
50% new exploration: the registry architecture change itself was unexpected and required discovering a new detection method from scratch; also explored a fresh bug dimension — inter-branch consistency within a single linter (:= vs var handling drifting apart), which hadn't been an explicit probe target before.
Success criteria: at least one high-confidence, non-duplicate, actionable finding; reconcile registry/tooling state so future runs aren't using a dead detector.
Full audit trail (~20 linters reviewed)
Audited and found clean (no action needed): globwalkignorederror, manualmutexunlock, httpnoctx (FuncLit-boundary walk is correct here — closures capture by reference, so crossing the boundary is semantically valid, unlike the historical execcommandwithoutcontext bug), excessivefuncparams, uncheckedtypeassertion, sortslice, rawloginlib, stringscountcontains (+ test), timeafterleak, goroutinemissingrecover, panic-in-library-code, errorfwrapv, fmterrorfnoverbs, regexpcompileinfunction, ioutildeprecated, hardcodedfilepath, bytescomparestring (confirmed it correctly does NOT need writebytestring's isExactString fix — named-to-unnamed-composite-type assignability differs from named-to-named-basic-type assignability), mapclearloop.
One genuine gap found in seenmapbool (detailed below).
Findings
seenmapbool: inconsistent := vs var candidate gating causes false negatives
Evidence: the := branch requires isMapStringBool(pass.TypesInfo.TypeOf(ident)) && isMapStringBoolExpr(stmt.Rhs[i]) — the second conjunct re-derives type information from AST shape, accepting only make(map[string]bool, ...) calls and map[string]bool{...} composite literals. The var/DeclStmt branch has no such restriction — it accepts any map[string]bool-typed declaration on the type check alone.
Impact: seen := getSeenMap() (a helper returning map[string]bool) or seen := other (a plain identifier copy) silently escape detection even when used as a pure boolean-sentinel set, identical in every other respect to the BadSetBool/BadSetBoolLiteral cases the linter already catches. Existing testdata doesn't exercise either shape, so the gap was also untested.
Currently latent: a targeted grep for ) map[string]bool return signatures in pkg/ found only one hit (pkg/cli/runner_guard_activation_gate.go:110), and it's only consumed by tests — so there's no open production false negative today, but any future helper-returned or copied map[string]bool set would silently miss the linter.
Recommendation: drop the isMapStringBoolExpr conjunct in the := branch to match the var branch's type-only gate; delete the now-dead isMapStringBoolExpr/isMapStringBoolTypeExpr helpers; add testdata for the helper-returned and identifier-copy cases.
Filed as issue (sg61a1, temporary_id: aw_sg61a1, labeled sergo).
Metrics
Linters audited this run: ~20 (of 64 registered)
Findings/observations: 8
Issues filed: 1 (no duplicates skipped — pre-run sergo-label search returned zero open issues, and a targeted search for existing seenmapbool issues found only unrelated historical ones: duplicate-diagnostics-in-closures, escape-analysis, nolint-support-request)
Success score: 8/10 — one high-confidence, previously-unfiled, actionable finding with full evidence and a validation checklist; docked slightly for filing only 1 of the possible 1-3 issues and for the registry-detector staleness only being caught this run rather than earlier.
Land the seenmapbool fix (small, single-file change plus two testdata cases).
Next run, use the registry.go/doc.go-based detector for registry size — the old main.go grep method no longer reflects reality.
Consider extending the "inter-branch consistency" probe (checking whether a linter's := and var/other syntactic-form branches apply the same semantic gate) to other multi-branch linters, since this is a newly identified angle distinct from the previously-tracked bug classes.
Next-run focus
Re-verify sg61a1 landed.
Watch for registry growth past 64 analyzers (use the new detector).
Probe newly added linters' SuggestedFix bodies for exact-type-param vs. Underlying()-match assignability bugs (the writebytestring bug class), and their nolint/test-skip wiring parity.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Executive Summary
This run picked up after a 12-run cache gap (only the 3 most recent strategy entries are retained under the bounded-context policy, so the last cached run was R60 on 2026-07-08, but issue numbering and the registry size show ~60 runs actually happened in between). Registry size jumped from 43 to 64 analyzers. One new, high-confidence, previously-unfiled bug was found and filed:
seenmapbool's:=-branch candidate gate is more restrictive than its ownvar-branch, causing false negatives formap[string]bool-as-set variables assigned from anything other than a literalmake()/composite literal.1 issue filed. No duplicates found (
sergo-labeled issues were all closed pre-run).Tool Cache & Registry Update
cmd/linters/main.gono longer lists analyzers directly — it now simply callsmultichecker.Main(linters.All()...). The old registry-size detector (grep -c Analyzer cmd/linters/main.go) is now dead and was silently returning stale/wrong deltas.pkg/linters/registry.go'sallAnalyzersslice (64 entries) againstpkg/linters/doc.go's "All N active analyzers" header (also 64 — matched).pkg/linters/spec_test.goprogrammatically reconcilesregistryNames(fromallAnalyzers) againstdocumented(parsed fromdoc.go). The historical "doc.go drifts from registry" bug class (e.g. prior issue doc-sync: pkg/linters/doc.go says "29 active analyzers" but 30 are registered — list omits hardcodedfilepath and sprintferrdot #40436) is now structurally prevented rather than needing manual audits each run.writebytestring.gonow contains theisExactStringcheck (lines 128, 149-152) wrapping named-string RHS values instring(...)before emittingio.WriteString, matching the recommended fix.Strategy Split
DELTA-43to64-registry-architecture-change+doc-sync-CI-enforced+narrow-RHS-gate-scan:=vsvarhandling drifting apart), which hadn't been an explicit probe target before.Full audit trail (~20 linters reviewed)
Audited and found clean (no action needed):
globwalkignorederror,manualmutexunlock,httpnoctx(FuncLit-boundary walk is correct here — closures capture by reference, so crossing the boundary is semantically valid, unlike the historicalexeccommandwithoutcontextbug),excessivefuncparams,uncheckedtypeassertion,sortslice,rawloginlib,stringscountcontains(+ test),timeafterleak,goroutinemissingrecover,panic-in-library-code,errorfwrapv,fmterrorfnoverbs,regexpcompileinfunction,ioutildeprecated,hardcodedfilepath,bytescomparestring(confirmed it correctly does NOT needwritebytestring'sisExactStringfix — named-to-unnamed-composite-type assignability differs from named-to-named-basic-type assignability),mapclearloop.One genuine gap found in
seenmapbool(detailed below).Findings
seenmapbool: inconsistent
:=vsvarcandidate gating causes false negativespkg/linters/seenmapbool/seenmapbool.go,collectSeenMapCandidates(lines 99-141).:=branch requiresisMapStringBool(pass.TypesInfo.TypeOf(ident)) && isMapStringBoolExpr(stmt.Rhs[i])— the second conjunct re-derives type information from AST shape, accepting onlymake(map[string]bool, ...)calls andmap[string]bool{...}composite literals. Thevar/DeclStmtbranch has no such restriction — it accepts anymap[string]bool-typed declaration on the type check alone.seen := getSeenMap()(a helper returningmap[string]bool) orseen := other(a plain identifier copy) silently escape detection even when used as a pure boolean-sentinel set, identical in every other respect to theBadSetBool/BadSetBoolLiteralcases the linter already catches. Existing testdata doesn't exercise either shape, so the gap was also untested.) map[string]boolreturn signatures inpkg/found only one hit (pkg/cli/runner_guard_activation_gate.go:110), and it's only consumed by tests — so there's no open production false negative today, but any future helper-returned or copiedmap[string]boolset would silently miss the linter.isMapStringBoolExprconjunct in the:=branch to match thevarbranch's type-only gate; delete the now-deadisMapStringBoolExpr/isMapStringBoolTypeExprhelpers; add testdata for the helper-returned and identifier-copy cases.sg61a1,temporary_id: aw_sg61a1, labeledsergo).Metrics
sergo-label search returned zero open issues, and a targeted search for existing seenmapbool issues found only unrelated historical ones: duplicate-diagnostics-in-closures, escape-analysis, nolint-support-request)Historical context
syntactic_stdlib_match,scope_boundary_funclit,pattern_set_too_narrow(this run's finding fits here),suppression_enforce_gap,double_traversal_dup,phantom_reconcile,registry_delta_detect(method updated this run).Recommendations
seenmapboolfix (small, single-file change plus two testdata cases).registry.go/doc.go-based detector for registry size — the oldmain.gogrep method no longer reflects reality.:=andvar/other syntactic-form branches apply the same semantic gate) to other multi-branch linters, since this is a newly identified angle distinct from the previously-tracked bug classes.Next-run focus
sg61a1landed.SuggestedFixbodies for exact-type-param vs.Underlying()-match assignability bugs (thewritebytestringbug class), and theirnolint/test-skip wiring parity.References:
All reactions