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: a package that ends with _test cannot have an internal test package #45477

Open
hajimehoshi opened this issue Apr 9, 2021 · 5 comments
Open

Comments

@hajimehoshi
Copy link
Member

@hajimehoshi hajimehoshi commented Apr 9, 2021

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

$ go version
go version devel go1.17-40d620781e Sat Apr 10 00:20:28 2021 +0900 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=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hajimehoshi/Library/Caches/go-build"
GOENV="/Users/hajimehoshi/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/hajimehoshi/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/hajimehoshi/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/hajimehoshi/go-code"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/hajimehoshi/go-code/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel go1.17-40d620781e Sat Apr 10 00:20:28 2021 +0900"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/hajimehoshi/go-code/src/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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/60/khbk2xqn1c5bml1byjn89dwc0000gn/T/go-build2286639433=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Prepare this test script in cmd/go/testdata/script and run this:

go test -v .

-- go.mod --
module example.com/pkg_test

go 1.17

-- pkg.go --
package pkg_test

-- pkg_test.go --
package pkg_test

What did you expect to see?

No compile error

What did you see instead?

This compile error:

found packages pkg_test (pkg.go) and pkg (pkg_test.go) in $WORK/gopath/src
@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Apr 9, 2021

@bcmills
Copy link
Member

@bcmills bcmills commented Apr 9, 2021

I agree that this is a bug. However, it seems like a low priority to fix, since basically nobody should have a package named pkg_test in the first place.

(But I do like to test these sorts of edge-cases just for completeness — and thanks for documenting this one!)

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Apr 9, 2021

It may be relevant here that it's possible to have a "test-only" package: one that has tests but no code. In that case, the package name can only inferred from package tests. Consider:

-- go.mod --
module example.com

go 1.16
-- a_test.go --
package pkg

import "testing"

func TestFoo(t *testing.T) {}

In this case, tests work and the package name is considered to be "pkg":

$ go test -v
=== RUN   TestFoo
--- PASS: TestFoo (0.00s)
PASS
ok  	example.com	0.087s
$ go list -f '{{.Name}}' 
pkg

If a_test.go is modified as follows:

-package pkg
+package pkg_test

That could be interpreted to mean "make the package name pkg_test" or "make this an external test file". It seems cmd/go picks the latter at this time:

$ go test -v            
=== RUN   TestFoo
--- PASS: TestFoo (0.00s)
PASS
ok  	example.com	0.268s
$ go list -f '{{.Name}}'
pkg

It's an example demonstrating a rare edge-case where it's not possible to specify a package name and whether the test is internal or external without ambiguity as long as normal package names with a "_test" suffix are allowed to exist.

(This might be quite irrelevant since the whether a test file is internal or external isn't very meaningful for a package that has only tests but no code.)

@bcmills
Copy link
Member

@bcmills bcmills commented Apr 9, 2021

@dmitshur, that's another neat edge-case!

I agree that it probably doesn't make much difference which direction we bias in that case, since AFAICT nothing else can import the test-only package. (Or, we could perhaps make some sort of heuristic decision about the likely package name based on the import path.)

@yunnian
Copy link

@yunnian yunnian commented Apr 11, 2021

another neat edge-case 😺

-- pkg.go --
package pkg_test

-- pkg_test.go --
package pkg_test_test

It's result is :

PASS
ok
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants