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/cover: cannot run in directory with no .go files #33855

Closed
rhysh opened this issue Aug 27, 2019 · 7 comments
Closed

cmd/cover: cannot run in directory with no .go files #33855

rhysh opened this issue Aug 27, 2019 · 7 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@rhysh
Copy link
Contributor

rhysh commented Aug 27, 2019

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

$ go1.12 version
go version go1.12.9 darwin/amd64
$ go1.13 version
go version go1.13rc1 darwin/amd64

Does this issue reproduce with the latest release?

This problem is present on go1.13rc1. It is not present in go1.12.9.

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

go env Output
$ go1.13 env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/rhys/Library/Caches/go-build"
GOENV="/Users/rhys/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/rhys/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/Users/rhys/go/version/go1.13"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/Users/rhys/go/version/go1.13/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/tmp/mymod/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/49/zmds5zsn75z1283vtzxyfr5hj7yjq4/T/go-build267819565=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

$ mkdir /tmp/mymod
$ cd /tmp/mymod
$ go mod init mymod
$ go tool cover -func=/dev/null

What did you expect to see?

$ go1.12 tool cover -func=/dev/null
total:	(statements)	0.0%

What did you see instead?

$ go1.13 tool cover -func=/dev/null
cover: cannot run go list: exit status 1
build .: cannot find module for path .

git bisect points to 4a2d3d0 (authored in December, but committed in July) as the first "bad" commit.

@bcmills
Copy link
Contributor

bcmills commented Aug 27, 2019

As far as I can tell, this is the same underlying issue as #33157.

go list cannot in general assume that an empty directory corresponds to a particular package path, because that package path may actually exist (and contain .go source files) in some other module with a common path prefix.

@rhysh, is there a particular reason you need or expect go tool cover to work in a directory that does not contain a Go package?

CC @jayconrod @stamblerre @matloob

@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Aug 27, 2019
@bcmills bcmills added this to the Unplanned milestone Aug 27, 2019
@rhysh
Copy link
Contributor Author

rhysh commented Aug 27, 2019

Is there a particular reason you need or expect go tool cover to work in a directory that does not contain a Go package?

For background, this is part of an import of go1.13rc1 into my company's build system. The build scripts worked with go1.12.x and earlier, and work with go1.13beta1.

The build scripts run the tests for several packages with code coverage enabled. They then convert the raw coverage reports into html. It's that conversion from raw to html that encounters the problem. Why should the current working directory have an effect on how a raw coverage report is converted into html? Why does go tool cover run go list when converting report formats?

@rhysh
Copy link
Contributor Author

rhysh commented Aug 27, 2019

It looks like the problem is in cmd/cover.findPkgs: when there are no packages represented in the coverage profile, the meaning of go list $packages changes from explicitly listing packages (which exist) to doing an implicit lookup of the package in the current directory (which might not exist).

The call to go list should be gated by the coverage profile containing at least one package. https://github.com/golang/go/blob/go1.13rc1/src/cmd/cover/func.go#L197

Do the integration tests for this code live in src/cmd/go/testdata/script? I don't see any there currently.

@gopherbot
Copy link

Change https://golang.org/cl/192340 mentions this issue: cmd/cover: skip go list when profile is empty

@bcmills
Copy link
Contributor

bcmills commented Aug 29, 2019

Do the integration tests for this code live in src/cmd/go/testdata/script?

I'm not sure, but the new test seems fine there to me.

@rhysh
Copy link
Contributor Author

rhysh commented Aug 30, 2019

@gopherbot, please backport to Go 1.13: this is a regression from Go 1.12.

@gopherbot
Copy link

Backport issue(s) opened: #33983 (for 1.12), #33984 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

tomocy pushed a commit to tomocy/go that referenced this issue Sep 1, 2019
Only call "go list" when explicitly listing packages. An empty coverage
profile references no packages, and would otherwise lead to "go list"
implicitly looking at the package in "." (which might not exist).

Fixes golang#33855

Change-Id: I02d4e374405d86f03d105fe14648aa03b4d2284c
Reviewed-on: https://go-review.googlesource.com/c/go/+/192340
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
t4n6a1ka pushed a commit to t4n6a1ka/go that referenced this issue Sep 5, 2019
Only call "go list" when explicitly listing packages. An empty coverage
profile references no packages, and would otherwise lead to "go list"
implicitly looking at the package in "." (which might not exist).

Fixes golang#33855

Change-Id: I02d4e374405d86f03d105fe14648aa03b4d2284c
Reviewed-on: https://go-review.googlesource.com/c/go/+/192340
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@golang golang locked and limited conversation to collaborators Aug 29, 2020
@rsc rsc unassigned bcmills Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

3 participants