cmd/compile: gc inconsistent about reporting "unused variable" errors

[adonovan]

For this program:
  http://play.golang.org/p/BzMO7Vt3uy
  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.

[griesemer]

Comment 1:

gccgo also complains about this as an unused variable:
$ gccgo x.go
x.go:4:9: error: 'x' declared and not used
  switch x := interface{}(nil).(type) {
         ^
The spec makes this an implementation restriction, but go/types and gccgo agree with how
the implementation restriction should be applied in this case. Making this a cmd/gc bug.

Labels changed: added release-none, repo-main.

Status changed to Accepted.

[adg]

Comment 2:

This program should generate the error "p declared but not used":
package main
func main() {
        p := true
        func() {
                p = true
        }()
}
If you remove the closure, the compiler raises the error.

[gopherbot]

CL https://golang.org/cl/10757 mentions this issue.

[rsc]

This is in milestone Unplanned. By my assignment should I infer you are requesting we reprioritize it? Normally Unplanned things have no assignee.

[alandonovan]

Yes, that's what I meant. (Sorry if that was unclear or seemed passive-aggressive.)

[rsc]

OK, reprioritized to Go 1.7, but that's still no guarantee.

[gopherbot]

CL https://golang.org/cl/23528 mentions this issue.

[odeke-em]

@adg your report in https://github.com/golang/go/issues/8560#issuecomment-66097949 was a bug that was already reported at https://github.com/golang/go/issues/3059, in case you are interested in tracking that case.

[jim-minter]

Out of interest, are there any known workarounds for the gorename issue #14596 (short of not using closures in this way across a codebase) that can be used to enable use of gorename in codebases such as that before this issue is resolved?

[gopherbot]

CL https://golang.org/cl/29853 mentions this issue.

[griesemer]

Marked NeedsInvestigation since we need to re-establish the current facts.

[griesemer]

The Go 1.18 compiler correctly reports errors in these cases. Per #49214 we will accept the correct behavior for 1.18 and document it in the release notes.