Thanks for opening this issue! This behavior stems from a check implemented here, when either the -m or -v flags are passed, as they are used to enable printing the embedded module version information for executables and reporting unrecognized files respectively.

Basically, when go version parses -v, it switches from reporting its own go version to searching for version information on Go executable files, on the path provided as argument(s).

Edit: I guess the certain way to get Go to print its own version would be GOFLAGS="" go version; I'm not aware of any cases where there are exceptions on GOFLAGS.

I can write a p/r for gitea to make that work, but if you go this route, this behavior should probably be documented in the go 1.15 release notes some how. I'm sure I'm not the only person who will hit it. :-)

I'm not the most qualified person to say which way this should be handled eg. a better error message, or documenting the two go version 'modes' in a clear way.

Maybe @mvdan will have some more context since he worked more recently on implementing these checks.

This seems like an unintended regression; I'll take a look in the morning.

Thanks much. :-)

@bcmills @jayconrod @matloob

@bcmills is there a way for runVersion to tell apart go version -v from GOFLAGS=-v go version? I think it's OK for the first to error, because the explicit flag is pointless, but the second shouldn't. It's perfectly reasonable to write something like:

export GOFLAGS=-v # always be verbose
go version
go build ./...

If it's not possible to separate the two cases, then I'll just send a revert CL which we can backport to 1.15.x.

@mvdan, you could iterate over cmd/go/internal/base.GOFLAGS:

That would reduce the false-positives, at the cost of some (rare) false-negatives: if the user ran GOFLAGS=-v go version -v then the explicit argument wouldn't be diagnosed, but I'm not sure that matters much.

Do you reckon that's worth it versus a revert, given the slight inconsistency and unlikely false negatives? It would be a pretty tiny patch if we're OK with exporting inGOFLAGS, so at least there's that.

I think either approach is fairly low-risk, given that go version is not that widely used and GOFLAGS does not often contain -v or -m.

Change https://golang.org/cl/254157 mentions this issue: cmd/go: relax version's error on unexpected flags

Do we think this is enough of a regression to warrant backporting to 1.15.x? I personally think not, because it seems pretty rare and also fairly easy to work around. But if anyone else feels strongly about it, it wouldn't be a lot of effort to backport.

I would like to see it back ported if it isn't a lot of work, otherwise I will have to backport it myself in Gentoo's go packages since we set GOFLAGS=-v by default in our builds.

@gopherbot please consider this for backport to 1.15, it's a regression.

Backport issue(s) opened: #41464 (for 1.15).

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

Thanks @williamh, that seems like enough reason to me. I've opened a backport issue and CL.