Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

goroutineresourceleak: checkChannelLeak misses usage via function-call indirection (channel_usage_indirection_blind)

Aperta Adatta ai principianti
  • Qualcosa non va?
#69,613 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
devtools

Direzione di ricerca

Leggi pkg/linters/goroutineresourceleak/goroutineresourceleak.go, concentrandoti su checkChannelLeak e markChannelUsage, quindi esamina gli SAFE PATTERNS in testdata/src/a/a.go intorno alle righe 259-318. Aggiungi il caso di test descritto per una chiamata a una funzione helper ed estendi la scansione degli usi affinché un canale passato a una funzione helper non venga segnalato come perdita. Il lavoro è completato quando il nuovo caso passa e i casi positivi e negativi esistenti elencati mantengono il loro comportamento.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

cookie sergo
Problem

pkg/linters/goroutineresourceleak/goroutineresourceleak.go checkChannelLeak (lines 149-171), backed by createdChannels and markChannelUsage (lines 173-236), only recognizes a channel as used inside a spawned goroutine via three direct AST shapes within the goroutine body itself: a SendStmt (ch <- v), a literal close(ch) call, or a unary receive (<-ch). There is no handling for a channel being passed as an argument to another function call, stored into a struct field or closure, or returned -- all common decomposition patterns where the real send/receive/close happens inside the callee rather than inline in the goroutine body.

This causes a false-positive channel leak report on perfectly safe code: a goroutine that creates a channel and immediately hands it off to a well-behaved helper function (for example go func() { ch := make(chan int); process(ch) }(), where process does the actual send/receive/close) has zero recognized usage events under the current scan, so it falls through every safe-pattern check in checkChannelLeak and gets flagged as a leak.

Evidence
  • goroutineresourceleak.go:159-160 -- channels := createdChannels(pass, body); markChannelUsage(pass, body, channels), both walk only the goroutine's own body via ast.Inspect (excluding FuncLit boundaries)
  • goroutineresourceleak.go:208-233 -- markChannelUsage checks only *ast.SendStmt, a close(...) CallExpr, and a token.ARROW UnaryExpr; no case handles a channel identifier appearing as a plain CallExpr argument, a composite literal field, or a return value
  • testdata/src/a/a.go:259-318 (SAFE PATTERNS section) has zero coverage for a channel passed to a helper function -- every existing safe case either uses one of the three recognized syntactic forms directly inline, or is a named-function goroutine (go doSomeWork()), which is explicitly out of scope for the whole check per the namedFunctionGoroutine comment
  • This is distinct from the already-filed paren_unwrap_gap (#68591) and adjacent_defer_assumption (#68945) issues on this same linter, which affect checkCancelLeak/checkMutexLeak rather than checkChannelLeak
Recommendation

Extend markChannelUsage to also treat a channel identifier appearing as a CallExpr argument (or in a composite literal / return statement) as a usage event, at least conservatively marking it as both sent-and-received to suppress the diagnostic -- a full call-graph analysis is out of scope for an AST-heuristic linter, but a channel handed to any opaque call should not be treated as provably unused.

Validation checklist
  • Add a testdata case: ch := make(chan int); process(ch) where process is an external/unanalyzed function -- should NOT be flagged
  • Confirm existing positive cases (channelWithoutUse, channelWithSend, channelWithReceive, channelWithUnbufferedSequentialSendAndReceive) still correctly flag
  • Confirm existing negative cases (channelWithClose, channelWithBufferedSendAndReceive) still correctly pass
Effort

Small -- one function (markChannelUsage) plus one new testdata fixture.

Pattern class: channel_usage_indirection_blind (new -- a resource-usage scan recognizing only a closed set of direct syntactic forms, with no awareness of usage via a function-call indirection).

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · 211.8 AIC · ⌖ 0.49 AIC · ⊞ 5.3K · ◷

  • expires on Oct 23, 2026, 7:59 PM UTC-08:00
Lingua principale
Go
Stelle
5.4k
Fork
584
Merge medio
3h 20m
PR unite (30g)
830

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di github/gh-aw

Tutte le issue di github/gh-aw

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.