runtime: Caller can return <autogenerated> as filename when called from a global variable

[pgimalac]

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

$ go version
go version devel go1.22-de5b418bea Sat Dec 2 03:15:03 2023 +0000 darwin/arm64

Does this issue reproduce with the latest release?

No, the issue appeared with 88cb17e (unreleased).

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

go env Output

$ go env
GO111MODULE='auto'
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/pierre.gimalac/Library/Caches/go-build'
GOENV='/Users/pierre.gimalac/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/pierre.gimalac/go/pkg/mod'
GONOPROXY='github.com/DataDog'
GONOSUMDB='github.com/DataDog,go.ddbuild.io'
GOOS='darwin'
GOPATH='/Users/pierre.gimalac/go'
GOPRIVATE='github.com/DataDog'
GOPROXY='binaries.ddbuild.io,proxy.golang.org,direct'
GOROOT='/tmp/dFNYRnSYTNDcoJjl/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/tmp/dFNYRnSYTNDcoJjl/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='devel go1.22-de5b418bea Sat Dec 2 03:15:03 2023 +0000'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/tmp/gist/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/zp/m8h1x16s30g3f656sxsdt7rm0000gp/T/go-build2626990949=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOROOT/bin/go version: go version devel go1.22-de5b418bea Sat Dec 2 03:15:03 2023 +0000 darwin/arm64
GOROOT/bin/go tool compile -V: compile version devel go1.22-de5b418bea Sat Dec 2 03:15:03 2023 +0000
uname -v: Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000
ProductName:		macOS
ProductVersion:		13.5.2
BuildVersion:		22G91
lldb --version: lldb-1403.0.17.67
Apple Swift version 5.8.1 (swiftlang-5.8.0.124.5 clang-1403.0.22.11.100)

What did you do?

When using the current dev version of Go, runtime.Caller can return <autogenerated> as caller filename, instead of the actual caller filename.

Minimal reproducible example can be found on https://github.com/pgimalac/gist/tree/go-runtime-caller-filename-autogenerated (I could not reduce it to a single file, but it's rather small as it is).

The example declares a global variable which indirectly calls runtime.Caller, which returns <autogenerated> instead of the actual filename.
A main function prints an error with the returned filename if it doesn't contain package1. It can run with go run main.go.

If this is not considered a bug, the documentation should make it clear that runtime.Caller can return something else when called from a global variable.

What did you expect to see?

runtime.Caller should return <root>/mypackage1/myfile.go.

What did you see instead?

runtime.Caller returns <autogenerated>.

[pgimalac]

I can still reproduce with 1.22.5 as well as 1.23rc1.

[randall77]

I'm not sure how we would fix this.

There's no file for this kind of init function (the kind that contains initialization code for all the global variables, not the kind the user declared with func init()). There's only one such function per package.
Imagine you had 2 files in mypackage1, each with a variable that needs initialization code. Which file does the init function get set to?

I guess we could generate an init function per file instead of per package. But that doesn't really work either, as initialization order can jump back and forth between files. So really we'd need one init function per global variable to be able to accurately give a file name. (Maybe that's not so horrible? Probably we could coalesce in the common case. It adds complexity, but maybe we'd have to do so anyway if we ever solve #14840?)

Note that you can use FuncForPC to get a function name, which would be mre/mypackage1.init in this case. Even better, use runtime.Callers + runtime.CallersFrames, it has the function info already there for you.

[pgimalac]

Thanks for the reply !

Indeed when you start looking into the internals it becomes much less obvious that this is a bug 😄
I opened this issue in particular because it used to work as I expected, and then stopped working, I probably wouldn't have opened it if it didn't work from the start !

From my side we stopped relying on this behavior when we noticed it changed, so I won't push for this to be fixed, up to you !