nil is not a valid go/constant Value. In general, we don't describe in every package that nil is not valid - we usually describe when nil is valid. We also don't test every single impossible value (see https://play.golang.org/p/O62KzUF86T for instance). The documentation says "The comparison must be defined for the operands." - admittedly vague but it's clear to expect the unexpected otherwise.

@griesemer Should I file a bug for go/ssa instead, or is it also expected that an *ssa.Const.Value can be nil?

In retrospect I agree that the error message is wrong: That code clearly is reachable after all, even if it means incorrect input. I will fix that.

And yes, if go/ssa produces a nil constant Value it probably should say that either nil is possible and means "no constant value", or there's a bug (documentation or otherwise).

I.e. is https://play.golang.org/p/ONBGaMJD1d valid and expected to disagree with go/constant's definition of a valid Value?

The ssa and go/constant packages are both working as intended.

The constant package does not allow nil operands to its functions. (When a Go function accepts optional arguments or nil, this is usually explicitly documented and in the absence of documentation it should be assumed unsafe.)

The ssa package uses a nil constant.Value to indicate a typed nil value, even though nil is not a constant according to the language spec. See https://godoc.org/golang.org/x/tools/go/ssa#Const:

[...] a Const may represent the nil value of any reference type---interface, map, channel, pointer, slice, or function---but not "untyped nil". [...] Value holds the exact value of the constant, independent of its Type(), using the same representation as package go/exact uses for constants, or nil for a typed nil value.

As a result, you must check the ssa.Const.Value field is non-nil before passing it to a function such as constant.Compare.

CL https://golang.org/cl/32870 mentions this issue.

CL https://golang.org/cl/32872 mentions this issue.