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: modules vendoring themselves can cause panics with type assertions #31681

Closed
tom-hadlaw-hs opened this issue Apr 25, 2019 · 2 comments
Closed

Comments

@tom-hadlaw-hs
Copy link

@tom-hadlaw-hs tom-hadlaw-hs commented Apr 25, 2019

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

Go 1.11.5

Does this issue reproduce with the latest release?

Yes

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

go env Output
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tom.hadlaw/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tom.hadlaw/Documents/Code/go19"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/x0/4hvqwj_n7zb6pb98kt__sr8m0000gp/T/go-build417046013=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

You need to create 2 modules, say m0 and m1

m0 contains 2 submodules, say a and b
m1 contains a main function to run the code

m0/a/a.go:

package a

import "github.com/pod/m0/b"

func Bar() interface{} {
        return b.Foo{}
}

m0/b/b.go:

package b

type Foo struct{}

m1/main.go

package main

import (
	"fmt"

	"github.com/pod/m0/a"
	"github.com/pod/m0/b"
)

func main() {
	i := a.Bar()
	a := i.(b.Foo)
	fmt.Println(a)
}
.
├── m0
│   ├── a
│   │   └── a.go
│   ├── b
│   │   └── b.go
│   └── vendor
│       └── github.com
│           └── pod
│               └── m0
│                   ├── a
│                   │   └── a.go
│                   └── b
│                       └── b.go
└── m1
    └── main.go

The run go run main.go

What did you expect to see?

Type assertion should've happened with no issue.

What did you see instead?

The following confusing panic:

panic: interface conversion: interface {} is b.Foo, not b.Foo (types from different packages)

goroutine 1 [running]:
main.main()
        /Users/tom.hadlaw/Documents/Code/go19/src/github.com/pod/m1/main.go:12 +0x45
exit status 2

This is just a case I was able to use to easily recreate the issue. I ran into this because I was using an external library that for some reason vendors itself (i've created an issue over there as well). I'm not sure why someone would vendor the package in that way, regardless the error I got from it was confusing (i.e the panic message saying interface{} is T, not T).

@katiehockman katiehockman changed the title Modules vendoring themselves can cause panics with type assertions cmd/go: modules vendoring themselves can cause panics with type assertions Apr 30, 2019
@katiehockman

This comment has been minimized.

Copy link
Member

@katiehockman katiehockman commented Apr 30, 2019

/cc @bcmills

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Apr 30, 2019

Note the GOMOD="" line in the go env output: this go run command is running in GOPATH mode, not module mode.

In GOPATH mode, main.go should be compiled using dependencies from GOPATH (that is, ignoring the vendor subdirectory of the current directory), whereas a should be compiled using its vendored b. So this seems to be working as designed for GOPATH mode.

As you note, this is a weird use-case, and to me it further reinforces the decision to use only the main module's vendor directory in module mode.

(CC @jayconrod in case I've missed anything.)

@bcmills bcmills closed this Apr 30, 2019
@bcmills bcmills removed the modules label Apr 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.