Closed
Description
Repro, originating from @adonovan's investigation of #68744:
> cat bad.go
package main
import "fmt"
func main() {
fmt.Printf("%s", 123)
wrapf("%s", 123)
}
func wrapf(format string, args ...any) {
fmt.Printf(format, args...)
}
> 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=0 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
When GODEBUG=gotypesalias=1 (the default in 1.23), the printf analyzer fails to report a diagnostic for the wrapf
printf wrapper, due to a missing call to types.Unalias
.
Separately, it appears the default vet tool distributed with 1.23rc2 (or built on the release branch with make.bash
) does not have GODEBUG=gotypesalias=1. Otherwise, this should have been caught by the vet integration tests. I will file a separate issue for that.
It may be the case that the two bugs mentioned in the previous two paragraphs effectively cancel themselves out for the Go distribution. However, I think we should at least block the release until we understand both better.
Metadata
Metadata
Labels
Type
Projects
Status
Done