Open matloob opened 5 years ago
It looks like these errors are coming from the compiler.
The Go command wants to build these packages at its own version (devel +6d1aaf143c Tue Jun 25 21:47:04 2019 +0000
). It invokes the compiler from GOTOOLDIR
, which is derived from the explicitly set GOROOT
. The compiler was built with go1.12
, and that doesn't match the requested version. It can only build for the same version.
I don't think it makes sense to ignore GOROOT
entirely. This would work if the Go command were built with the same version of Go as GOROOT
. That's probably necessary for bootstrapping, though I'm not sure exactly how. I expect some folks have a workflow that takes advantage of this, too.
It's definitely a problem that the errors aren't reported correctly in the JSON when the -e
flag is set though. If the Go command runs a tool that exits non-zero, the Go command assumes the tool printed something and sets its own exit status to 2 (which is what's happening here). For go list -e
specifically, we should capture stderr and push it into the Error
field of the Package
that corresponds to the action.
cc @jayconrod
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I did a
go list
with a GOROOT set to a different Go installations's goroot. I have Go 1.12 installed in /usr/local/go/bin/go, and something tip-ish installed in $HOME/devgoif I do a normal
go list -export
of a stdlib package, exports show up fine:On the other hand running go list with GOROOT set to a different go installation's goroot, the export data is missing:
And the exit status is 2 so at least we know something's wrong.
But it's worse if we do a list -e. The same "warnings" are printed, but the exit status is 0 and an error isn't set on the package
What did you expect to see?
The ideal situation is that the value GOROOT is ignored. The go command already knows its own GOROOT, and using a different one will break things.
At the least, if go list is going to fail, it should have an error set.
What did you see instead?
go list -e -json -export succeeds, but has no export data present.