cmd/compile: go build panics when 'len' keyword was unintentionally shadowed

[harikb]

What version of Go are you using (go version)?

go version go1.11.1 darwin/amd64
(Also occured on go version go1.11 darwin/amd64)

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Mac OS X 10.12.6

What did you do?

go build

Exact steps are here (fix is not pushed yet, so that code will still break)
https://play.golang.org/p/Xt3wlYYucAZ . (Not Go code, but a shell session)

What did you expect to see?

Apparently, as per go 1.10.3 (from Slack), the error message should have been

[I] meta@keynsham ~/P/G/s/g/h/p/c/pghash> go version
go version go1.10.3 darwin/amd64
[I] meta@keynsham ~/P/G/s/g/h/p/c/pghash> go build
# github.com/harikb/pghash/lib/pghash
../../lib/pghash/pghash.go:60:18: cannot call non-function len (type uint32)
[I] meta@keynsham ~/P/G/s/g/h/p/c/pghash> 

What did you see instead?

$ go build
# github.com/harikb/pghash/lib/pghash
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x70 pc=0x177c96e]

goroutine 1 [running]:
cmd/compile/internal/gc.typecheck1(0xc00037c180, 0x2, 0xc00037b680)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:1270 +0x3ece
cmd/compile/internal/gc.typecheck(0xc00037c180, 0x2, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6ad
cmd/compile/internal/gc.typecheck1(0xc00037c100, 0x2, 0x10)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:1711 +0x4781
cmd/compile/internal/gc.typecheck1(0xc00037c100, 0x2, 0xc000378f00)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:1229 +0x39d9
cmd/compile/internal/gc.typecheck(0xc00037c100, 0x2, 0xc000378f00)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6ad
cmd/compile/internal/gc.typecheckas(0xc00037c000)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:3336 +0xa4
cmd/compile/internal/gc.typecheck1(0xc00037c000, 0x1, 0xc00037bf00)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:1985 +0x332a
cmd/compile/internal/gc.typecheck(0xc00037c000, 0x1, 0xc00037bf00)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6ad
cmd/compile/internal/gc.typecheckslice(0xc00037c200, 0x10, 0x10, 0x1)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:68 +0x50
cmd/compile/internal/gc.Main(0x18c1300)
	/usr/local/go/src/cmd/compile/internal/gc/main.go:518 +0x2059
main.main()
	/usr/local/go/src/cmd/compile/main.go:51 +0x96

[harikb]

After applying the following fix (patch file) to the code, the build went through just fine
Fixes to main.go are irrelevant to the problem.

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

[bradfitz]

This appears to be fixed at tip.

@odeke-em, @griesemer, is there something to backport to Go 1.11?

[harikb]

Sorry I did not include go env output. Here it is

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hbhaskar/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/hbhaskar/code"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-L/usr/local/lib"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/s_/mh6lcqcs33z1dp8gytlf05pc0000gn/T/go-build648323542=/tmp/go-build -gno-record-gcc-switches -fno-common"

[ALTree]

This has already been selected for a 1.11 backport: #27399, but for some reason it wasn't included in 1.11.1, it was moved (with a few others) on a future 1.11.2

[bradfitz]

Bummer. Not sure why that wasn't included in Go 1.11.1.

Will close this one as a duplicate of that.

/cc @andybons @katiehockman @dmitshur

[katiehockman]

I'm checking my terminal logs, and I can see that releasebot moved issue #27399 over from Go 1.11.1 to Go 1.11.2 yesterday when I ran releasebot -mode=release go1.11.1. I'll investigate why that happened, since it looks like that issue was both closed and tagged by the time that the command was run.

[katiehockman]

The reason it wasn't added to 1.11.1 is because a cherrypick CL was not merged for #27399, thus the issue was still open when the release occurred. Open issues like that one are moved to the next minor release (in this case, 1.11.2). If we want to get this into 1.11.2 then someone should create the cherry pick CL and merge it into the release1.11 branch, thus closing #27399.

See https://github.com/golang/go/wiki/MinorReleases for more details.

[ALTree]

Sigh, I tried to send the cherry-pick CL -so we don't forget again-, but apparently only the change author (and I assume the go devs) can do that.