Debug go generate

[firelizzard18]

Is your feature request related to a problem? Please describe. I am working on a generator. The generator has bugs that I need to debug.

Describe the solution you'd like When my code has a go generate comment starting with go run, as in go run ../my_generator, I want an additional code lens, debug go generate, to show up after the run go generate lens. This lens would start a debug session that executes the same code as the go run command.

Describe alternatives you've considered I've created a normal debug entry that runs my generator, but this is annoying when I am messing with flags. It would be really nice to have a lens to click on and totally forgo the launch configuration.

[hyangah]

Thanks for the feature request @firelizzard18

go generate can take arbitrary commands that don't have to be go run commands. For example,

//go:generate goyacc -o gopher.go -p parser gopher.y

Do you mean debugging the go generate command itself, or the command go generate will run (in your example, my_generator package, maybe)?

For the latter, if handling commands that explicitly call go run is sufficient, I think it's feasible. The extension needs to detect the explicit invocation of go run ... and somehow implement go generate's command line parsing and populate a launch request.

[firelizzard18]

For the latter, if handling commands that explicitly call go run is sufficient, I think it's feasible.

That's the idea.

somehow implement go generate's command line parsing

What about go generate -n? That will print the commands that go generate would run, without running them, thus making it easy to use go generate's command line parsing directly.

[ArpanSriv]

Would love to see this.

[gopherbot]

Change https://go.dev/cl/661195 mentions this issue: extension/src/goDebugConfiguration: fix debugging package urls

[firelizzard18]

I'm working on adding this to Go Companion. For now it's masquerading as a test adapter (for the Testing API). I've opened microsoft/vscode#244814 which would be the ideal solution, but if that doesn't look like it's going anywhere I'll probably make it opt-in and tell users they should manually hide it in the test explorer.