cmd/compile: typechecker Go version and build-constraints Go version disagree

[LukeShu]

What version of Go are you using (go version)?

$ go version
go version go1.20 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/lukeshu/.cache/go-build"
GOENV="/home/lukeshu/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/lukeshu/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/lukeshu/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/lukeshu/btrfs/btrfs-tools/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 -fdebug-prefix-map=/run/user/1000/tmpdir/go-build2441700527=/tmp/go-build -gno-record-gcc-switches"

What did you do?

• go.mod:

  module local
  
  go 1.18
  

• main.go:

  package main
  
  import (
  	"reflect"
  )
  
  func main() {
  	f[reflect.Type]()
  }

• go118.go:

  //go:build !go1.20
  
  package main
  
  func f[T any]() {}

• go120.go:

  //go:build go1.20
  
  package main
  
  func f[T comparable]() {}

What did you expect to see?

I expected the program to successfully compile with either Go 1.18 or Go 1.20, offering stricter type-safety with Go 1.20.

While this flexibility isn't such a problem for standalone programs (as in the above reproducer), this is a problem for me trying to publish a library where I need the type parameter to be spec-comparable; for Go <1.20 it is appropriate to fall back to any and note in the documentation that it may panic if the type isn't spec-comparable; while for Go >=1.20 it is appropriate for the compiler to help check for mistakes and prevent non-spec-comparable type parameters.

If that example doesn't demonstrate the use-case to you, consider a library providing a type MyMap[K mapkey, v Any] struct{ … } with type mapkey = any for go:build !go1.20 and type mapkey = comparable for go:build go1.20.

I'll note that there was no mention of build-constraints in #56548. I'm not entirely sure how I think this should work, but I think that satisfying the go1.20 build constraint while disabling Go 1.20 features is definitely wrong.

What did you see instead?

The program fails to compile with Go 1.20:

$ go build
# local
./main.go:8:4: reflect.Type to satisfy comparable requires go1.20 or later (-lang was set to go1.18; check go.mod)

[zigo101]

It indeed compiles with Go 1.20. You just need to change the lang in go.mod to 1.20.

[Edit]: The go toolchain version build constraint and the lang version set in go.mod are independent with each other. That really looks some weird. But it looks that is the design. I also ever encountered one or two other subtle frustrating problems in the current go module implementation.

[dr2chase]

I think this may be working as intended, but pinging @rsc because this looks like at least a confusion-case.

[mknyszek]

In triage, we agree this is working as intended, but also that the distinction can be confusing. I'm not sure what the next steps are. Assigning to Russ for now, I guess?

[qiulaidongfeng]

See #59033, you can use the newer Go feature files in these files by using //go:build.

Isn't a semantic change a relatively new feature? Or am I misunderstood #59033?