tree ac6a9c67cc7e8d909b4bef0c3ac0616a04cc9fe4
parent 289839ce88a68c156debe69b37c27c09adcfe9ff
author Hana <hyangah@gmail.com> 1629827892 -0400
committer Hyang-Ah Hana Kim <hyangah@gmail.com> 1630023015 +0000

src/goDebugConfiguration: massage launch config for debug/test

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.

Updates golang/vscode-go#1713

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>