<p dir="auto">gorename reports a variable as being unused when the variable is assigned in a closure. go build will compile the code without complaining.</p>
<p dir="auto">Error reported by gorename:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="11:50 $ gorename -offset rotator.go:#831 -to TimeFormat
/home/iand/src/code.avct.io/services/log/rotator.go:398:6: s declared but not used
gorename: couldn't load packages due to errors: code.avct.io/services/log"><pre class="notranslate"><code class="notranslate">11:50 $ gorename -offset rotator.go:#831 -to TimeFormat
/home/iand/src/code.avct.io/services/log/rotator.go:398:6: s declared but not used
gorename: couldn't load packages due to errors: code.avct.io/services/log
</code></pre></div>
<p dir="auto">Can reproduce with code like this:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="func Scan() {
    var s string

    tester(func() {
        s = &quot;done&quot;
    })
}

func tester(fn func()) {
    fn()
}"><pre class="notranslate"><code class="notranslate">func Scan() {
    var s string

    tester(func() {
        s = "done"
    })
}

func tester(fn func()) {
    fn()
}
</code></pre></div>
<p dir="auto">go version go1.6 linux/amd64<br>
golang.org/x/tools commit <a class="commit-link" data-hovercard-type="commit" data-hovercard-url="https://github.com/golang/go/commit/6f233b96dfbc53e33b302e31b88814cf74697ff6/hovercard" href="https://github.com/golang/go/commit/6f233b96dfbc53e33b302e31b88814cf74697ff6"><tt>6f233b9</tt></a></p>
<p dir="auto">This renders gorename unusable if any of the GOPATH contains this pattern of code, even though it compiles fine with the go command.</p>
<pre class="notranslate">For this program:
  <a href="http://play.golang.org/p/BzMO7Vt3uy" rel="nofollow">http://play.golang.org/p/BzMO7Vt3uy</a>
  switch x := interface{}(nil).(type) {}
go/types reports an error but gc does not.

I realize the spec does not say what should happen here, but the fact of this
implementation-specific behaviour is that we have two dialects of Go whose tools reject
each others' programs.

We should probably make the tools consistent one way or another.
I would also argue in favour of removing this hole in the spec.</pre>