cmd/go: go list mangles absolute paths weirdly

[segevfiner]

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

$ go version
go version go1.11.4 windows/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
set GOARCH=amd64
set GOBIN=
set GOCACHE=<snip>\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=<snip>\go
set GOPROXY=
set GORACE=
set GOROOT=<snip>\go
set GOTMPDIR=
set GOTOOLDIR=<snip>\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=<snip>\AppData\Local\Temp\go-build323227346=/tmp/go-build -gno-record-gcc-switches

What did you do?

1. Create foo/main.go somewhere outside GOPATH:

package main

func main() {

}

2. cd to that directory and run go list.

What did you expect to see?

The full absolute path to the directory:

C:/Users/User/foo

What did you see instead?

The full absolute path to the directory mangled:

_/C_/Users/User/foo

[novasharper]

This is actually the valid output

// dirToImportPath returns the pseudo-import path we use for a package
// outside the Go path. It begins with _/ and then contains the full path
// to the directory. If the package lives in c:\home\gopher\my\pkg then
// the pseudo-import path is _/c_/home/gopher/my/pkg.
// Using a pseudo-import path like this makes the ./ imports no longer
// a special case, so that all the code to deal with ordinary imports works
// automatically.
func dirToImportPath(dir string) string {
	return pathpkg.Join("_", strings.Map(makeImportValid, filepath.ToSlash(dir)))
}

cmd/go/internal/load/pkg.go#L393

[bcmills]

In GOPATH mode you cannot import things that reside outside of GOPATH (except, perhaps, as relative imports). So it shouldn't really matter what the actual import path is: it only shows up in a few places (e.g. reflect).

In module mode, the go.mod file in (a parent of) the current directory defines its import path.
Given that, I don't think this is worth changing at this point.

[segevfiner]

The only reason I saw this was accidently placing something outside GOPATH that isn't a module and having errors in vscode-go due to the output of go list. It's your call whether you actually care about this or not...