debug: dlv-dap remote attach doesn't recognize cwd/remotePath - should it?
Once #1873 is in, using hello-world program from hello directory from vscode, set a breakpoint in the editor.
Then start the dlv server from the symbolic link directory.
hello1_ln$ dlv debug . --headless --listen=:54321 --api-version=2
There are two ways to configure the path mapping with "debugAdapter": "legacy" that work:
"cwd":"/path/to/hello",
"remotePath":"/different/path/to/hello1_ln",
"substitutePath": [
{
"from": "/Users/polina/go/src/hello1",
"to": "/Users/polina/go/src/hello1_ln",
},
]
Both only substitutePath works with dlv-dap.
@suzmue @hyangah
Should we use this as an opportunity to migrate the users from remotePath to substitutePath, which is more powerful with multiple entries and new dlv config support in dap, matches dlv terminal, and can be used when connecting to dlv dap servers as well. Or should we aim for backward compatibility and map remotePath+cwd to substitutePath for the user? If not, we should update package.json because it misleadingly says "If specified, becomes the first entry in substitutePath."
Update: this doesn't matter for Cloud Code. They can easily update their configuration to use whatevere.
I just noticed the following deprecation setting in package.json: https://github.com/golang/vscode-go/blob/cc34acfbcfc409bb5b6077cc74d3eb1d4aaeee2c/package.json#L852-L857 added in https://github.com/golang/vscode-go/commit/dac15006ebf50d1cf83b1b6da9c5ab32f21dac5f
I must have missed this earlier. But looks like the plan is to deprecate remotePath, so switch to dlv-dap might serve as a good catalyst and we should therefore not map remotePath to substitutePath automoatically..