setting that uses .gitignore to exclude directories instead of build.directoryFilters

[vogtb]

tl;dr -- custom build writes thousands of files to target directories that are ignored by .gitignore. But it's not clear that gopls is not by default ignoring these, causing it to include all of my non-source files, use 100% CPU, and hang indefinitely. The build.directoryFilters setting is not immediately obvious, and I'd like an option to use .gitignore instead, possibly by default.

Problem

I work with many git submodules in a single large git module that is also my vscode workspace. Building these modules results in thousands files across their own target directories, which are all ignored with .gitignore at the workspace level, and individual .gitignore files at each git submodule.

When I build these modules all of them are being sent to gopls to be scanned, causing _gopls use 100% CPU and become unresponsive.

Solution

A setting that lets me use .gitignore to exclude files from being used by gopls. Additionally, I'd like this setting to be on by default, as it's safer and causes fewer surprises to users. This would be an alternative the existing build.directoryFilters setting.

Current Alternative

I'm using build.directoryFilters for now, but it seems a bit weird that gopls is using "[by default] all directories".

See also

• Possibly causing saving file stuck: Saving 'xxxx.go': Getting code actions from ''Go'' #2687.
• Maybe related to High CPU Usage #2623.

[hyangah]

@vogtb How does go build ./... perform in your setup? This issue talks about gopls's aggressive directory scanning behavior and proposes to translate .gitignore into gopls's configuration. However, this extension also has lint and other functionalities that also scan the entire workspace.

I think it would be nice if we can make gopls less aggressive but smarter in its directory scanning.

Understanding vscode's files.exclude and translating it to gopls's build.directoryFilters and other parts in the extension (e.g. lint, test explorer, ..) is something I are thinking about, but I am not sure about translating a specific VCS's config file
designed for something else into the gopls configuration or the other way because a user happens to configure one of them.

The existence in .gitignore doesn't necessary mean build.directoryFilters. So, mixing the two different rules by default seems strange and less intuitive to me. For example, some people would choose not to check in to git but need them to be included in gopls and go command's operation - many go users do this for go.work or vendor used for hack, but the same reasoning may apply to directories.

[vogtb]

Running go build ./... performs normally.

Using something like vscode's files.exclude would also be fine. I thought using .gitignore could be a sane default as, in my mind, there's a large overlap between what you don't check into git, and what you don't want scanned. But I also understand the desire to keep things clean, and not have multiple settings affecting what's scanned, or not scanned.

[hyangah]

Thanks for testing go build ./.... It's interesting that gopls falls over while go build ./... works ok. Something strange is going on (cc @findleyr )

One of the complications in translating files.exclude or .gitignore or other ignore files to build.directoryFilters is the pattern syntax difference.

I will discuss this with the team in our weekly meeting but feel free to add more ideas/opinion.

[findleyr]

@hyangah I am endeavoring to eliminate most if not all of the places where gopls scans the filesystem. (see e.g. https://go.dev/issue/56496). Gopls really shouldn't need to scan the filesystem, but does currently to discover modules and template files. Both of those operations can be changed to avoid a scan.

Currently, gopls doesn't translate directoryFilters to go list exclusions (though it could with a clever use of overlays). Therefore, I believe there is no good reason for directoryFilters to exist at all, and we should focus on exclusions that affect the Go command.