cmd/compile: "goto jumps over declaration" error is unclear for multiple jumped decls

[willfaught]

What did you do?

https://play.golang.org/p/anZpKB9l1ov

What did you expect to see?

prog.go:8:7: goto Default jumps over declaration of b1 at prog.go:9:5

(B1 is the first declaration (on line 9) following the goto.)

What did you see instead?

prog.go:8:7: goto Default jumps over declaration of b9 at prog.go:17:5

(B9 is the last declaration (on line 17) following the goto.)

It's confusing what this error means if you're not familiar with the goto variable scope rule, since there are lots of other variable decls in this example that are also skipped that are even closer to the goto statement.

System details

go version go1.11 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/will/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/will/Developer/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
GOROOT/bin/go version: go version go1.11 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.11
uname -v: Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G65
lldb --version: lldb-1000.11.37.1
  Swift-4.2

[cznic]

since there are lots of other variable decls in this example that are also skipped that are even closer to the goto statement.

That's a valid approach. OTOH, b9 is closest to the goto's target Default. That's also a perfectly valid approach.

[willfaught]

The issue wasn't validity, since the error is technically correct; it's that it left me thinking "why is it okay for b1–b8 but not b9"? The go compiler only reports 8 or so of the topmost (in terms of file position) errors before quitting altogether, so the current approach here of reporting the bottommost error is confusing because it suggests that there were no previous errors.

[cznic]

It's not okay for b1-b8. It would be ok iff when b9 is removed and compiler would then accept the code.

I think the compiler "discovers' the error only after finally seeing the label and then it intentionally reports the last and thus nearest jumped-over declaration. Reporting all of the others is definitely possible, the question is if that adds any value for the user. I don't think so.

[katiehockman]

/cc @randall77

[randall77]

It would be fine by me to report b1 instead of b9. I think it is a small improvement to report earlier decls, for the reason @willfaught described.
What I don't want is this:

prog.go:8:7: goto Default jumps over declaration of b1 at prog.go:9:5
prog.go:8:7: goto Default jumps over declaration of b2 at prog.go:10:5
prog.go:8:7: goto Default jumps over declaration of b3 at prog.go:11:5
prog.go:8:7: goto Default jumps over declaration of b4 at prog.go:12:5
prog.go:8:7: goto Default jumps over declaration of b5 at prog.go:13:5
prog.go:8:7: goto Default jumps over declaration of b6 at prog.go:14:5
prog.go:8:7: goto Default jumps over declaration of b7 at prog.go:15:5
prog.go:8:7: goto Default jumps over declaration of b8 at prog.go:16:5
prog.go:8:7: goto Default jumps over declaration of b9 at prog.go:17:5

It's unnecessary stutter, each less useful for fixing the problem than the last.

It would also be ok to do something like this, if there's more than one decl being jumped over:

prog.go:8:7: goto Default jumps over declarations, one of which is b9 at prog.go:17:5