Just found this one: #45488 - Are there any workarounds?

@powellnorma, don't set tags in GOFLAGS that overlap with GOOS tags? 😅

I'm not sure that this is really a bug in cmd/vet per se. GOFLAGS=-tags=windows specifies that files with //go:build windows should be included in packages, but your GOOS is set to linux, so vet is trying to analyze packages loaded from files for two different (and mutually exclusive) configurations.

(CC @matloob @timothy-king per https://dev.golang.org/owners)

don't set tags in GOFLAGS that overlap with GOOS tags?

Ok that helps, thank you - This works as expected: GOOS=windows go vet main.go

Fyi I didn't have a specific reason to not use GOOS, I just copied it from #29202 (comment)

Perhaps a warning could be displayed when tags are used that don't match the GOOS?

@bcmills @powellnorma - I have encountered the same issue yesterday go vet -tags=linux # internal/goos
and the same issue happens when you do go vet -tags=arm64 # internal/goarch

..\..\golang\go\src\internal\goarch\goarch_arm64.go:8:2: _ArchFamily redeclared in this block
        ..\..\golang\go\src\internal\goarch\goarch_amd64.go:8:2: other declaration of _ArchFamily
..\..\golang\go\src\internal\goarch\goarch_arm64.go:9:2: _DefaultPhysPageSize redeclared in this block
        ..\..\golang\go\src\internal\goarch\goarch_amd64.go:9:2: other declaration of _DefaultPhysPageSize
..\..\golang\go\src\internal\goarch\goarch_arm64.go:10:2: _PCQuantum redeclared in this block
        ..\..\golang\go\src\internal\goarch\goarch_amd64.go:10:2: other declaration of _PCQuantum
..\..\golang\go\src\internal\goarch\goarch_arm64.go:11:2: _MinFrameSize redeclared in this block
        ..\..\golang\go\src\internal\goarch\goarch_amd64.go:11:2: other declaration of _MinFrameSize
..\..\golang\go\src\internal\goarch\goarch_arm64.go:12:2: _StackAlign redeclared in this block
        ..\..\golang\go\src\internal\goarch\goarch_amd64.go:12:2: other declaration of _StackAlign
..\..\golang\go\src\internal\goarch\zgoarch_arm64.go:7:7: GOARCH redeclared in this block
        ..\..\golang\go\src\internal\goarch\zgoarch_amd64.go:7:7: other declaration of GOARCH
..\..\golang\go\src\internal\goarch\zgoarch_arm64.go:9:7: Is386 redeclared in this block
        ..\..\golang\go\src\internal\goarch\zgoarch_amd64.go:9:7: other declaration of Is386
..\..\golang\go\src\internal\goarch\zgoarch_arm64.go:10:7: IsAmd64 redeclared in this block
        ..\..\golang\go\src\internal\goarch\zgoarch_amd64.go:10:7: other declaration of IsAmd64
..\..\golang\go\src\internal\goarch\zgoarch_arm64.go:11:7: IsAmd64p32 redeclared in this block
        ..\..\golang\go\src\internal\goarch\zgoarch_amd64.go:11:7: other declaration of IsAmd64p32
..\..\golang\go\src\internal\goarch\zgoarch_arm64.go:12:7: IsArm redeclared in this block
        ..\..\golang\go\src\internal\goarch\zgoarch_amd64.go:12:7: other declaration of IsArm
..\..\golang\go\src\internal\goarch\zgoarch_arm64.go:12:7: too many errors

@matloob @timothy-king - I tried to run vet_test.go -> TestTags -> (c *Cmd) CombinedOutput() -> c.Stderr. is this stack data pushed into error?

go vet -tags=arm64 # internal/goarch

GOARCH=arm64 gotip vet should work as a short term solution. A longer term solution will take some investigation.

Thanks @timothy-king . I have done investigation and started a fix for that. It is not just for vet , impacts for build too. So testing more scenarios and here is the CL - https://go-review.googlesource.com/c/go/+/543675

Change https://go.dev/cl/543675 mentions this issue: cmd/vet: Fix for not including GOOS/GOARCH or both go files based on

@matloob

Issue Description :
When we give build flags with tags as one or more of the already existing Go variable values like GOOS and GOARCH,
go command process tries to include the file with the tag name like file_.go along with respective platform based files from internal/goos or internal/goarch.
This leads to conflicting constants in those go files which are generated by go generate.

For Example :

go vet -tags=linux main.go in darwin.

In this case, since we are doing that in darwin - internal/goos/zgoos_darwin.go is included and the command susequently includes the file mentioned in the tag //go:build linux, 
which is nothing but zgoos_linux.go. Both of these files have common available global contants. That gives the error message in the build process  - _**redeclared in this block**_ 

This issue is not limited to just GOOS for a combination of OS. This can happen to multiple combinations across OS platform. The same issue is possible for using 
GOARCH variable as a build tags for different architectures.

Uknown: This is pretty much possible for other Go variable which may need to be investigated.

Impact: The same issue happens in go build process and leads to build failure.
The error message is unclear and doesn't point towards the fix.

Fix Approaches:

1. Identify the conflicting tags against Go variable tags and error out notifying the user to fix it - This is pretty safe approach.

2. Fixing it for higher level for go vet and go build command (Have separate fixes by ignoring the conflicting tags) and safely run the command - Independent handling and flexibility to change(Feels like duplicate effort).

3. Fixing at build.go as to ignore the conflicting tag files(Based on OS/ARCH currently) in all associated build process- This needs careful testing as almost all go command uses this file and common fix for all. (Preferred approach) . We can grab known OS or ARCH from a common file which can be used here for ignoring respective tags.

I agree with @bcmills that this doesn't seem to be a bug.

It is expected not to include both os files under internal/goos for windows and linux. But it does(Pls correct my understanding). This happens for go build too.
So we have to have a way to ignore conflicting env variable values and the same used as flag. This is what I am thinking.

@bcmills - your thoughts.

@raghvenders, we do not expect Go users to set -tags=windows explicitly, since that tag is reserved to mean GOOS=windows.

(There may be some tools — such as static analyzers — that set it explicitly in go list to get additional files, but those tools do not expect to also run the Go compiler in that configuration.)

This is not a bug, and it is not about go vet. Using GOOS=linux go build -tags windows runtime fails as well.
I think we can close this as not a bug.