go version -m fails for target binaries compiled with go1.18
What version of Go are you using (
The text was updated successfully, but these errors were encountered:
I looked at the parser in 1.17. It seems hard to make it completely backward compatible. It needs at least one bit to tell if the new format is used, but the 1.17 parser seems to need all bits? If this line
then we'd have some free bits. Maybe there is a clever way. I'm not sure.
The problem for the old format is that in some configurations it cannot find the Go version at all, so we cannot rely on that.
When would one want to use a gopls built with the new toolchain while still using the old toolchain? Does vscode-go shell out the go command somehow? If so, could it hint the user to user to choose the new go command (even just temporarily for that one)?
Or vscode-go could use the debug/buildinfo package (available in 1.18) to do its own parsing, without shelling out the go command. So if vscode-go is built with the new toolchain, it should be able to handle other tools built with the new toolchain, regardless of the go command's version.
Thanks for looking into it. That is unfortunate. Is the current format forwards-compatible? Would be nice if we can avoid repeating this in the future.
This is a user visible change so I think it's worth documenting this in the release note. Users need to update their Go to 1.18 if they want to inspect binaries built/distributed by other parties who potentially could selected go1.18.
Switching between go versions is not uncommon. We've been recommending users to compile gopls with the latest Go version and keep using it when they work with older versions of Go.
The extension has allowed users to configure only one Go version at a time and used it both for checking the tools versions and building user's project. Maybe we should add another setting to separate them.
vscode-go is a typescript project. :-/
The best path forward for us is to add another setting or pick the most recent Go versions it can find from the system.
Or, maybe we can use gopls for checking versions of other tools - because it's easier for vscode-go to manage gopls version than the go toolchain at this moment. (cc @findleyr )
I don't believe it is reasonable to make a guarantee that older Go versions can understand binaries from newer Go versions. That restricts too much what we can change or fix in newer Go versions. In this case, the way the versions were encoded was fundamentally incompatible with certain kinds of binaries and was overly complicated for all kinds of binaries. We greatly simplified it in Go 1.18. If we had to preserve compatibility with 'go1.17 version', that would mean more complexity in the binaries that we carry around until the end of time. It doesn't seem like the right tradeoff. Instead, the rule is: to analyze new Go binaries, use a new Go toolchain.
If we could go back in time, I would suggest that gopls have a -V flag that makes it print its version and exit, same as 'go tool compile' and friends all do. Maybe that's a better future-proof way at least.
@rsc I left this issue open for documentation purpose - release note.
Gopls already has its own version command. My intention was to utilize
Fixes #50085 Change-Id: I9be8ddb983fb4fe598becbb0b93bb5b7e1f8438f Reviewed-on: https://go-review.googlesource.com/c/go/+/372214 Trust: Hyang-Ah Hana Kim <email@example.com> Run-TryBot: Hyang-Ah Hana Kim <firstname.lastname@example.org> TryBot-Result: Gopher Robot <email@example.com> Reviewed-by: Bryan Mills <firstname.lastname@example.org>