Go linter in VS code not working for packages across multiple files?

Question

I have installed the Go extension (version 0.11.4) in Visual Studio Code on MacOS:

However, I find that the linter does not 'pick up' functions defined in the same package, but in different files. For example, if I create in the same directory a file foo.go with

package foobar

import "fmt"

func main() {
    fmt.Println(SayHello())
}

and a file bar.go with

package foobar

func SayHello() string {
    return "Hello, world!"
}

then in foo.go I get a linter error that SayHello is an undeclared name:

I've read about a similar issue here (https://github.com/golang/lint/issues/57), but since that issue is five years old I figured it might be fixed by now? Or does golint simply not work across multiple files?

Which lint tool you're using? `golint`, `golangci-lint`, other? Check settings `go.lintTool` then try to run linter from command line. — Alex Yu, Sep 20 '19 at 09:39

score 69 · Answer 1 · edited Feb 16 '22 at 20:32

[The original answer is outdated; here is up-to-date information provided by the vscode-go maintainers. The updated answer is now marked as "Recommended" in the Go collective]

The plugin has changed a lot since 2019.

In 2021, Go Modules became the default which may have changed how the program is built and analyzed.
The vscode-go plugin uses gopls as the language server by default. Note that in 2019, there were two different language servers and gopls was still in experimental mode.
golint was deprecated.

If you still have a similar issue, it's likely that you are seeing a different problem.

Please check the followings:

Do you have go.mod? Otherwise, initialize your working module and restart the language server or reload the window.
Is the go.mod file in the root directory of your workspace? See gopls workspace setup guide for complex setup.
Do you use build tags or other build constraints? Then see issue 29202. You may need to configure "go.buildTags" or "go.buildFlags".
If you expect lint errors from linters like staticcheck, golangci-lint, ..., check "go.lintOnSave" is set to the right scope.

If you notice that restarting the language server ("Go: Restart Language Server" command) fixes your issue, that's a gopls bug. Please consider to file an issue in github.com/golang/vscode-go following the troubleshooting guide.

Otherwise, please open a new question with details.

----- Original answer -------

I faced same problem. I found that I got into this problem after enabling "Go language server" which is an experimental feature. I disabled it in VS code settings->Go Configuration and after that the problem went away.

2022(almost) update: I actually had to install Go language server for it to start working... — Chemdream, Dec 28 '21 at 16:15
Disabling and then re-enabling worked for me.. when i disabled VSCode for go no longer understood "package main", so had to re-enable it — Cpp crusaders, Jan 01 '22 at 15:02
My problem was that, without changing it myself, the "go.lintOnSave" setting had been changed globally to "file" instead of "package". Maybe a bad old config from a previous version that got ported over? It seems "package" is supposed to be the default. — Gbps, Mar 06 '22 at 22:13
I had the same problem. I went through everything in the updated answer, however what ultimately fixed it was disabling the "Go: Language Server Experimental Features" setting. — rchapin, Mar 28 '22 at 08:39

Khoa Le · Answer 2 · 2022-05-08T09:16:02.077

59

Update VS Code Go Tool might help. Command + Shift + P -> Go: Install/update tools Install all tools and restart VS Code.

May 2022 update:

This solution only works if you haven't installed the helper tools. Normally after you installed these packages it'll work right away with the default configuration, if you still have a problem, take a look at the answer above.

edited May 08 '22 at 09:16

answered Sep 20 '19 at 05:03

Khoa Le

709
4
4

It is worth noting that I had installed/uninstalled the Go extension and checked the language server was enabled, but I was still having issues until I manually updated the VS Code Go Tools. – confusedandamused Sep 08 '22 at 06:58
1

I did. that didn't help – Hari Kishore Oct 03 '22 at 16:00

score 33 · Answer 3 · answered Apr 30 '21 at 14:15

33

The cause of this warning for me was the setting go.lintOnSave, which was set to file. Changing the value to package made the linter correctly pick up the types defined in other files.

answered Apr 30 '21 at 14:15

3ventic

1,023
1
20
32

This solution was the correct one for me. **Use Language Server** was already unchecked on mine and updating _go_ tools did not work for me. – RisingSun Jul 01 '21 at 21:17
Worked for me (y) – hungdoansy Oct 21 '21 at 04:49
Yes! Thank you! – Gabriel Oct 31 '21 at 12:57
I haven't logged in to SO in FOREVER. I did so just to tell you I <3 you. – Micah Nov 03 '21 at 01:25

Hana · Answer 4 · 2022-02-15T19:33:58.373

For people who ended up here:

The plugin has changed a lot since 2019.

In 2021, Go Module became the default which may have changed how the program is built and analyzed.
The vscode-go plugin uses gopls as the language server by default. Note that in 2019, there were two different language servers and gopls was still in experimental mode.
golint was deprecated.

If you still have a similar issue, it's likely that you are seeing a different problem.

Please check the followings:

Do you have go.mod? Otherwise, initialize your working module and restart the language server or reload the window.
Is the go.mod file in the root directory of your workspace? See gopls workspace setup guide for complex setup.
Do you use build tags or other build constraints? Then see issue 29202. You may need to configure "go.buildTags" or "go.buildFlags".
If you expect lint errors from linters like staticcheck, golangci-lint, ..., check "go.lintOnSave" is set to the right scope.

If you notice that restarting the language server ("Go: Restart Language Server" command) fixes your issue, that's a gopls bug. Please consider to file an issue in github.com/golang/vscode-go following the troubleshooting guide.

Otherwise, please open a new question with details.

score 9 · Answer 5 · answered Oct 29 '21 at 08:59

9

Update Install/update tools for GO
Open your code as main project in VS Code and avoid multiple projects/workspace in the same VS Code. **

Single Project VS Code

**

Avoid Multiple Project in VS Code

**

answered Oct 29 '21 at 08:59

junnyea

471
6
8

score 3 · Answer 6 · answered Feb 08 '21 at 07:39

3

If you run across this and are NOT using modules, then adding "go.useLanguageServer": false will disable gopls and return you to your former environment. (meaning vscode will now recognize functions and structures defined in multiple files in the same package)

answered Feb 08 '21 at 07:39

Richard Varno

537
6
8

4

What if we are using modules? – nsrCodes Feb 16 '21 at 16:14

score 3 · Answer 7 · answered Oct 12 '21 at 12:41

3

In my case it was a missing go.mod file. I fixed with the following command:

go mod init example.com/myProject/myModule

Of course you should use a more reasonable module name.

answered Oct 12 '21 at 12:41

iBug

35,554
7
89
134

score 1 · Answer 8 · edited Oct 13 '21 at 12:50

1

Make clean uninstall of vscode and then it's work fine again...

add sudo if you needed to

rm -rf $HOME/Library/Application\ Support/Code

rm -rf $HOME/.vscode

Remove vscode from application

Download vscode and install again

edited Oct 13 '21 at 12:50

Zoe

27,060
21
118
148

answered Sep 20 '19 at 13:23

SebastianSalvatore

47
6

score 1 · Answer 9 · answered May 05 '22 at 14:16

1

One possible reason:

If you are referencing a function/variableis declared in a test file (*_test.go) from a non test file, this error would be thrown.

answered May 05 '22 at 14:16

Siva Prakash

4,626
34
26

score 1 · Answer 10 · answered Jun 17 '22 at 19:59

1

In my case, I just restarted VS Code and the error went away.

answered Jun 17 '22 at 19:59

Poçi

243
3
8

score 1 · Answer 11 · answered Jun 28 '23 at 23:44

Most of the answers here do not cover the buildtags scenario. The error messages do not do a good job pointing to this. If none of the other solutions work out, it might very well be that a module you're using uses a build tag. Search your codebase (cmd + shift + f or the magnifying glass icon on the left bar) for //go:build. In my case I had a:

//go:build linux

and this was the root of my problems. To make gopls aware of this, you must add the following configuration to settings.json

{ //your settings.json
  //...,
  "gopls": {
    "build.buildFlags": ["-tags=linux"],
  },
  //...
}

note your build flag may be different so replace linux with whatever yours is. You may specify more than one tag eg ["-tags=linux,tag1,tag2,etc"].

This worked out for me but if it doesn't you may find other unfortunate souls dealing with this here and hope someone has a solution for a similar enough environment to yours.

score 0 · Answer 12 · answered Sep 07 '20 at 16:54

After almost pulling my hair out, I found that linting was working but I had many files with errors. I haven't yet found the hierarchy followed but fixing problems in one file subsequently led to it correctly linting another file. I think it follows the execution tree, although I haven't validated this. I found this annoying as it can mistakenly lead you to think that linting is not working, while in fact, it's lining a file that you're not currently focussed on, especially if you have generated files that you're not interested in.

score 0 · Answer 13 · answered Aug 25 '21 at 19:47

Another solution might be that you need to have the folder opened in VS Code with the go.mod file included. So you might have a folder structure that looks like workspace/application/modules/xyz.go. If you have the go.mod file in the application folder and modules is the folder you have open in VS Code it will complain.

score 0 · Answer 14 · answered Mar 17 '22 at 01:57

I came across this issue by having the go extension installed, and attempting to utilize the same package name with a module under a different directory.

Files at Root: main.go, a.go, and go.mod
Sub-directory: nested/b.go

Problem: Attempting to label b.go as package main when it is under a different directory.

Solutions:

Move b.go up to project root and retain package name; all works as expected,

or

Change package name of b.go from package main to package nested, then add imports for b.go to main.go via:

// main.go
package main

import "example/nested"

func main() {
    A()
    nested.B()
}

and b.go:

// b.go
package nested

import "fmt"

func B() {
    fmt.Println("Hello from B")
}

Go linter in VS code not working for packages across multiple files?

14 Answers14

Linked