Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン 初心者向け
  • 何か問題がありますか？
#69,613 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go
領域
devtools

調査の方向性

pkg/linters/goroutineresourceleak/goroutineresourceleak.goを読み、checkChannelLeakとmarkChannelUsageに注目してください。次に、testdata/src/a/a.goの259～318行付近にあるSAFE PATTERNSを確認してください。説明されているヘルパー関数呼び出しのテストケースを追加し、ヘルパー関数に渡されたチャネルがリークとして報告されないように使用状況のスキャンを拡張してください。新しいケースがパスし、列挙されている既存の肯定・否定ケースの動作が維持されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
Go
スター
5.4k
フォーク
584
平均マージ
3時間 16分
マージ済み PR（30日）
829

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

github/gh-aw のほかの issue

github/gh-aw の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。