Originally reported by @dr2chase
- How to repro: provide an invalid path for
go. For example, the user has a go binary in $HOME/work/go/bin/go but VSCode doesn't resolve $HOME automatically (~ is resolved though). So, the following setting won't work as expected.
"go.alternateTools": {
"go": "$HOME/work/go/bin/go"
}
-
What do I expect to happen:
Clear error message pointing out the problem with this setting.
-
What did I see instead:
Confusing error message ""Failed to find the "go" binary in either GOROOT(/Users/drchase/work/go-1.15) or PATH(/Users/drchase/bin:<omitted>).Check PATH, or Install Go and reload the window. If PATH isn't what you expected, see https://github.com/golang/vscode-go/issues/971"
-
What happened:
"go.alternateTools" supports both
case A) the absolute path to the alternate tool, and
case B) an alternative tool name (e.g. instead of go, maybe look for go-1.15)
When resolving the path for go, the extension called getBinPathWithPreferredGopathGorootWithExplanation with alternateTool = '$HOME/work/go/bin/go'. $HOME isn't expanded, so it doesn't look like an absolute path nor it's a valid executable path
|
if (alternateTool && path.isAbsolute(alternateTool) && executableFileExists(alternateTool)) { |
As a result, the extension thinks the user's intention was to provide an alternative tool name (case B).
Thus, in the following tool search path, the extension tries to look up '$HOME/work/go/bin/go' from all the paths (GOBIN, GOROOT/bin, PATH, ...), and miserably fails.
When a user supplies go.alternateTools and the lookup failed.
- If the path contains directory path separators, consider this was a misconfigured case A.
- Otherwise, show the
binname used in the actual search.
cc @dr2chase @findleyr @suzmue
Re: $HOME. Not sure if we want to expand $HOME as we already do for ~. VSCode has variables for tasks/launch settings. I feel like we need to stop reinventing the wheel and look into a way to support more standard solution instead. (i.e. ${env:HOME}). https://code.visualstudio.com/docs/editor/variables-reference#_environment-variables
Originally reported by @dr2chase
go. For example, the user has a go binary in$HOME/work/go/bin/gobut VSCode doesn't resolve$HOMEautomatically (~is resolved though). So, the following setting won't work as expected.What do I expect to happen:
Clear error message pointing out the problem with this setting.
What did I see instead:
Confusing error message
""Failed to find the "go" binary in either GOROOT(/Users/drchase/work/go-1.15) or PATH(/Users/drchase/bin:<omitted>).Check PATH, or Install Go and reload the window. If PATH isn't what you expected, see https://github.com/golang/vscode-go/issues/971"What happened:
"go.alternateTools"supports bothcase A) the absolute path to the alternate tool, and
case B) an alternative tool name (e.g. instead of
go, maybe look forgo-1.15)When resolving the path for
go, the extension calledgetBinPathWithPreferredGopathGorootWithExplanationwithalternateTool = '$HOME/work/go/bin/go'.$HOMEisn't expanded, so it doesn't look like an absolute path nor it's a valid executable pathvscode-go/src/utils/pathUtils.ts
Line 63 in b79bdf9
As a result, the extension thinks the user's intention was to provide an alternative tool name (case B).
Thus, in the following tool search path, the extension tries to look up
'$HOME/work/go/bin/go'from all the paths (GOBIN, GOROOT/bin, PATH, ...), and miserably fails.When a user supplies
go.alternateToolsand the lookup failed.binnameused in the actual search.cc @dr2chase @findleyr @suzmue
Re:
$HOME. Not sure if we want to expand$HOMEas we already do for~. VSCode has variables for tasks/launch settings. I feel like we need to stop reinventing the wheel and look into a way to support more standard solution instead. (i.e.${env:HOME}). https://code.visualstudio.com/docs/editor/variables-reference#_environment-variables