runtime: panic stack trace includes closure from method value

[jdef]

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

go version go1.10 linux/amd64

Does this issue reproduce with the latest release?

yes

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/vagrant/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/vagrant/workspace-dss"
GORACE=""
GOROOT="/usr/local/go-1.10"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go-1.10/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build161669454=/tmp/go-build -gno-record-gcc-switches"

What did you do?

It's may also be reproduced by examining the call stack of a panic. For example:
https://play.golang.org/p/579SSX2Vx5t

What did you expect to see?

hi
panic: stack trace

goroutine 1 [running]:
main.Func.Bar(0x11d5a8, 0x1738e0)
	/tmp/sandbox941741331/main.go:19 +0x60
main.Func.Foo(0x1040c128, 0x0)
	/tmp/sandbox941741331/main.go:11 +0x40
main.main()
	/tmp/sandbox941741331/main.go:25 +0x80

What did you see instead?

hi
panic: stack trace

goroutine 1 [running]:
main.Func.Bar(0x11d5a8, 0x1738e0)
	/tmp/sandbox941741331/main.go:19 +0x60
main.(Func).Bar-fm()
	/tmp/sandbox941741331/main.go:24 +0x40
main.Func.Foo(0x1040c128, 0x0)
	/tmp/sandbox941741331/main.go:11 +0x40
main.main()
	/tmp/sandbox941741331/main.go:25 +0x80

This is a problem for code that expects to reliably count frames on the stack based on the function calls actually made (e.g. logging modules that want to track file/line of the caller). When artificial frames are injected into the call stack (due to passing around a function reference and later invoking it) this becomes confusing and hard to deal with when attempting to determine the file/line of the caller. It also seems semantically incorrect: the assignment of func Bar to a variable IS NOT a call to the function, so it should not be in the caller stack.

[jdef]

To be clear, this was first observed when troubleshooting a failing unit test on a project that was attempting to use runtime.Caller. The reproduction use case using panic seemed more concise, so that's what I linked to. If needed I can provide a reproduction using runtime.Caller instead.

[bcmills]

Per https://golang.org/ref/spec#Method_values:

These two invocations are equivalent:

t.Mv(7)
f := t.Mv; f(7)

That does seem to imply that the method value should not be treated as a separate function call.

[bcmills]

See also #16723.
(CC: @aclements)

[gopherbot]

Change https://golang.org/cl/153477 mentions this issue: runtime: proper panic tracebacks with mid-stack inlining