Closed benz9527 closed 5 months ago
I think whether the tooltitude startup is before the vscode-go sometime result in it unable to read the go env?
@benz9527 Thanks for your feedback.
We check the availability of go by running the following command: 'go env --json' Could you execute it in the terminal and share with me what its output in cases where go isn't available? Is there any chance that the environment variables aren't correctly setup.
P.S. This issue doesn't seem to be related to vscode go.
@benz9527 I added a diagnostic so that in the next version it will be possible to find out the exact cause of why this command failed in the developer tools.
@benz9527 We have a discord community here: https://discord.gg/f9MHBXsVwr We could troubleshoot what's going on there if it works for you.
@benz9527 The new diagnostic is out. In 0.69.0+ when the error is shown, there's an additional button View Log. If you press it, it will output detailed diagnostics. You could share it here (please remove information which you don't want to expose here), and it will be much easier for me to understand what's going on.
It seems that when tooltitude startup, it will run go env -json
but in my windows will response an error.
I run go env -json
manually, it is okay.
PS E:\Projects\My\xboot> go env -json
{
"AR": "ar",
"CC": "gcc",
"CGO_CFLAGS": "-O2 -g",
"CGO_CPPFLAGS": "",
"CGO_CXXFLAGS": "-O2 -g",
"CGO_ENABLED": "1",
"CGO_FFLAGS": "-O2 -g",
"CGO_LDFLAGS": "-O2 -g",
"CXX": "g++",
"GCCGO": "gccgo",
"GO111MODULE": "",
"GOAMD64": "v1",
"GOARCH": "amd64",
"GOBIN": "E:\\Env\\Go\\Path\\bin",
"GOCACHE": "C:\\Users\\BenZh\\AppData\\Local\\go-build",
"GOENV": "C:\\Users\\BenZh\\AppData\\Roaming\\go\\env",
"GOEXE": ".exe",
"GOEXPERIMENT": "",
"GOFLAGS": "",
"GOGCCFLAGS": "-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\\Users\\BenZh\\AppData\\Local\\Temp\\go-build3926234670=/tmp/go-build -gno-record-gcc-switches",
"GOHOSTARCH": "amd64",
"GOHOSTOS": "windows",
"GOINSECURE": "",
"GOMOD": "E:\\Projects\\My\\xboot\\go.mod",
"GOMODCACHE": "E:\\Env\\Go\\Path\\pkg\\mod",
"GONOPROXY": "",
"GONOSUMDB": "",
"GOOS": "windows",
"GOPATH": "E:\\Env\\Go\\Path",
"GOPRIVATE": "",
"GOPROXY": "https://goproxy.cn,direct",
"GOROOT": "E:\\Env\\Go\\go1.22.1",
"GOSUMDB": "sum.golang.org",
"GOTMPDIR": "",
"GOTOOLCHAIN": "auto",
"GOTOOLDIR": "E:\\Env\\Go\\go1.22.1\\pkg\\tool\\windows_amd64",
"GOVCS": "",
"GOVERSION": "go1.22.1",
"GOWORK": "",
"PKG_CONFIG": "pkg-config"
}
@benz9527 The output you pasted as the text is what we are looking for. I.e. it's completely correct.
Concerning the screenshot, it would be great if you could somehow convert the error message to a correct encoding. It looks like some useful error message. (my guess it's something along the lines of 'go' command not found).
Also, how do you run vscode? Do you run it via icon or menu, or via the code command? Is it the difference? It might be PATH environment variable not correctly configured in one of the cases.
'go' 不是内部或外部命令,也不是可运行的程序或批处理文件
After translated:
'go' is not an internal or external command, nor is it a runnable program or batch file
After I upgraded the go from 1.22.1 to 1.22.2, the tooltitude always show me with the load error log.
Oho, I know the root cause. After I update the GOROOT env but I don't why my Path will lose the %GOROOT%\bin
, after I re-added it, tooltitude will be load normally.
There still a stranger issue that is the VSCode terminal (powershell) could work wihout the %GOROOT%\bin
(I have set the go.goroot in settings.json), but both the windows cmd and tooltitude are not.
@benz9527 Thanks for detailed investigation!
Now, I see what's going on. "go.goroot" is a vscode-go setting, and we would rather not use it. I will think what we could do to work this around.
@benz9527 May be a weird question, but did you restart the machine after your change the env variables? Did you restart vscode since then? I will add diags about environment variables in the next version so that we could investigate what path it's running with in the next version.
@benz9527 Also, as a tmp workaround, could you invoke code from the command line via the cmd command? In this case, it should inherit environment variables, and it should have PATH set correctly.
@benz9527 We added tooltitude.env configuration setting which allows you to specify environment variables for the tooltitude language server process. If nothing works, you will be able to explicitly set PATH to correct value. It will be available in 0.70.0 likely somewhere on the next week (we will try to release it sooner, but can't promise that).
Thanks.
@benz9527 0.70.0 is out. Could you please try the setting, and see whether you could make your project work with it.
Closing this issue since we now have a way to resolve this problem.
Tooltitude Version: v0.68.0
OS Version: Windows 11 Pro 22H2 22621.3296
VS Code Version: Version: 1.87.2 (user setup) Commit: 863d2581ecda6849923a2118d93a088b0745d9d6 Date: 2024-03-08T15:20:17.278Z Electron: 27.3.2 ElectronBuildId: 26836302 Chromium: 118.0.5993.159 Node.js: 18.17.1 V8: 11.8.172.18-electron.0 OS: Windows_NT x64 10.0.22621
Go Version: 1.22.1
Code Repository (if open source): github.com/benz9527/xboot
What did you try to do?
Is there anything interesting in the tooltitude output channel? (should be open if you are reporting error from within VS Code)
Steps to reproduce