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)
 }