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

Jump to bottom

cmd/go: list prints leading underscore when given testdata directories #28155

Open
mvdan opened this issue Oct 11, 2018 · 4 comments
Open

cmd/go: list prints leading underscore when given testdata directories #28155

mvdan opened this issue Oct 11, 2018 · 4 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
Unplanned

Comments

@mvdan
Copy link
Member

mvdan commented Oct 11, 2018 •
edited

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

go version devel +c96c2a39bb Thu Oct 11 04:45:18 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes - checked on 1.11.1.

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mvdan/go/cache"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mvdan/go/land:/home/mvdan/go"
GOPROXY=""
GORACE=""
GOROOT="/home/mvdan/tip"
GOTMPDIR=""
GOTOOLDIR="/home/mvdan/tip/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build430264220=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Run go list ./testdata both in GOPATH and module mode.

Copy and paste this into a shell:

GOPATH=$(mktemp -d)
mkdir -p $GOPATH/src/foo.com/bar
cd $GOPATH/src/foo.com/bar
mkdir testdata
echo 'package foo' >testdata/foo.go
go list ./testdata
export GO111MODULE=on
go mod init foo.com/bar
go list ./testdata

What did you expect to see?

The same result in both cases.

What did you see instead?

$ GOPATH=$(mktemp -d)
$ mkdir -p $GOPATH/src/foo.com/bar
$ cd $GOPATH/src/foo.com/bar
$ mkdir testdata
$ echo 'package foo' >testdata/foo.go
$ go list ./testdata
_/tmp/tmp.rr2RmmLENC/src/foo.com/bar/testdata
$ export GO111MODULE=on
$ go mod init foo.com/bar
go: creating new go.mod: module foo.com/bar
$ go list ./testdata
foo.com/bar/testdata

Note that this only happens with testdata directories containing Go files. It doesn't happen with other directories that shouldn't be importable packages, like _foo.

First, I'm confused by the weird _/$GOPATH/src/$IMPORT_PATH string, when I was expecting just the import path. I couldn't find any piece of documentation about this format.

Second, I'm even more confused as to why this behaves differently depending on whether we're in GOPATH or module-aware mode.

This bug report is the result of digging a bit after the tests on a linter of mine were failing on 1.10. This was because go/types.Type.String() was returning mvdan.cc/unparam/check/testdata.FooType on Go 1.11 with GO111MODULE=on, but _/home/travis/gopath/src/mvdan.cc/unparam/check/testdata.FooType on Go 1.10 with GO111MODULE=on (since the env var is ignored there).

/cc @bcmills (and thanks to @rogpeppe and @myitcv, who helped me investigate)
@mvdan mvdan added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 11, 2018
@mvdan
Copy link
Member Author

mvdan commented Oct 11, 2018

Also, I realise that this _/full/path/to/directory format is used for Go packages outside of GOPATH when we're in GOPATH mode. However, that shouldn't apply here, as we're clearly inside $GOPATH/src.

mvdan added a commit to mvdan/unparam that referenced this issue Oct 12, 2018
@mvdan
CI: temporarily drop Go 1.10
12a4543 
At least until we figure out why 'go list' behaves in a weird way in
GOPATH mode. Go 1.10 doesn't have a module-aware mode like 1.11, so we
don't have an easy workaround at the moment.

See golang/go#28155.
@mvdan
Copy link
Member Author

mvdan commented Oct 26, 2018

I forgot to properly label this.

@bcmills bcmills added this to the Go1.13 milestone Nov 15, 2018
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@bcmills bcmills removed the modules label Jul 9, 2019
@bcmills bcmills modified the milestones: Go1.14, Unplanned Jul 9, 2019
@bcmills
Copy link
Contributor

bcmills commented Jul 9, 2019

As far as I can tell, this affects only GOPATH mode and only in pretty unusual edge-cases. I would be surprised if we are able to fix it before GOPATH mode is removed.

@mvdan
Copy link
Member Author

mvdan commented Jul 10, 2019

@bcmills sounds good. I think this issue only made sense a year ago, when GOPATH was still used in the majority of projects. Perhaps it can be left open for others to find it, until GOPATH mode is dropped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
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
Milestone
Unplanned
Development

No branches or pull requests
3 participants
@andybons @mvdan @bcmills