Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/analysis/passes/httpresponse: check whether http.Response Body is closed. #31131

timakin opened this issue Mar 29, 2019 · 3 comments


Copy link

@timakin timakin commented Mar 29, 2019

httpresponse really helps you to avoid a mistake when using net/http package.
But it only whether your function call of Body.Close() is in correct line or not.

So I recently created own linter to check "whether you call Body.Close() or not" like the below case.

func f() {
	_, err := http.Get("") // want "response body must be closed"
	if err != nil {
		// handle error

After I released, I realized it might be better if an official httpresponse supported this workflow.
So, can I contribute to add this feature?

@gopherbot gopherbot added this to the Unreleased milestone Mar 29, 2019
Copy link

@agnivade agnivade commented Mar 30, 2019

Copy link

@alandonovan alandonovan commented Apr 10, 2019

We already have a check that does something very similar to this: lostcancel, which looks for calls of the form ctx, cancel = context.WithCancel(...) where the cancel variable is not referenced on all execution paths. It uses the syntactic control-flow graph; you don't need SSA to solve the problem; see

I suggest we fork that analysis, adapt it to this problem, then try to identify the generalization, as I'm sure there are many other functions that users would designate for this analysis, like they do for unusedresult.

Copy link

@gopherbot gopherbot commented Apr 16, 2019

Change mentions this issue: cmd/gopherbot: CC triaged issues to owners

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants