Go version
go version go1.24.5 windows/amd64
Output of go env in your module/workspace:
set AR=ar
set CC=gcc
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_ENABLED=0
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set CXX=g++
set GCCGO=gccgo
set GO111MODULE=
set GOAMD64=v1
set GOARCH=amd64
set GOAUTH=netrc
set GOBIN=
set GOCACHE=C:\Users\***\AppData\Local\go-build
set GOCACHEPROG=
set GODEBUG=
set GOENV=C:\Users\***\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFIPS140=off
set GOFLAGS=
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\***\AppData\Local\Temp\go-build548994352=/tmp/go-build -gno-record-gcc-switches
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMOD=NUL
set GOMODCACHE=C:\Users\***\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\***\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTELEMETRY=local
set GOTELEMETRYDIR=C:\Users\***\AppData\Roaming\go\telemetry
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.24.5
set GOWORK=
set PKG_CONFIG=pkg-config
What did you do?
PS D:\Desktop\NEW\Go\go> go mod init go
What did you see happen?
go: creating new go.mod: module go
panic: go: internal error: missing go root module
goroutine 1 [running]:
cmd/go/internal/modload.mustHaveGoRoot(...)
cmd/go/internal/modload/buildlist.go:104
cmd/go/internal/modload.newRequirements(0xc0?, {0xc00010f3a0?, 0x1616c0e?, 0x2?}, 0x20b4bff05a0?)
cmd/go/internal/modload/buildlist.go:118 +0x6f8
cmd/go/internal/modload.updatePrunedRoots({0x1743560, 0x1bb3560}, 0xc0001b73e0, 0xc000178140, {0x0, 0x0, 0xc00011d100?}, {0x0, 0x0, 0x0}, ...)
cmd/go/internal/modload/buildlist.go:1236 +0xb68
cmd/go/internal/modload.updateRoots({0x1743560?, 0x1bb3560?}, 0x1738f6a?, 0x6?, {0x0?, 0x1?, 0x16196f1?}, {0x0, 0x0, 0x0}, ...)
cmd/go/internal/modload/buildlist.go:796 +0xba
cmd/go/internal/modload.CreateModFile({0x1743560, 0x1bb3560}, {0xc000116100, 0x2})
cmd/go/internal/modload/init.go:1126 +0x7f4
cmd/go/internal/modcmd.runInit({0x1743560?, 0x1bb3560?}, 0xc000159848?, {0xc0001240f0?, 0x1616bc0?, 0x1617a33?})
cmd/go/internal/modcmd/init.go:48 +0x8c
main.invoke(0x1b5e340, {0xc0001240e0, 0x2, 0x2})
cmd/go/main.go:341 +0x845
main.main()
cmd/go/main.go:220 +0xe6b
What did you expect to see?
Maybe create successfully or alert that the name is invalid and add it to Go Document.
Comment From: mrkfrmn
CC @golang/command-line from owners.
Comment From: gopherbot
Change https://go.dev/cl/691515 mentions this issue: cmd/go: explicitly reject module paths "go" and "toolchain"
Comment From: Dev-BilalMunir
Hi,
I’m interested in contributing to this issue (#74784) as it’s a clear bug in cmd/go that affects module initialization. I’ve reproduced the panic on my Mac with go mod init go using Go 1.23.5, and I believe adding input validation in cmd/go/internal/modcmd/init.go to reject the reserved module name "go" with a user-friendly error could resolve it.
Since the issue is labeled FixPending, is anyone actively working on a fix, or is it open for contributions? I’d also like to propose updating the Go modules documentation to clarify reserved module names. Please let me know if this approach aligns with the maintainers’ expectations or if there’s an existing PR I should coordinate with.
Thanks!
Comment From: matloob
@Dev-BilalMunir I have a CL in review to fix the issue in the go command (see gopherbot’s comment https://github.com/golang/go/issues/74784#issuecomment-3133607982) but we’d definitely appreciate documentation contributions!
In general we discourage module paths that don’t have a dot because they can’t be fetched (it can’t be a domain for a git repo, proxy, or page with a meta tag), but the toolchain and go module paths have a special meaning post Go 1.21 and the go command will just not work with them.