cmd/go: using newer standard library APIs with an incompatible go version in go.mod does not produce error

[bmon]

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

$ go version
go version go1.17 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/brendan/.cache/go-build"
GOENV="/home/brendan/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/brendan/go/pkg/mod"
GOOS="linux"
GOPATH="/home/brendan/go"
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.17"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/brendan/git/go-mod-time-version/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2597690025=/tmp/go-build -gno-record-gcc-switches"

What did you do?

When using standard library APIs added in 1.17 (Time.UnixMilli() in my case), I had hoped that the toolchain would ask me to update the go directive in the go mod file, exactly as it did when adding go:embed directives.

reproduction case: https://github.com/bmon/go-mod-time-version/tree/75f34ebbfdc044550c5577a7aef3b86fc7547216

$ cat go.mod
module github.com/bmon/mod-time-version

go 1.15

$ go run time/main.go
1629343955534

$ go run embed/main.go
# command-line-arguments
embed/main.go:8:3: go:embed requires go1.16 or later (-lang was set to go1.15; check go.mod)

What did you expect to see?

I thought that the toolchain would ask me to modify the go version, exactly as it did with usage of go:embed

time/main.go:9: Time.UnixMilli() requires go1.17 or later (-lang was set to go1.15; check go.mod)

What did you see instead?

The module builds, and passes go mod tidy and go mod vet without any issue, despite incorrectly setting the go version in the mod file.

Apologies if this is a duplicate, I spent some time searching but I wasn't able to find an issue matching this request. The closest I found was #30241

[ianlancetaylor]

Related to #30639, which goes in the other direction.

[zikaeroh]

Also #46201 and #30791; depending on the definition, it could be interpreted that the only purpose of the version is to enable new language/toolchain features (and that it's legal to use newer versions in go.mod but still support older versions of Go with the right build tags, including new APIs/packages/etc).

[jayconrod]

Potential solution: #46136, though there are some unresolved issues.

[seankhliao]

#46136 was accepted and implemented.