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

$ go version
go version go1.21.4 darwin/arm64

Does this issue reproduce with the latest release?

Yes (1.21.4)
It doesn't reproduce with Go 1.20.x.
On the current main branch, it is shadowed by the issue described in #64520 (but I still opened this separate issue as I'm not sure whether fixing the other one would fix this one, and this one appears in a released version).

It also reproduces on different OS and architectures (eg. linux/amd64)

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

$ 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='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.21.4'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/tmp/pKsOoeSDXncWwAsv/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-build1790875425=/tmp/go-build -gno-record-gcc-switches -fno-common'
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 Go 1.21, when running test with coverage enabled, runtime.Caller can return covervars.go as caller filename, instead of the actual caller filename.

A minimal reproducible example can be found on https://github.com/pgimalac/gist/tree/go-runtime-caller-filename-covervars-go (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 covervars.go instead of the actual filename.
The bug is triggered by running go test ./... -cover, a test which checks that the filename contains package1 will fail.

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 when running in a test with coverage enabled.

What did you expect to see?

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

What did you see instead?

runtime.Caller returns covervars.go.