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?

[bcmills]

@zacho314, the error message that we see is from an ImportMissingError:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/modload/import.go;l=54-56;drc=master

Generally when we see an ImportMissingError we attribute that to the package being imported, but in this case we want to also attribute the error to the importing package, since we can't tell whether the error is due to a missing standard-library package or a missing package to be provided by a replace directive.

I suspect that the point where we're reporting the error today is here:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/modload/load.go;l=1205;drc=master

What we need to propagate this error correctly is something like:
For each package pkg, if all of:

• pkg imports a package with an ImportMissingError for which isStd == true
• pkg.mod specifies a higher Go version than the current version,
• and pkg.err is nil,
  then set pkg.err to an error that indicates the mismatched version.

We already have a “for each package pkg” loop that also iterates over imports today in (*loader).buildStacks; that might be a decent place to put the above logic as well.

[lazerkat]

I plan on looking into this if @mzacho isn't actively working on it.

[gopherbot]

Change https://go.dev/cl/432075 mentions this issue: modload: provide a clearer compiler error for standard library packages from newer releases