x/tools/go/analysis/passes/nilness: incorrect "impossible condition: nil != nil"; missing tautological error

[hut8]

Go version

go version go1.23.0 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/liam/.cache/go-build'
GOENV='/home/liam/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/liam/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/liam/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.0'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/liam/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/liam/nilness-bug/go.mod'
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 -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1057087488=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I believe there is a bug in the nilness checker that incorrectly reports an impossible "nil != nil" and also omits an error in a different location about a tautological comparison. This code demonstrates it:

package main

import "fmt"

func TriggerBug(a *struct{}) {
	hasA := a != nil // "impossible condition: nil != nil"
	if hasA {
		fmt.Println("A is not nil")
		return
	}
	if !hasA {
		fmt.Println("A is nil")
	}
}

I checked here: https://github.com/golang/go/issues?page=1&q=is%3Aissue+is%3Aopen+nilness and I can't find anything that matches.

What did you see happen?

	hasA := a != nil // "impossible condition: nil != nil"

Here is a screenshot for clarity:

What did you expect to see?

The above error implies that a is always nil and therefore a != nil will never happen. That is not true. However, there still is a problem with the code. Because of the return, then the if !hasA is tautological -- although, that's a different error, and it's not reported, and the error that is reported is not only erroneous but also in the wrong place.

This, for example, correctly reports no errors:

func TriggerBug(a *struct{}) {
	hasA := a != nil
	if hasA {
		fmt.Println("A is not nil")
		return
	}

	fmt.Println("A is nil")
}

So I would expect to see something like this:

func TriggerBug(a *struct{}) {
	hasA := a != nil
	if hasA {
		fmt.Println("A is not nil")
		return
	}
	// at this point, hasA is definitely false
	if !hasA { //  "tautological condition: nil == nil"
		fmt.Println("A is nil")
	}
}

Interestingly, if I just get rid of hasA and put the expression directly in the if statement, I get:

func TriggerBug(a *struct{}) {
	if a != nil {
		fmt.Println("A is not nil")
		return
	}
	if a == nil { // tautological condition: nil == nil
		fmt.Println("A is nil")
	}
}

That's what I would expect to see whether or not I have the boolean value broken out into a different variable.

[gabyhelp]

Related Issues

• x/tools/go/analysis/passes/nilness: bogus "impossible condition: non-nil == nil" that is actually possible #66835 (closed)
• x/tools/go/analysis/passes/nilness: not report slice as non-nil #45177 (closed)
• affected/package: go1.20.1 When obtaining a "nil" value after defining an interface, it is not recognized as an empty value during condition checks. #59521 (closed)
• conflict behavior when comparing nil and (*SturctName)(nil) #35413 (closed)
• nil literal should not be parsed as ast.Ident #28918 (closed)
• builtin/error: late assignment of custom error type cause nil checking of the error variable not working #53768 (closed)
• `err != nil` when `err == nil` with custom `error` type #35292 (closed)
• The result of a nil pointer type not equal nil is true, is that right? #44102 (closed)
• crypto/x509: The if's condition checks that err is not nil but returns nil #49135 (closed)
• proposal: cmd/vet: do not warn about nil comparisons after for loop #28871 (closed)

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