compiler detects module based on current working directory

[rittneje]

Go version

go version go1.22.4 darwin/amd64

Output of go env in your module/workspace:

GO111MODULE='auto'
GOARCH='amd64'
GOBIN=''
GOCACHE='/tmp/.gocache'
GOENV='/Users/rittneje/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/rittneje/go/pkg/mod'
GONOPROXY='<redacted>'
GONOSUMDB='<redacted>'
GOOS='darwin'
GOPATH='/Users/rittneje/go'
GOPRIVATE='git.intra.lutron.com'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/rittneje/go1.22.4'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/Users/rittneje/go1.22.4/pkg/tool/darwin_amd64'
GOVCS='<redacted>'
GOVERSION='go1.22.4'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD=''
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 x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/kf/kr7_s3xx0l12zbj3jrn082hmzy5gvy/T/go-build3773258374=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

We originally noticed this issue because debug.ReadBuildInfo() was not reporting the expected value for DefaultGODEBUG.

It seems that go build will only detect that we are building a module if the current working directory is with the module root.

module godebugbug

go 1.22.4

package main

import (
	"fmt"
	"runtime/debug"
)

func main() {
	fmt.Println(debug.ReadBuildInfo())
}

What did you see happen?

It ignores go.mod completely, and uses the 1.21 DefaultGODEBUG settings.

Inside the module folder:
go build && ./godebugbug

go go1.22.4
path godebugbug
mod godebugbug (devel)
build -buildmode=exe
build -compiler=gc
build CGO_ENABLED=1
build CGO_CFLAGS=
build CGO_CPPFLAGS=
build CGO_CXXFLAGS=
build CGO_LDFLAGS=
build GOARCH=amd64
build GOOS=darwin
build GOAMD64=v1
true

Outside the module folder:
go build -o main ./godebugbug && ./main

go go1.22.4
path _/Users/jrittner/gomodtest/src/godebugbug
build -buildmode=exe
build -compiler=gc
build DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,panicnil=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
build CGO_ENABLED=1
build CGO_CFLAGS=
build CGO_CPPFLAGS=
build CGO_CXXFLAGS=
build CGO_LDFLAGS=
build GOARCH=amd64
build GOOS=darwin
build GOAMD64=v1
true

What did you expect to see?

It should instead detect it based upon the target package being within a module.

That is, if I run go build ./foo/bar/baz, where the go.mod file is located at ./foo/go.mod, then it should detect the module and build properly, using the DefaultGODEBUG that goes with the version of Go listed in the go.mod file.

[gabyhelp]

Similar Issues

• cmd/go: Module mode doesn't turn on automatically while build upon relative path #34043
• runtime/debug: ReadBuildInfo returns no information about main module #51918
• cmd/go: improve error when a package exists in the filesystem but is in a different module #30590
• cmd/go: only generate a new 'go.mod' file during 'go mod init' #29433
• cmd/go: module mode doesn't work without go.mod #26994
• go/build: resolve package in GOPATH when GO111MODULE=on outside module #34669
• cmd/go: 'go build' on a module absolute path while cwd is in GOPATH builds in GOPATH mode #27612
• x/website: #45769
• go build ignores GoVersion in go.mod file #58420
• cmd/go: improve diagnostics for mod subcommands within $GOPATH/src #26365

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[rittneje]

Adding to the confusion, the 1.22 compiler will compile with 1.22 loop semantics when it cannot find the go.mod file, even though it will also use the 1.21 DefaultGODEBUG.

[seankhliao]

I believe this is working as intended for your setting of GO111MODULE=auto where it falls back to GOPATH mode if a module is not found.
The default setting is GO111MODULE=on, which should report an error like:

go: go.mod file not found in current directory or any parent directory; see 'go help modules'

Using the module based on the go command is the intended behaviour, see also the -C flag.

[rittneje]

@seankhliao then the behavior ought to be revisited, as it is completely undesirable and unexpected. The toolchain should go by the go.mod file for the code being built; the current working directory should never be relevant.