Prompt to add/update buildtags setting, if current file has buildtags

[ramya-rao-a]

If current file has build tags and the user hasnt added the same via the go.buildtags setting, then the below features may not work as expected

• build
• test
• go to definition
• go to implementation
• find references
• rename

This feature request is to prompt the user in such scenarios to update the go.buildtags setting.
The prompt should have an option "Don't show again" which if chosen results in the prompt never being shown again
The prompt should have an option "Open settings" that would open the settings file so that user can add/edit the go.buildtags setting

PRs are welcome
I can help anyone who is interested to give this a try

[urohit011]

I would like to give it a try, but it will my first time contributing to this project so can I get some pointers to get started?

[ramya-rao-a]

Sure!

Basic set up steps are described here: Building and Debugging the Go extension

It assumes you have node installed.

Once you are set up, you can follow how we have the "notify user if a generated file is being edited" feature. This is done in the notifyIfGeneratedFile function. You can rename it to say checksOnFileEdit and add the build tags check in it.

Good luck! Let me know if you have any issues. You can also ping me on the gophers slack

[urohit011]

Thank you, will get started right away.

[ramya-rao-a]

After looking at attempts to implement this feature #1590 and #3020, I am having second thoughts about the feature being requested in #1497

This is not going to be trivial as ideally, each feature will need to trigger the check for build tags on current file.

When the feature is on a package or workspace level, these checks cannot be done as we the check assumes we are working with a single file.

When feature is about testing, one will also need to look at go.testTags setting.

Since the error message when build tags are not set are simple enough to unpack, I would vote for not implementing this feature

@marcel-basel, @stamblerre, @hyangah, thoughts?

[hyangah]

I agree that this is non-trivial in the current state. To add more complexity to the problem, also we have to consider the GOOS, GOARCH, and other env vars.

There are other efforts related to handling sources with build tags - e.g.
golang/go#39005 proposal: build configuration
golang/go#29202 gopls: improve handling of build tags

I leaning towards not implementing this feature yet.

Instead, maybe showing clear messages and indicating that the source is not included in the current build configuration (with some reference) will be nice.

[ramya-rao-a]

Instead, maybe showing clear messages and indicating that the source is not included in the current build configuration (with some reference) will be nice.

Yes, but unfortunately the extension is not equipped to figure this out. But, when using the language server, we can possibly look into having better error messages.

Closing this issue based on the above discussions