-
Notifications
You must be signed in to change notification settings - Fork 767
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
debug: cannot import absolute path #1680
Comments
Nightly build v2021.8.919 exhibits the same issue. |
Can you please fill out the bug report template? You can find it here: https://github.com/golang/vscode-go/issues/new?assignees=&labels=&template=bug_report.md&title=. Also, can you please share your |
What version of Go, VS Code & VS Code Go extension are you using?
golang.org/x/tools/gopls v0.7.1
go env Share the Go related settings you have added/editedRun { Nothing with [go*] Describe the bugA clear and concise description of what the bug. Steps to reproduce the behavior:
import "fmt" func main() { Outcome: Starting: /home/sunny/go/bin/dlv-dap dap --listen=127.0.0.1:46545 --log-dest=3 Screenshots or recordingsIf I need to do a recording, please, advise. Rolling back to 0.26.0 I can successfully step through the code above. |
This is caused by the difference in the way to build the binary for debug in the new dlv-dap adapter. @alexandre-kovalenko Workarounds:
@suzmue @polinasok To handle this ad-hoc mode build (not module mode nor GOPATH mode), we may need changes in dlv dap:
Personally, I prefer the option 2 which gives more flexibility to clients. |
Dlv-dap already can handle a relative program path, just like dlv cli - same helper library is used to build in both cases. The absolute path is enforced in the extension, but it doesn't have to be. |
Change https://golang.org/cl/346095 mentions this issue: |
When the current build directory is resolved to a path different from the program's directory due to soft/symbolic links, the go command can be confused and complain that the absolute path in program is outside the module of the current directory. This CL avoids such problem by making dlv always use a relative path as the build target for build/test mode (and auto for testing). Before starting the debug session, we massage the launch config: program: /foo/bar.go -> program: ./bar.go, __buildDir: /foo program: /foo/bar -> program: ., __buildDir: /foo/bar Previously we find the package directory just before spawning dlv dap and spawn the dlv dap process from the package directory. With this CL, we find the package directory when resolving the debug configuration before debug session. This introduces __buildDir attribute which is internal. (There is an ongoing work to introduce 'buildDir' to dlv DAP so we use internal attribute to make it clear.) Also, this made the resolveDebugConfigurationWithSubstitutedVariables accept relative paths without workspace root. Just the behavior is undefined. (The motivation of change in this part is the testing. We have 'output' property or some others, that are like relative path. I guess most users wouldn't care much. Delve is cool with relative paths so we do our best to resolve that wrt the workspace root. Otherwise, just let delve decide. Fixes #1713 Fixes #1680 Fixes #1677 Updates #1348 Change-Id: I434c43131b27d9c58058450c502e1b30c58ea690 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/344790 Trust: Hyang-Ah Hana Kim <hyangah@gmail.com> Trust: Suzy Mueller <suzmue@golang.org> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: kokoro <noreply+kokoro@google.com> Reviewed-by: Suzy Mueller <suzmue@golang.org> Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/346095
v0.27.2 is released and that includes the fix. Please reopen this issue or comment otherwise. Thanks! |
Looks like
https://github.com/Microsoft/vscode-go/issues/905
resurfaced in 0.27.0.
Rolling back to 0.26.0 resolves the issue.
I am not sure I can add much to the original report, but, if there's any information that need to be provided, kindly, let me know.
The text was updated successfully, but these errors were encountered: