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

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

Closed
jayconrod opened this issue Sep 15, 2020 · 8 comments
Closed
Labels
NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@jayconrod
Copy link
Contributor

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.

@jayconrod jayconrod added the NeedsFix The path to resolution is known, but the work has not been done. label Sep 15, 2020
@jayconrod jayconrod added this to the Go1.16 milestone Sep 15, 2020
@jayconrod jayconrod added the okay-after-beta1 Used by release team to mark a release-blocker issue as okay to resolve either before or after beta1 label Nov 30, 2020
@toothrot toothrot removed the okay-after-beta1 Used by release team to mark a release-blocker issue as okay to resolve either before or after beta1 label Dec 17, 2020
@bcmills bcmills modified the milestones: Go1.16, Go1.17 Jan 5, 2021
@gopherbot
Copy link

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

@iwdgo
Copy link
Contributor

iwdgo commented Apr 19, 2021

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

Is there anything else to do here?

@iwdgo
Copy link
Contributor

iwdgo commented May 4, 2021

Maybe a test of the specific go list commands.

@jayconrod jayconrod modified the milestones: Go1.17, Backlog May 4, 2021
@jayconrod
Copy link
Contributor Author

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

bcmills commented May 4, 2021

This may be fixed incidentally when we address #45827.

@iwdgo
Copy link
Contributor

iwdgo commented Jul 3, 2021

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

iwdgo commented Nov 3, 2023

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

@bcmills bcmills closed this as completed Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants