cmd/compile: "only supported as of -lang=go1.13" error is misleading

[rogpeppe]

$ go version
go version devel +8b058cfbce Sun Aug 11 15:44:08 2019 +0000 linux/amd64

When I compile some Go code that uses binary literals and has an old (go1.12) Go version declaration in its go.mod file, I get this error message:

./tst.go:8:13: binary literals only supported as of -lang=go1.13

This makes it sound like I need to enable go1.13 support by passing a -lang=go1.13 flag to the go build invocation, where actually the problem is the incorrect go 1.12 directive inside the go.mod file - go build does not recognize the -lang flag.

[mvdan]

An idea to slightly improve the error given by the main Go tool (not the compiler):

binary literals only supported as of -lang=go1.13, but go.mod states 1.12

[cherrymui]

The go command does not parse the file and so does not know whether it uses binary literals. It is the compiler that finds the error.

Maybe just mention go 1.13, without -lang?

[bcmills]

CC @ianlancetaylor @griesemer

[mvdan]

I should have been clearer in my comment. I assume that this is the compiler giving the error (hence the -lang mention); my point is that cmd/go could further decorate these errors by including the fact that -lang=go1.12 came from go.mod.

For example, this could be done by detecting the error. I realise that's hacky, but I assume that the Go tool already does that elsewhere.

Not mentioning either -lang nor go.mod is also an option, but for the sake of UX, I'd hope we can point the user at go.mod. Since modules were introduced without that go X.Y line initially, plenty of them are still unaware that it exists, or how it affects the build.

[ianlancetaylor]

I think we can just change the compiler to give a better error message. How about

binary literals not supported in language version 1.12 (may need to update language version in go.mod file)

[ianlancetaylor]

@gopherbot please open backport to 1.13

This is an unnecessarily confusing error message for people who want to try the new 1.13 language features, so when we fix it I think we should backport the fix to the 1.13 release series.

[gopherbot]

Backport issue(s) opened: #33761 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[griesemer]

I'm in favor of @cherrymui's suggestion with respect to the compiler error. But perhaps it could say:

XYZ requires Go 1.13 or later (-lang was set to go1.13)

This is short, makes it clear what minimum version is needed, and provides clear information as to what caused this (the current setting of -lang) without speculating what needs to be done.

[ianlancetaylor]

I think that something needs to say "go.mod". I'm thinking that it's fine to do that in cmd/compile, but if we don't put it there then it has to be in cmd/go as @mvdan suggested.

[andybons]

Any updates on this?

[griesemer]

The compiler doesn't know who/what set the -lang flag, yet the compiler will need to provide an error message. I'll send out a CL for discussion.

[gopherbot]

Change https://golang.org/cl/198491 mentions this issue: cmd/compile: better error message for language version errors

[gopherbot]

Change https://golang.org/cl/201480 mentions this issue: [release-branch.go1.13] cmd/compile: better error message for language version errors