debug: prompt users with helpful info when launch is requested without main or test packages

[sivan-koren]

Is your feature request related to a problem? Please describe.
If the active tab does not contain the main package when we start debugging the debugger exits with the following message:
go run: cannot run non-main package

This forces the user to change tabs before debugging, distracting from the code of interest.

Describe the solution you'd like
When debugging starts, all currently open tabs should be checked for a main package and if found the file associated with that tab should be passed to go run instead of the file associated with the active tab.

Describe alternatives you've considered
Custom workspace settings maybe?

[hyangah]

@00Sivan Thanks for the feature request.

If launching a specific program in different location needs to be done frequently, isn't it possible to configure a custom launch.json to point to the program? https://code.visualstudio.com/docs/editor/debugging#_launch-configurations

If you commit launch.json, it will help other project members sharing the workflow, instead depending on the ad-hoc way of finding a main package to run.

And, if multiple main packages or unrelated main package files are open, I am afraid this implicit target choice can lead confusion.

[sivan-koren]

Thanks, I will look into a launch config. I thought about the cases you've described. I don't see any issue. You shouldn't have multiple mains. You're going to get an error from the Go compiler, let alone VS. To compile we need ONE and only ONE main package. There is no other possible workflow. If we have multiple main packages open, it's still not a problem for VS. Either error at that point, or run the one in focus, which is already the behavior now. I don't see any issue. If there is one main package open, the way the Go compiler expects it to be, VS shouldn't need my help to find it...

…

On Tue, May 26, 2020, 7:05 AM Hyang-Ah Hana Kim ***@***.***> wrote: @00Sivan <https://github.com/00sivan> Thanks for the feature request. If launching a specific program in different location needs to be done frequently, isn't it possible to configure a custom launch.json to point to the program? https://code.visualstudio.com/docs/editor/debugging#_launch-configurations If you commit launch.json, it will help other project members sharing the workflow, instead depending on the ad-hoc way of finding a main package to run. And, if multiple main packages or unrelated main package files are open, I am afraid this implicit target choice can lead confusion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#94 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGVZZLFYWMZLN2GTMXA6LTRTO5CZANCNFSM4NJW5EWA> .

[hyangah]

@00Sivan I am not worried about the go compiler. I am worried whether the main package with the open window is really the right one to run. We can't make any assumption about users workflow or authoring pattern in this case.

It's not uncommon to have multiple windows for different main packages open. It's not uncommon to have an unrelated main package open for edit, while editing a different package. Accidentally leaving an unrelated main package source code open can start debugging with that implicitly chosen main package, and I fear that will confuse users.

Since launch.json already allows that kind of customization and provides more flexibility (you can pass parameters and data files) and ability to share with team members, I am not sure if we need this feature.

cc/ @quoctruong @ramya-rao-a

[sivan-koren]

You've made some valid points. I can see why the launch.json is the go to. It seems with this in mind that users should be offered for VS to make the appropriate json for us, like other packages and VS features do when faced with ambiguity. A prompt would be much better than a panic with no instructions.

[hyangah]

@00Sivan yes, that's a reasonable request. The extension should be able to detect this type of errors early (auto/debug mode running against a file with non-main or test package). Or alternatively, we should be able to translate the error from dlv (e.g.: could not launch process: not an executable file currently) to a more user-friendly error message.