Closed
Description
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.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
bcmills commentedon Oct 14, 2021
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 commentedon Oct 14, 2021
(Also compare #46136.)
andig commentedon Oct 14, 2021
From evcc-io/evcc#1303:
For an end user that tries to self-compile its impossible to relate this error in a mismatching go version.
bcmills commentedon Oct 14, 2021
That report is from
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 commentedon Oct 14, 2021
Hmm... It is the case that
go1.15.15
(the last release that did not include theembed
package) still produces a pretty useless error here: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:
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.
[-]go/build: proposal to fail if go.mod version is higher than go compiler version[/-][+]cmd/go: poor diagnostic when the main module specifies a newer Go version and imports a newly-added package[/+][-]cmd/go: poor diagnostic when the main module specifies a newer Go version and imports a newly-added package[/-][+]cmd/go: missing version diagnostic when the main module specifies a newer Go version and imports a newly-added package[/+][-]cmd/go: missing version diagnostic when the main module specifies a newer Go version and imports a newly-added package[/-][+]cmd/go: missing version diagnostic when a package in the main module imports a package from a newer release[/+]andig commentedon Oct 26, 2021
Note https://github.com/theckman/goconstraint/ for a go-only compile time solution.
mzacho commentedon Jan 10, 2022
I'd like to look into this issue - @bcmills do you have some pointers on how to fix it?
bcmills commentedon Jan 10, 2022
@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 areplace
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 anImportMissingError
for whichisStd == true
pkg.mod
specifies a higher Go version than the current version,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 commentedon Sep 15, 2022
I plan on looking into this if @mzacho isn't actively working on it.
gopherbot commentedon Sep 20, 2022
Change https://go.dev/cl/432075 mentions this issue:
modload: provide a clearer compiler error for standard library packages from newer releases
modload: provide a clearer error for standard library packages from n…
modload: provide a clearer error for standard library packages from n…