cmd/go: wildcard should consistently match package with invalid build tags

[jayconrod]

What version of Go are you using (go version)?

$ go version
go version go1.15.2 darwin/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jayconrod/Library/Caches/go-build"
GOENV="/Users/jayconrod/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/jayconrod/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/jayconrod/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/go/installed"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/go/installed/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/jayconrod/Code/test2/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rq/x0692kqj6ml8cvrhcqh5bswc008xj1/T/go-build456970586=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Create a package in GOPATH with one file containing an invalid build tag.

-- go.mod --
module m

go 1.16
-- bad.go --
// +build !foo-bar

package bad

Run the two commands below from the module directory in GOPATH mode and module mode.

go list m/...
go list ./...

What did you expect to see?

Package m listed by both commands in both modes.

What did you see instead?

In GOPATH mode:

$ go list m/...
m
$ go list ./...
m

In module mode:

$ go list m/...
go: warning: "m/..." matched no packages
$ go list ./...
m

The modload package uses different code to match package patterns and directory patterns. It looks like the package pattern matching code ignores files with invalid tags, so the directory appears to contain no files. We should include those files instead and maybe report errors later when loading packages.

[gopherbot]

Change https://golang.org/cl/305670 mentions this issue: cmd/go: print deprecation notice for 'go get cmd'

[iwdgo]

On tip, messages are now identical. Some refactoring took place and has aligned behavior.
The issue as formulated seems solved.

go version devel go1.17-fd3612e433 Sat Apr 17 00:02:01 2021 +0000 windows/amd64

 > env GO111MODULE=off
 > go list m/...
 [stderr]
 go: warning: "m/..." matched no packages
 > stderr 'go: warning: "m/..." matched no packages'
 > go list ./...
 [stdout]
 _/<temporary directory path>/gopath/src
 > stdout m
 > env GO111MODULE=on
 > go list m/...
 [stderr]
 go: warning: "m/..." matched no packages
 > stderr 'go: warning: "m/..." matched no packages'
 > go list ./...
 [stdout]
 m
 > stdout m
 PASS

[ianlancetaylor]

Is there anything else to do here?

[iwdgo]

Maybe a test of the specific go list commands.

[jayconrod]

It's good that the behavior is now consistent, but it would be better for go list m/... to match and report packages with errors.

[bcmills]

This may be fixed incidentally when we address #45827.

[iwdgo]

On tip (go1.17-b5df4522e6), the behavior is described in the earlier comment is unchanged. Regarding listing modules, the flag -m is usable when GO111MODULE=on. No match for the package (go list m/...) seems consistent with the difference between package and module. A discussion about matching using ... is also #37227.

> go list -m m/...
[stdout]
m
> stdout m

[iwdgo]

The behavior described in the issue is fixed as expected in the above comment

$ gotip version
go version devel go1.22-8c92897e15 Fri Oct 27 17:54:18 2023 +0000 windows/amd64
$ go list m/...
m
$ go list ./...
m