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

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).

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.

+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).

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"]?

FWIW, I have a project with multiple folders containing multiple magefiles. All my magefiles have no build tags other than //go:build mage. No magefile provides code that is used by the package it builds.

As mentioned in my original post, go vet doesn't return errors. Can you help me understand what limitations gopls has that go vet doesn't?

As mentioned in my original post, go vet doesn't return errors. Can you help me understand what limitations gopls has that go vet doesn't?

Vet has the same limitation as gopls. Suppose I put an arbitrary vet error into your magefile -- say a bad string(int) conversion string(2). In this case, consider the following command line session, from the root of Michael-F-Ellis/magegopls.

> go vet
> go vet -tags=mage
main.go:4:2: import "github.com/Michael-F-Ellis/magegopls/mypkg" is a program, not an importable package
> go vet magefile.go
# command-line-arguments
./magefile.go:33:42: conversion from untyped int to string yields a string of one rune, not a string of digits (did you mean fmt.Sprint(x)?)

With the first command, vet does not find the error in magefile.go, because it's guarded by build tags. With the second command, it can't build mypkg, because of the package main in mypackage/magefile.go. With the third ocmmand, we tell vet to specifically consider magefile.go to be its own package.

So as you can see, vet has the same limitation that without more information, it doesn't know what files are intended to constitute a package. I am guessing that mage has some convention around how to build a package out of magefiles. What I'm proposing is a rule that would allow users to encode the convention of "files guarded by this build tag should always be considered a standalone package", but I don't know enough about mage to determine if this is sufficiently expressive.

So, I think a lot of the problem here is likely due to how Mage works when you have mage files interleaved with non-mage files.

Mage does some tricks to only build the files with the mage build tag in the current directory. This is different from how normal Go build tools work, where if you specify a build tag, it by default just adds files with that build tag to those without that mage build tag, and builds all of them.

The problem comes with the fact that Mage needs the code in magefiles to be in package main, which will cause conflicts if you set the mage build tag on your editor/gopls, and have a package in the same directory that is not package main, because then gopls will see two different packages in the same directory.

Also, because Mage generates the code for func main(), magefiles will be in package main, but won't have a main function, which will cause some tools to complain.

This is something the Mage team is trying to address. We just released mage v1.13, which adds support for putting your magefiles in a subdirectory, so they don't have to be in the same folder as other go code, and you don't need the mage build tag, and won't ever have two different packages in the same directory.

Note that we just release v1.13 of Mage, which adds support for moving your magefiles out of the root directory and into a subdirectory, so you don't need them interleaved with other go files, and don't need the build tag anymore (the old way is still supported, but causes problems with gopls as you've noticed).

See here for details: https://magefile.org/blog/2022/03/release-v1.13.0/

I get a similar error if I merely rename a Go source file, such as iDictionary.go to idictionary.go. There is no iDictionary.go file, but if I double-click the error, VS Code opens the idictionary.go as iDictionary.go. I also get lots of weird mangled reformating / undoing code changes if I press Ctrl-S on the idictionary.go file.

Hi folks,

I recently added a feature to gopls (not yet released) such that gopls can detect certain files as "standalone main files", meaning that gopls recognizes that they are intended to be standalone packages, such as with //go:build ignore or //go:build mage. Would someone using mage be willing to try it out and provide feedback?

To use this feature, you will first need to install the prerelease version of gopls:

go install golang.org/x/tools/gopls@v0.10.0-pre.1

Then you will need to configure your editor to set the new "standaloneTags" setting, which is the list of build tags gopls recognizes as special, indicating a standalone main file. The default value is ["ignore"], so you'll need to change this setting to ["ignore", "mage"], or any list that includes "mage".

Please reply here with any feedback, as I believe this new feature should resolve this issue. Thank you!

Ok, closing this as I believe it should be addressed by the new setting. Please comment or re-open if this isn't working for you.