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: go list fails with "no non-test Go files" but succeeds upon re-running #56018

Open
findleyr opened this issue Oct 4, 2022 · 0 comments
Labels
GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@findleyr
Copy link
Contributor

findleyr commented Oct 4, 2022

While working on an unrelated gopls bug, I stumbled into a scenario where go list fails non-deterministically depending on whether GOCACHE is populated.

Test setup: (from x/tools/gopls/internal/regtest/misc.TestImportTestVariant)

-- go.mod --
module mod.com

go 1.12
-- client/test/role.go --
package test

import _ "mod.com/client"

type RoleSetup struct{}
-- client/client_role_test.go --
package client_test

import (
	"testing"
	_ "mod.com/client"
	ctest "mod.com/client/test"
)

func TestClient(t *testing.T) {
	_ = ctest.RoleSetup{}
}
-- client/client_test.go --
package client

import "testing"

func TestClient(t *testing.T) {}

Notably client/test/role.go imports mod.com/client, which has no go files (an unintentional bug in the test setup). However, I observed that the entire workspace load fails for gopls in this scenario, due to the following go command bug:

$ go clean -cache
$ go list -compiled=true -- mod.com/...
go build mod.com/client: no non-test Go files in /tmp/gopls-regtest-3664541497/TestImportTestVariant/default/work/client
mod.com/client
mod.com/client/test
$ go list -compiled=true -- mod.com/...
mod.com/client
mod.com/client/test

The first time the go command runs, it returns a non-zero exit code with the "no non-test Go files" error printed to stderr. The second time, it succeeds with no error.

I see no reason for the error upon the first invocation, but even so the error should of course not depend on the state of the cache.

In my testing, this bug exists at least back to Go 1.12, so it's hard to make an argument for urgency (other than the fact that it just cost me two hours of debugging! :) )

CC @bcmills @adonovan

@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Oct 4, 2022
@bcmills bcmills added this to the Backlog milestone Oct 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

2 participants