"go vet ." should be run in the package directory, not in subdirectories

[stefantalpalaru]

I have a subdirectory named "examples" in https://github.com/stefantalpalaru/pool and the default Go linter runs "go vet ." in that subdir instead of the package dir, leading to false positives for "examples/web_crawler.go".

There are two ways to fix this:

• make sure you always run that command in the project dir
• replace "go vet ." with "go tool vet some_file.go" as described here: cmd/vet: more clearly document go tool vet on a single file golang/go#23916

[w0rp]

Sounds good. Someone with knowledge of Go can pick this up whenever they want. go tool might be the way to go.

[arp242]

What kind of "false positive" do you get? It seems to work correctly as far as I can see?

You do have some compile errors in the examples package, as you're defining the same functions in both pool_example.go and web_crawler.go; is that what you mean?

[stefantalpalaru]

You do have some compile errors in the examples package

That's not a Go package. It's just a subdirectory for stand-alone examples.

you're defining the same functions in both pool_example.go and web_crawler.go

Those are compiled separately to generate different executables.

Both "go vet examples/web_crawler.go" and "go vet web_crawler.go" work properly, with no errors reported.

[arp242]

That's not a Go package. It's just a subdirectory for stand-alone examples.

Every directory within GOPATH with Go files is a package. See go help packages.

you're defining the same functions in both pool_example.go and web_crawler.go

Those are compiled separately to generate different executables.

This is not really something that Go supports; almost all Go tools – such as go build, go test, go install, etc. – are primarily designed to work on packages.

The most notable exception is go run file.go; the Go authors have repeatedly made it clear that it's only intended for simple "quick test" type of programs.

Stuff like go test ./... is now broken on your repo, for example.

The standard way to work around this sort of thing is to guard those files with build tags:

// +build ignore

package main

Since go run file.go ignores those tags, that will still work, while ensuring that all standard Go tools work.

Other than that, it seems to me that declaring the same function in the same package is exactly the kind of error that I would expect a linter to report?

[stefantalpalaru]

// +build ignore

This works for me.

Stuff like go test ./... is now broken on your repo, for example.

I don't know what you're trying to run there. It's just "go test" in the top dir and it works just fine.