Please, ignore ignored files and folders

[wtask]

What version of Go, VS Code & VS Code Go extension are you using?

• Run go version to get version of Go
  • 1.13.7
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders
  • 1.42.0 ae08d5460b5a45169385ff3fd44208f431992451 x64
• Check your installed extensions to get the version of the VS Code Go extension
  • 0.13.0

Describe the bug

I have .gitignore file to hide from VCS some local content, for example the .history folder which contains the local history of changes and where there are stored a lot of Go-files. When I check "Problems" tab, I see thousands warnings for the files from this .history folder (in my case 45K+). But all these errors and warnings are out of real project context.
I think vscode-go should consider ignored files and not send them for gopls processing.

[stamblerre]

This is a tough problem to solve, and it comes up in other cases. For example, this extension has some testdata files, and gopls runs on these files as well. In some cases, it can be helpful, but in other cases, it is unnecessary (as in your case).

I think that a viable alternative may be to specify some directories that should be excluded by the extension. @ramya-rao-a: Is there any precedent for such configuration in other VS Code extensions?

[apmckinlay]

In my settings I have:

"files.exclude": {
	".history/": true,

I also have it in my .gitignore

This previously worked fine. But recently, the Go extension started showing errors in these files. Sometimes only for new files added to the .history directory. It seems random. If I restart the language server the errors go away, but sometime later they reappear. So I have to restart the language server many times per hour.

It is especially annoying because vscode will slow down, presumably because there are a lot of files in the .history folder and it takes a lot of processing to check them all.

I also get the message that my system is "misconfigured". I wonder if this is because it's looking at excluded files?

It seems like this used to work and it was broken recently.

[stamblerre]

Can you share the contents of your gopls logs? https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capturing-logs

That will allow us to understand why your workspace is misconfigured.

[stamblerre]

I filed golang/go#37697 under gopls, we'll take a look at it upstream.

[apmckinlay]

Here's a log. In this case it only looked at a new file in the excluded .history

gopls_log.txt

[stamblerre]

Thanks for providing the log. I agree that one of the issues is the ignored files, but it also seems like your project does not play well with gopls, probably due at least partially to build tags (see golang/go#29202). If you could open a new issue in the https://github.com/golang/go repository, I'd be happy to help investigate what's going on.

[apmckinlay]

Thanks for looking at this.

I am aware of the build tags issue. It's not new. It's unfortunate but I realize there's no easy fix. I live with it.

But what changed with excluded files like .history ?
This only started being a problem (for me) quite recently.
And I'm pretty sure it can affect all my history files, not just ones with build tags.

I tried moving my history directory outside my workspace, but I couldn't get it to work. Presumably something to do with the Local History extension. For now I've disabled it.

[stamblerre]

gopls/v0.3.x diagnoses the user's entire workspace, so we will look at all files underneath the directory that you open in VS Code (release notes). This was not the case previously, so that's the change you are seeing here.

[apmckinlay]

This is probably also why it's continually putting old stuff back into my go.mod file - because it finds it in .history

[stamblerre]

To avoid that you can upgrade to Go 1.14 - the behavior of gopls modifying the go.mod should stop happening.

[wtask]

An idea which may help to process ignored files more accurate. First, get the list of ignored files/dirs from project/workspace root (git status --ignored --short). Do not process *.go files from these list with gopls in background and start processing only if file directly open in the editor... From other side, if vscode-go have a whitelist for gopls processing it is ok. Also may add an option like avoid-background-processing=(gitignore, blacklist, never). And when the value is gitignore use git to get ignored list as I hint above. Or vscode-go already have support for excluding files from processing via files.exclude?

[nom3ad]

@apmckinlay . To exclude your .history directory from the "Problems" tab, you may create an empty go.mod file inside .history. In my case, this helped to prevent gopls from running inside gitignored directories.`

[apmckinlay]

@nom3ad That helps, thanks.

[apmckinlay]

@nom3ad I spoke too soon. I'm still getting errors from .history files even with an empty go.mod in .history

[wtask]

@nom3ad Better to explore your history extension, if you use Local History you might move history-folder out of project directory, check the extension settings. But this is temporary solution.

[ramya-rao-a]

I think that a viable alternative may be to specify some directories that should be excluded by the extension. @ramya-rao-a: Is there any precedent for such configuration in other VS Code extensions?

@stamblerre AFAIK there is no generic setting meant to be used for file patterns to be ignored by extensions. It has been concluded in microsoft/vscode#22289 (comment) that each extension is to provide a setting of its own for this matter.

Meanwhile, there is a way to make VS Code not show the problems for the files matching the pattern in files.exclude. Please note that this doesnt stop the extension from generating the problems in the first place. It only makes VS Code hide them in the Problems view.

So, we circle back to the extension needing its own setting or the extension making the call that it will respect files.exclude setting

[stamblerre]

Thanks for the information @ramya-rao-a! We'll probably need to add additional handling for the issue on the gopls side, so I'm going to close this issue in favor of the upstream one: golang/go#37697.