x/tools/gopls: spurious errors reported with go1.17 and mage

[Michael-F-Ellis]

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

Version Information

• Run go version to get version of Go from the VS Code integrated terminal.
  • go version go1.17.2 darwin/amd64
• Run gopls -v version to get version of Gopls from the VS Code integrated terminal.
  • golang.org/x/tools/gopls v0.7.3
    golang.org/x/tools/gopls@v0.7.3 h1:Lru57ht8vtDMouRskFC085VAjBAZRAISd/lwvwOOV0Q=
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/google/go-cmp@v0.5.6 h1:BKbKCqvP6I+rmFHt06ZmyQtvB8xAkWdhFyr0ZUNZcxQ=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.4.2 h1:Gz96sIWK3OalVv/I/qNygP42zyoKp3xptRVCWRFEBvo=
    golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
    golang.org/x/sys@v0.0.0-20210809222454-d867a43fc93e h1:WUoyKPm6nCo1BnNUvPGnFG3T5DUVem42yDJZZ4CNxMA=
    golang.org/x/text@v0.3.6 h1:aRYxNxv6iGQlyVaZmk6ZgYEDa+Jg18DxebPSrd6bg1M=
    golang.org/x/tools@v0.1.8-0.20211014194737-fc98fb2abd48 h1:hk7xRoeg0CG1nRLsd5BZLDUgVpA9bnKylGk1p2/BPH0=
    golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
    honnef.co/go/tools@v0.2.0 h1:ws8AfbgTX3oIczLPNPCu5166oBg9ST2vNs0rcht+mDE=
    mvdan.cc/gofumpt@v0.1.1 h1:bi/1aS/5W00E2ny5q65w9SnKpWEF/UIOqDYBILpo9rA=
    mvdan.cc/xurls/v2@v2.3.0 h1:59Olnbt67UKpxF1EwVBopJvkSUBmgtb468E4GVWIZ1I=
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.
  • 1.61.2
    6cba118ac49a1b88332f312a8f67186f7f3c1643
    x64
• Check your installed extensions to get the version of the VS Code Go extension
  • v0.28.1

• Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > Go: Locate Configured Go Tools command.

Share the Go related settings you have added/edited

Settings

"gopls": { "buildFlags": [ "-tags=mage" ] }, "go.testFlags": [ "-count=1" ], "go-template.patterns": [ "*.tpl", "*.go.tpl", "**/*.tpl" ], "go.toolsManagement.autoUpdate": true,

### Describe the bug

Briefly, the problem is that vscode reports a slew of errors even though the code in the repo builds and runs with no errors or warnings from mage, go vet or go build.

The problem appears to be that vscode (via gopls) isn't honoring the //go:build mage directive in mypkg/magefile.go.

The complaints seems to originate because magefiles want to have package main specified.

I can make the vscode complaints go away by changing that to package mypkg, but then mage is no longer able to run.

I've used mage in this manner prior to the advent of go1.17 in large projects requiring extensive code generation without getting vscode complaints.

Steps to reproduce the behavior:

I've created a minimal example that reproduces the problem in a public repo.

git clone https://github.com/Michael-F-Ellis/magegopls
cd magegopls
code .

1. Observe list of errors in the vscode Problems tab.
2. Open terminal and run go vet. Observe no problems reported.
3. If you have mage installed, run mage -v
4. Observe that the code builds and runs with output similar to the following:

exec: mage -v generate
Running target: Generate
exec: go build
exec: ./magegopls
Generated at 2021-10-21 13:23:28.031119 -0400 EDT m=+0.000218297

[seankhliao]

Note you've set "buildFlags": [ "-tags=mage" ] . go build -tags mage fails similarly.

[Michael-F-Ellis]

Note you've set "buildFlags": [ "-tags=mage" ] . go build -tags mage fails similarly.

If I delete that setting, I get the following warning:

No packages found for open file /private/tmp/magegopls/magefile.go: <nil>.
If this file contains build tags, try adding "-tags=<build tag>" to your gopls "buildFlags" configuration (see (https://github.com/golang/tools/blob/master/gopls/doc/settings.md#buildflags-string).
Otherwise, see the troubleshooting guidelines for help investigating (https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md).

[findleyr]

Thanks for reporting. We want to understand this, and will investigate with your reproducer. It is however a busy time on the Go team, so this might take a couple weeks.

[MaurGi]

+1 happens on my project as well

magefile starts with:

//go:build mage
// +build mage

but I still get:

No packages found for open file /home/maurgi/go/src/goms.io/aks/aksiknife/magefile.go: <nil>.
If this file contains build tags, try adding "-tags=<build tag>" to your gopls "buildFlags" configuration (see (https://github.com/golang/tools/blob/master/gopls/doc/settings.md#buildflags-string).
Otherwise, see the troubleshooting guidelines for help investigating (https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md).

[findleyr]

A couple week turned into a couple months I'm afraid, due to Go 1.18 busyness. Putting this in the v0.8.0 release, though see below about our options for improving this.

Looking at it again, I'm not sure what is desired here. The diagnostics of the form No packages found for open file ...magefile.go: <nil>. exist because gopls doesn't naively know what to do with magefiles. They are not loaded with the current build tags, and therefore most functionality won't work. That diagnostic exists to alert users to this fact. Of course, by telling gopls to use -tags=mage, these files will be included in a package with other files in the directory, causing errors.

For most build tags, this is the correct behavior: gopls can't always guess the combinations of build tags that lead to a valid package, and wants to avoid presenting spurious errors by guessing wrong. However, for some build tags (such as "ignore"), there is an implicit convention that the files should be considered part of a single-file package.

For mage users: is it always the case that magefiles should type-check as a single package? If we had a gopls setting like "singleFileBuildTags", which defaulted to ["ignore"], would you be able to address your use-case by setting this to ["ignore", "mage"]?