-
Notifications
You must be signed in to change notification settings - Fork 797
tools: tools version check logic is broken with go 1.18 #1939
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Change https://golang.org/cl/382159 mentions this issue: |
And reduce the verbosity of `Go: Locate Configured Go Tools`. With go1.18 which includes more details in go version -m output, reporting everything from `go version -m` will be too excessive. `Go: Locate Configured Go Tools` used runGoVersionM to retrieve the build info of each located tool. However, the default inspectGoToolVersion also utilizes `go version -m`, so, they overlap with each other. As we also want to reduce the verbosity of the `Go: Locate Configured Go Tools` output, runGoVersionM is not much different from inspectGoToolVersion any more. This CL unifies them. Since go1.18 changes the build info encoding, we will see failed `go version -m` more often. So, let's not print the error output in the output channel. For golang#1939 Change-Id: I1f674b030ca97804d34df63c66272cddb42b1c65
Change https://go.dev/cl/382159 mentions this issue: |
And reduce the verbosity of `Go: Locate Configured Go Tools`. With go1.18 which includes more details in go version -m output, reporting everything from `go version -m` will be too excessive. `Go: Locate Configured Go Tools` used runGoVersionM to retrieve the build info of each located tool. However, the default inspectGoToolVersion also utilizes `go version -m`, so, they overlap with each other. As we also want to reduce the verbosity of the `Go: Locate Configured Go Tools` output, runGoVersionM is not much different from inspectGoToolVersion any more. This CL unifies them. Since go1.18 changes the build info encoding, we will see failed `go version -m` more often. So, let's not print the error output in the output channel. For golang#1939 Change-Id: I1f674b030ca97804d34df63c66272cddb42b1c65
And reduce the verbosity of `Go: Locate Configured Go Tools`. With go1.18 which includes more details in go version -m output, reporting everything from `go version -m` will be too excessive. `Go: Locate Configured Go Tools` used runGoVersionM to retrieve the build info of each located tool. However, the default inspectGoToolVersion also utilizes `go version -m`, so, they overlap with each other. As we also want to reduce the verbosity of the `Go: Locate Configured Go Tools` output, runGoVersionM is not much different from inspectGoToolVersion any more. This CL unifies them. Since go1.18 changes the build info encoding, we will see failed `go version -m` more often. So, let's not print the error output in the output channel. For #1939 Change-Id: I1f674b030ca97804d34df63c66272cddb42b1c65 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/382159 Trust: Hyang-Ah Hana Kim <[email protected]> Run-TryBot: Hyang-Ah Hana Kim <[email protected]> TryBot-Result: kokoro <[email protected]> Reviewed-by: Suzy Mueller <[email protected]>
With the changes:
Closing. |
As reported in golang/go#50085 go 1.18 changes the encoding of the build info.
That means, if a tool is compiled with go1.18 and VS Code is configured to work with different versions of Go,
go version -m
command will fail.The extension currently relies on
go version -m
for two thingsDiagnosis tool that retrieves tools versions
This will affect only diagnosis. In this case we need to request users to reinstall all tools.
Tools update & consistency check logic:
vscode-go/src/goInstallTools.ts
Line 673 in ed978a6
This will stop tools update notification and compatibility check.
We thought about utilizing
go version -m
to improve our tool update logic, but now I am afraid that this is an evidence that we shouldn't rely ongo version -m
unless the go version is the latest.Currently the extension does not have logic to install the latest go version, or allow users to use different toolchains for tool management (probably we should. #825).
The text was updated successfully, but these errors were encountered: