-
Notifications
You must be signed in to change notification settings - Fork 769
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
debug: "program":"${file}" foo.go turns into extension-output-golang.go-nightly-#3 in launch request #1826
Comments
Change https://golang.org/cl/353990 mentions this issue: |
That is because the focus was on OUTPUT channel which VS Code treats like an open document and The current way of showing notification is not ideal either because users would suppress it forever. In that case, there is no place to show the error details. DEBUG CONSOLE will be the natural place to look into but unfortunately, debug session didn't start yet when this check occurs so there is DEBUG CONSOLE. Alternative is to let the extension forward this request and |
parseProgramSync assumed 'program' is a directory if it does not contain '.'. That was a hack to avoid lstatSync and implement/test parseProgramSync without requiring the program to be a valid, existing file or directory. However, this does not work for users whose folder name contains '.'. (e.g., #1826) Readd the lstat check to examine whether the program is a directory. This required to change tests to create dummy files and folders. While we are here, rework parseProgramSync. - move parseProgramSync to goDebugConfiguration, the only call site of this function. - rename it to parseDebugProgramArgSync and call it only for debug/test/auto launch requests. - call parseDebugProgramArgSync for externally launched debug adapter settings too because it does `program` validation. But in that case, we won't mess with `program` or `__buildDir`. - previously we accepted cases for which parseDebugProgramArgSync throws an error (including files other than .go) because the hack is not perfect and delve dap and go build may know better on how to handle that. But now build errors can be hidden in DEBUG CONSOLE so they fail to catch users' attention (e.g., #1826) So, let's stop and don't proceed if parseDebugProgramArgSync fails. Updates #1769 Updates #1826 Change-Id: If413a0ca0c5814bcaa45ea69ceff8bcfde558370 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/353990 Trust: Hyang-Ah Hana Kim <[email protected]> Trust: Suzy Mueller <[email protected]> Run-TryBot: Hyang-Ah Hana Kim <[email protected]> TryBot-Result: kokoro <[email protected]> Reviewed-by: Suzy Mueller <[email protected]>
v0.29.0 is released. |
What version of Go, VS Code & VS Code Go extension are you using?
Version Information
go version
to get version of Go from the VS Code integrated terminal.gopls -v version
to get version of Gopls from the VS Code integrated terminal.code -v
orcode-insiders -v
to get version of VS Code or VS Code Insiders.Go: Locate Configured Go Tools
command.Share the Go related settings you have added/edited
Run
Preferences: Open Settings (JSON)
command to open your settings.json file.Share all the settings with the
go.
or["go"]
orgopls
prefixes.Describe the bug
This comes and goes. I haven't figured out why. But every once in a while when I try to build my test
.go
file while it is in my active view, I get a build error indicating that some other file with what looks like an auto-generated (tmp?) nameextension-output-golang.go-nightly-#3
is being used instead:I thought maybe this was related to saving the file after making changes, but I haven't made any recent changes to the file this time.
Steps to reproduce the behavior
This is the most recent set-up where I observed this, but I am pretty sure last time I saw this I was not using
debugServer
and instead had the extension launch dlv-dap for me. That said, upon making a cosmetic edit tolaunch.json
, the issue went away. I don't know of a reliable way to reproduce this.File
foo.go
The text was updated successfully, but these errors were encountered: