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
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@tom-hadlaw-hs
Copy link

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 katiehockman added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 30, 2019
@katiehockman
Copy link
Contributor

/cc @bcmills

@bcmills
Copy link
Contributor

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 as completed Apr 30, 2019
@bcmills bcmills removed the modules label Apr 30, 2019
@golang golang locked and limited conversation to collaborators Apr 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge 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

4 participants