Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Michael-F-Ellis opened this issue Oct 21, 2021 · 10 comments
Open

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

Michael-F-Ellis opened this issue Oct 21, 2021 · 10 comments
Labels
gopls/metadata Issues related to metadata loading in gopls gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@Michael-F-Ellis
Copy link

Michael-F-Ellis commented Oct 21, 2021

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

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
@suzmue suzmue changed the title Spurious errors reported with go1.17 and mage x/tools/gopls: spurious errors reported with go1.17 and mage Oct 21, 2021
@suzmue suzmue transferred this issue from golang/vscode-go Oct 21, 2021
@seankhliao
Copy link
Member

seankhliao commented Oct 21, 2021

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

@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Oct 21, 2021
@gopherbot gopherbot added this to the Unreleased milestone Oct 21, 2021
@Michael-F-Ellis
Copy link
Author

Michael-F-Ellis commented Oct 21, 2021

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 findleyr added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 27, 2021
@findleyr findleyr modified the milestones: Unreleased, gopls/on-deck Oct 27, 2021
@findleyr
Copy link
Contributor

findleyr commented Oct 27, 2021

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
Copy link

MaurGi commented Jan 7, 2022

+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 findleyr modified the milestones: gopls/on-deck, gopls/v0.8.0 Jan 7, 2022
@findleyr
Copy link
Contributor

findleyr commented Jan 7, 2022

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

@Michael-F-Ellis
Copy link
Author

Michael-F-Ellis commented Jan 8, 2022

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?

@findleyr
Copy link
Contributor

findleyr commented Jan 9, 2022

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.

@natefinch
Copy link
Contributor

natefinch commented Mar 16, 2022

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.

@natefinch
Copy link
Contributor

natefinch commented Mar 18, 2022

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/

@findleyr findleyr added this to the gopls/on-deck milestone Apr 5, 2022
@findleyr findleyr added the gopls/metadata Issues related to metadata loading in gopls label Apr 11, 2022
@CarlMCook
Copy link

CarlMCook commented Aug 29, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls/metadata Issues related to metadata loading in gopls gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

7 participants