cmd/go: missing version diagnostic when a package in the main module imports a package from a newer release

[andig]

Given

module example.com/M

go 1.16

and using embed as part of that module, I'm experiencing a lot of user's questions where compilation fails due to go versions below 1.16. Having declared dependency on go1.16 syntax/libraries as part of go.mod it would be nice if the compiler would fail if the module version of the main module or it's dependencies are not met during build. It could be optional behaviour behind a flag.

I realise this might cause breakage for modules who's authors use the highes available go version as part of their go.mod to be "compatible", but that approach seems flawed anyway.

[bcmills]

What kind of errors are your users reporting? When the build fails, they should be getting an explicit notice about the version mismatch already.

[bcmills]

(Also compare #46136.)

[andig]

What kind of errors are your users reporting? When the build fails, they should be getting an explicit notice about the version mismatch already.

From evcc-io/evcc#1303:

pi@evcc:/opt/repos/evcc/evcc $ go build ./...
build github.com/andig/evcc: cannot find module for path embed 

For an end user that tries to self-compile its impossible to relate this error in a mismatching go version.

[bcmills]

That report is from

go version go1.11.6 linux/arm

That version of Go is way out of date: per the Go project's release policy, the current supported versions of the toolchain are 1.16.9 and 1.17.2.

Any change we would make at this point would only affect 1.18 and later, and I posit that the supported versions of the toolchain already produce a much more useful diagnostic in this case.

[bcmills]

Hmm... It is the case that go1.15.15 (the last release that did not include the embed package) still produces a pretty useless error here:

/tmp/evcc$ go1.15.15 build ./...
main.go:4:2: package embed is not in GOROOT (/usr/local/google/home/bcmills/sdk/go1.15/src/embed)
/usr/local/google/home/bcmills/pkg/mod/github.com/evcc-io/eebus@v0.0.0-20211004203943-949a5847f2ea/cert/cert.go:16:2: package io/fs is not in GOROOT (/usr/local/google/home/bcmills/sdk/go1.15/src/io/fs)

It looks like the failure in module resolution is before the failure due to the Go version.

And if we construct a similar situation with some new 1.18 package using Go 1.17.2, we still get a bad error message:

$ go1.17.2 build .
main.go:3:8: package constraints is not in GOROOT (/usr/local/google/home/bcmills/sdk/go1.17.2/src/constraints)

-- go.mod --
module example

go 1.18
-- main.go --
package main

import _ "constraints"

func main() {}

So there is a bug to be fixed here — but it's just a bug, it doesn't need to go through the proposal process.

[andig]

Note https://github.com/theckman/goconstraint/ for a go-only compile time solution.

[mzacho]

I'd like to look into this issue - @bcmills do you have some pointers on how to fix it?