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

runtime: display fully-qualified types when strings are equal in unequal type panic #11634

Open
Frumious opened this Issue Jul 9, 2015 · 3 comments

Comments

Projects
None yet
4 participants
@Frumious

Frumious commented Jul 9, 2015

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

go version devel +bd45bce Wed Jul 8 01:20:02 2015 +0000 linux/amd64

What operating system and processor architecture are you using?

Ubuntu 15.04, amd64

What did you do?

Created a test case to see what would happen when vendoring the same package twice in two different repositories.

go15vendortest has a copy of vendortedthing under the vendor directory
it also pulls in go15vendortest2 which has its own copy of vendoredthing under the vendor directory

export GO15VENDOREXPERIMENT=1
go get github.com/frumious/go15vendortest
go15vendortest

What did you expect to see?

A type exception with a way to tell which type came from which package.

What did you see instead?

panic: interface conversion: interface is vendoredthing.Data, not vendoredthing.Data

I know why this is happening because I created it on purpose, but there seems to be no way to display where these types came from.

@ianlancetaylor ianlancetaylor changed the title from Type name display ambiguity when using vendoring - " interface is vendoredthing.Data, not vendoredthing.Data" to cmd/compile: Type name display ambiguity when using vendoring - " interface is vendoredthing.Data, not vendoredthing.Data" Jul 9, 2015

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Jul 9, 2015

Note that I don't think this has anything to do with vendoring as such. It's a problem with the compiler error message.

@ianlancetaylor ianlancetaylor added this to the Go1.6 milestone Jul 9, 2015

@rsc

This comment has been minimized.

Contributor

rsc commented Nov 4, 2015

This is unrelated to vendoring. This happens if you just have two packages x/y and z/y that define different y.T's.

Here is a shorter example:

package main

import (
    t1 "html/template"
    t2 "text/template"
)

func main() {
    var x interface{}
    x = new(t1.Template)
    println(x.(*t2.Template))
}

$ go run x.go
panic: interface conversion: interface {} is *template.Template, not *template.Template

goroutine 1 [running]:
main.main()
    /tmp/x.go:11 +0x97
exit status 2

99% of the time you do want to see the shortened name. And in general reconstructing an expanded name may be difficult. For example the type involved might actually be func(chan *template.Template). Rebuilding that entire string with the expanded package name, from within the runtime, is non-trivial.

That's not to say we shouldn't do it, just that it's actually hard.

@rsc rsc changed the title from cmd/compile: Type name display ambiguity when using vendoring - " interface is vendoredthing.Data, not vendoredthing.Data" to runtime: display fully-qualified types when strings are equal in unequal type panic Nov 4, 2015

@rsc rsc modified the milestones: Unplanned, Go1.6 Nov 4, 2015

@mdempsky

This comment has been minimized.

Member

mdempsky commented Jan 5, 2018

In #17283, we had discussed changing the error to something like:

interface is foo.Bar (x/y/z), not foo.Baz (a/b/c)

but we were only considering the case of bare declared types. This solution doesn't extend to compound type literals though that might contain multiple declared types.

It's also not clear that it's always appropriate for single declared types. For example, expanding func(chan *template.Template) as func(chan *template.Template) (text/template) might be confusing because the (text/template) almost looks like a return parameter signature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment