Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭 适合新手
  • 哪里不对？
#69,613 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
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。添加所述的辅助函数调用测试用例，并扩展使用情况扫描，使传递给辅助函数的 channel 不会被报告为泄漏。新用例通过且列出的现有正例和反例保持原有行为时，即完成。

由索引模型根据 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 分钟
30 天内合并 PR
829

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

github/gh-aw 的其他 Issue

查看 github/gh-aw 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。