cmd/go: "module requires Go 1.12" error when building with Go 1.11.3 or earlier

[markbates]

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

Downloading: https://storage.googleapis.com/golang/go1.11.linux-amd64.tar.gz
Extracting archive
[command]/bin/tar xzC /home/vsts/work/_temp/1c8530c4-eae3-4887-a554-cae13254c039 -f /home/vsts/work/_temp/86ea4780-4861-4208-9eee-76c050c1dcec
Caching tool: go 1.11.0 x64
Prepending PATH environment variable with directory: /opt/hostedtoolcache/go/1.11.0/x64/bin

Does this issue reproduce with the latest release?

No

What operating system and processor architecture are you using (go env)?

go env Output

go1.11.linux-amd64
https://dev.azure.com/markbates/buffalo/_build/results?buildId=412

What did you do?

I rebuilt the go.mod file for gobuffalo/buffalo (https://github.com/gobuffalo/buffalo/pull/1610/files) using go1.12. In doing so it added go 1.12 to the top of the go.mod:

module github.com/gobuffalo/buffalo

go 1.12

When attempting to test this on CI with any variation of GOOS (windows, Mac, linux), go1.11 and GO111MODULES=on, I get errors telling me that module requires Go 1.12

PR: https://github.com/gobuffalo/buffalo/pull/1610/files
CI: https://dev.azure.com/markbates/buffalo/_build/results?buildId=412

What did you expect to see?

I expected my tests to pass as they had previously done before the go.mod file was modified.

What did you see instead?

go build github.com/gobuffalo/buffalo/render: module requires Go 1.12
go build github.com/gobuffalo/buffalo/binding: module requires Go 1.12
go build github.com/gobuffalo/buffalo/runtime: module requires Go 1.12
go build github.com/gobuffalo/buffalo/servers: module requires Go 1.12
go build github.com/gobuffalo/buffalo/worker: module requires Go 1.12
go build github.com/gobuffalo/buffalo/binding: module requires Go 1.12
go build github.com/gobuffalo/buffalo/buffalo/cmd/destroy: module requires Go 1.12
go build github.com/gobuffalo/buffalo/packrd: module requires Go 1.12
go build github.com/gobuffalo/buffalo/genny/grift: module requires Go 1.12
go build github.com/gobuffalo/buffalo/genny/grift: module requires Go 1.12
go build github.com/gobuffalo/buffalo/grifts: module requires Go 1.12
go build github.com/gobuffalo/buffalo/mail/internal/mail: module requires Go 1.12
go build github.com/gobuffalo/buffalo/render: module requires Go 1.12
go build github.com/gobuffalo/buffalo/worker: module requires Go 1.12

[bradfitz]

So change your module file to say go 1.11.

If you deleted your module, it initializes it to the language version you're working with.

[markbates]

So if it says 1.12 than those using 1.11 can’t build, even if the code is compatible?

…

----------- Mark Bates

On Feb 27, 2019, 4:03 PM -0500, Brad Fitzpatrick ***@***.***>, wrote: So change your module file to say go 1.11. If you deleted your module, it initializes it to the language version you're working with. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[bradfitz]

Yes. That's working as designed. That's the mechanism by which we can evolve the language.

If your intention is for your code to have Go 1.11 semantics and work with Go 1.11, declare it there in your go.mod.

[lukasschlueter]

https://golang.org/doc/go1.12#modules states the following:

If the go directive for a module specifies a version newer than the toolchain in use, the go command will attempt to build the packages regardless, and will note the mismatch only if that build fails.

Wouldn't that apply in this case, meaning it should still compile with 1.11 in this case?

[bradfitz]

Oh, I don't remember that part. Maybe this is a bug, then. @bcmills?

[bradfitz]

It looks like you were using go 1.11.0. Can you try a more recent Go 1.11.x version?

[thepudds]

I think the issue is the meaning of the go directive changed, and that change was first introduced in 1.11.4 and 1.12.

I believe Go 1.11.4 and higher will build a module that contains version go 1.12 without complaint, whereas earlier 1.11 versions complain with go build github.com/me/hello: module requires Go 1.12.

[thepudds]

Here's a short end-to-end example showing 1.11.3 fail and 1.11.4 build succesfully.

# create a .go file

$ cat <<EOF > hello.go
package main
import "fmt"
func  main() { fmt.Println("hello") }
EOF

# 'go mod init' in 1.12 sets the 'go.mod' to have  'go' directive value of '1.12'

$ go1.12 mod init github.com/me/hello
$ cat go.mod
module github.com/me/hello

go 1.12

# 1.11.3 fails when you try to build due to the 'go 1.12' in the 'go.mod'

$ go1.11.3 build
go build github.com/me/hello: module requires Go 1.12

# 1.11.4 builds same thing successfully

$ go1.11.4 build

# now force a compilation error with 1.11.4, and see extra message stating 1.12 is required
# (which will in theory be helpful in the future with Go2 changes).

$ echo "BAD COMPILE" >> hello.go

$ go1.11.4 build
# github.com/me/hello
.\hello.go:12:1: syntax error: non-declaration statement outside function body
note: module requires Go 1.12

[ianlancetaylor]

What people say above is correct: when creating a module with Go 1.12, and thereby getting a go 1.12 in your go.mod file, you need to use at least Go 1.11.4 to build the module going forward. Closing because this is working as expected. I agree that this is imperfect but the only other option I see would be to delay all language changes for another six months, which seems severe.

[markbates]

At the very least this should be in some docs somewhere. It's clearly a problem that people are somehow just suppose to just know what versions of Go will work with this change.

[thepudds]

@ianlancetaylor one alternative would be for Go 1.12 to set the required Go version to go 1.11 rather than go 1.12, which would sidestep this 1.11-specific transitional issue, and that could be reasonable given there are no language changes in Go 1.12. If language changes land in Go 1.13, then Go 1.13 could set go 1.13, and more generally moving forward the default version set could be the current version of the go tool. However, although in theory such a change could be introduced in a Go 1.12.1, I suspect that might be viewed as too much churn, too inconsistent with future behavior, and/or a ship that has already sailed.

@markbates agreed that a short release note comment or similar could save future headache for other gophers.