debugging: same filename can be found in wrong path (remote debugging)

[rspruyt-google]

TL;DR; when 2 files have the same filename (but different paths), the file from the incorrect path can be displayed while debugging.

go version go1.15.5 linux/amd64
VS Code go plugin v0.19.0

settings.json:

{
    "workbench.startupEditor": "welcomePage",
    "editor.fontSize": 13,
    "window.zoomLevel": 1,
    "editor.minimap.enabled": false,
    "breadcrumbs.enabled": true,
    "go.delveConfig": {
        "dlvLoadConfig": {
            "followPointers": true,
            "maxVariableRecurse": 1,
            "maxStringLen": 128,
            "maxArrayValues": 128,
            "maxStructFields": -1
        },
        "apiVersion": 2,
        "showGlobalVariables": false
    },
    "editor.fontFamily": "Roboto Mono, Consolas, Courier New",
    "editor.fontLigatures": true
}

launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach remote",
      "type": "go",
      "request": "attach",
      "mode": "remote",
      "port": 3333,
      "host": "127.0.0.1",
      "apiVersion": 2,
      "cwd": "${workspaceFolder}",
      "trace": "log",
      "showLog": true
    }
  ]
}

Problem:

In golang, short filenames are preferred, e.g.

/project/path1/component/bar.go (say has 100 lines of code)
/project/path2/component/bar.go (say has 200 lines of code)

Setting/stopping at breakpoints works fine for path1/../bar.go, however if set a breakpoint in path2/../bar.go, path1/../bar.go is opened instead (with the last line shown as the stop point since this file does not have line 150), which is incorrect.

If I remove /project/path1/ from the source tree, everything works fine.

Debug console shows the breakpoint is set correct:

AttachRequest
Start remote debugging: connecting 127.0.0.1:3333
InitializeEvent
SetBreakPointsRequest
Debuggee is not running. Setting breakpoints without halting.
All cleared
Creating on: /project/path2/component/bar.go:150

It looks like the file name match is done through an alphabetical search of sorts and does not use the full path. I'm not sure if this is a bug or there is a way to circumvent this?

[hyangah]

cc @suzmue @quoctruong
I am guessing the automated path mapping got confused.
What's the relationship between the path1 and path2 components? Are they in different modules? Are both supposed to be compiled in the final binary that's debugged here?

[rspruyt-google]

path1/component/bar.go belongs to package a;
path2/component/bar.go belongs to package b;

where a imports b.

the breakpoint is in package b.

They are compiled into the same binary. I can share a concrete example via internal Google chat if it is easier for full context, rspruyt@google.com

[gopherbot]

Change https://golang.org/cl/275514 mentions this issue: Improve path mapping

[suzmue]

The mapping for a case like this can now be done through the substitutePath configuration.

For a project set up locally as:
/project/path2/component/bar.go
/project/path1/component/bar.go

and remotely:
path2/component/bar.go (containing source for /project/path2/component/bar.go)

The launch configuration would contain:

{
"substitutePath": [
{ "from": "/project/path2/component", "to": "path2/component" },
{ "from": "/project/path1/component", "to": "path1/component" }
]
}