cmd/go: bootstrapped vet tool for 1.23 lacks GODEBUG=gotypesalias=1

[findleyr]

As reported in #68796, it appears that the cmd/vet built by make.bash lacks GODEBUG=gotypesalias=1, which should have been the default in 1.23. See below: the bug of #68796 only appears if GODEBUG=gotypesalias=1 is explicitly set in the environment, or if cmd/vet is reinstalled (apparently, reinstalling picks up the correct GODEBUG defaults).

While I think #68796 is a release blocker, this may not be a release blocker: if cmd/vet works as expected, it doesn't really matter which gotypesalias value it observes.

> go version
go version go1.23rc2 linux/amd64
> go vet bad.go 
# command-line-arguments
# [command-line-arguments]
./bad.go:6:2: fmt.Printf format %s has arg 123 of wrong type int
./bad.go:7:2: command-line-arguments.wrapf format %s has arg 123 of wrong type int
> GODEBUG=gotypesalias=1 go vet bad.go 
# command-line-arguments
# [command-line-arguments]
./bad.go:6:2: fmt.Printf format %s has arg 123 of wrong type int
> go install cmd/vet
> go vet bad.go
# command-line-arguments
# [command-line-arguments]
./bad.go:6:2: fmt.Printf format %s has arg 123 of wrong type int

CC @matloob @samthanawalla

[gabyhelp]

Related Issues and Documentation

• cmd/vet,x/tools/go/analysis/passes/printf: broken with GOTYPESALIAS=1 #68796
• go/types, types2: audit type assertions for potential Alias bugs #67547 (closed)
• cmd/vet: false positives and wrong types across files, needs automatic recursive checking #20514 (closed)
• cmd/vet: Printf format %.T has unrecognized flag #30363

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

[findleyr]

@adonovan notices the following:

> go version -m $(which go)
/usr/local/google/home/rfindley/src/go/bin/go: go1.23rc2
        path    cmd/go
        build   -buildmode=exe
        build   -compiler=gc
        build   -gcflags=cmd/...=-dwarf=false
        build   -trimpath=true
        build   DefaultGODEBUG=asynctimerchan=1,gotypesalias=0,httplaxcontentlength=1,httpmuxgo121=1,httpservecontentkeepheaders=1,netedns0=0,panicnil=1,tls10server=1,tls3des=1,tlskyber=0,tlsrsakex=1,tlsunsafeekm=1,winreadlinkvolume=0,winsymlink=0,x509keypairleaf=0,x509negativeserial=1
        build   CGO_ENABLED=0
        build   GOARCH=amd64
        build   GOOS=linux
        build   GOAMD64=v1

Note the value of DefaultGODEBUG has gotypesalias=0. That is wrong. Marking as a release blocker until we understand better.

[ianlancetaylor]

I know I'm confused, but I thought that gotypesalias=1 was going to be the default for 1.24, not for 1.23.

[adonovan]

I know I'm confused, but I thought that gotypesalias=1 was going to be the default for 1.24, not for 1.23.

Typically when you say you're confused, it's because I am mistaken and have confused you, but not in this instance:

https://tip.golang.org/doc/go1.23#gotypespkggotypes:

By default, go/types now produces Alias type nodes for type aliases. This behavior can be controlled by the GODEBUG gotypesalias flag. Its default has changed from 0 in Go 1.22 to 1 in Go 1.23.

I had to check to convince myself. ;-)

[hyangah]

@adonovan notices the following:

> go version -m $(which go)
/usr/local/google/home/rfindley/src/go/bin/go: go1.23rc2
        path    cmd/go
        build   -buildmode=exe
        build   -compiler=gc
        build   -gcflags=cmd/...=-dwarf=false
        build   -trimpath=true
        build   DefaultGODEBUG=asynctimerchan=1,gotypesalias=0,httplaxcontentlength=1,httpmuxgo121=1,httpservecontentkeepheaders=1,netedns0=0,panicnil=1,tls10server=1,tls3des=1,tlskyber=0,tlsrsakex=1,tlsunsafeekm=1,winreadlinkvolume=0,winsymlink=0,x509keypairleaf=0,x509negativeserial=1
        build   CGO_ENABLED=0
        build   GOARCH=amd64
        build   GOOS=linux
        build   GOAMD64=v1

Note the value of DefaultGODEBUG has gotypesalias=0. That is wrong. Marking as a release blocker until we understand better.

I am confused.
Isn't it expected when the go binary is built with the bootstrap go (<go1.23)? Or are toolchain binaries of go1.N supposed to be rebuilt with go1.N to pick up new GODEBUG (some may not be known to the bootstrap go)?

[dmitshur]

I believe the latter is intended, see here and here.

My current (and possibly mistaken or only partial) understanding of what's happening is that the cmd/go binary is built in a temporary work directory that has a go.mod file (to fix #44209), and that go.mod file doesn't contain a go directive, so cmd/go ends up falling back to the default of 1.16. At tip, including "go 1.24" in that temporary go.mod file seems to be enough to fix the original reproducer.

 workdir = xworkdir()
-if err := os.WriteFile(pathf("%s/go.mod", workdir), []byte("module bootstrap"), 0666); err != nil {
+if err := os.WriteFile(pathf("%s/go.mod", workdir), []byte("module bootstrap\ngo 1.24\n"), 0666); err != nil {
 	fatalf("cannot write stub go.mod: %s", err)
 }

[findleyr]

Based on internal discussions, it sounds like we're comfortable with the status quo for 1.23, since this GODEBUG issue has existed since Go 1.17. We can fix for 1.24. Then we also don't need to backport the fix for #68796 to 1.23. Thanks everyone for your help with the urgent investigation here.

[ianlancetaylor]

Thanks for the explanations, sorry for the noise.

[gopherbot]

Change https://go.dev/cl/604799 mentions this issue: cmd/dist: set go version in bootstrap go.mod file