Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
LukeShu opened this issue Feb 6, 2023 · 4 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@LukeShu
Copy link

LukeShu commented Feb 6, 2023

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)
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 6, 2023
@zigo101
Copy link

zigo101 commented Feb 6, 2023

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
Copy link
Contributor

dr2chase commented Feb 6, 2023

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

@prattmic prattmic added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 14, 2023
@mknyszek mknyszek added this to the Backlog milestone Feb 15, 2023
@mknyszek
Copy link
Contributor

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
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Development

No branches or pull requests

8 participants