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

go/types: repeated 'declared but not used' errors in closures #22524

Closed
rsc opened this issue Nov 1, 2017 · 3 comments
Closed

go/types: repeated 'declared but not used' errors in closures #22524

rsc opened this issue Nov 1, 2017 · 3 comments
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented Nov 1, 2017

$ cat /tmp/x.go
package p

func f() {
	_ = func() {
		var x int
	}
}
$ go get golang.org/x/tools/cmd/gotype
$ gotype /tmp/x.go
x.go:5:7: x declared but not used
x.go:5:7: x declared but not used
$ 

The error should be reported by go/types only once.

/cc @griesemer

@mvdan
Copy link
Member

mvdan commented Nov 1, 2017

The issue here is that we're checking the function literal scope twice. Ideally, we would know that this particular child of the f scope is a function literal that will be type-checked later, so we shouldn't recurse into it in Checker.usage. I haven't found a way to do that.

We could also keep a map of what scopes we have already type-checked to avoid duplicates, but that seems unnecessarily wasteful.

I don't see a clear fix here, so leaving it to someone else. Or, if anyone has any hints, I can have a second go at it.

@griesemer griesemer self-assigned this Nov 1, 2017
@gopherbot
Copy link

Change https://golang.org/cl/75251 mentions this issue: go/types: avoid repeated "declared but not used" errors for closure variables

@rsc
Copy link
Contributor Author

rsc commented Nov 2, 2017

Thanks for the quick fixes, @griesemer and @mvdan.

@golang golang locked and limited conversation to collaborators Nov 2, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants