code review 4442071: gc: correct handling of unexported method names in embe...

gc: correct handling of unexported method names in embedded interfaces
go/types: update for export data format change
reflect: require package qualifiers to match during interface check
runtime: require package qualifiers to match during interface check
test: fixed bug324, adapt to be silent

Fixes issue 1550.
Issue 1536 remains open.

[rsc, 2011-04-20 22:45:02]

Hello gri, ken2, r (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[r, 2011-04-20 22:50:57]

LGTM for reflect and runtime

[gri, 2011-04-20 23:06:48]

LGTM

for gcimporter changes and tests

http://codereview.appspot.com/4442071/diff/4001/test/fixedbugs/bug324.dir/mai...
File test/fixedbugs/bug324.dir/main.go (right):

http://codereview.appspot.com/4442071/diff/4001/test/fixedbugs/bug324.dir/mai...
test/fixedbugs/bug324.dir/main.go:46: x = px.(Exported)
couldn't this be a compile-time failure?

[rsc, 2011-04-20 23:25:53]

> test/fixedbugs/bug324.dir/main.go:46: x = px.(Exported)
> couldn't this be a compile-time failure?

it could but only by the logic "anything implementing
px must have a method named 'private from package p',
so it cannot also have a method named 'private from package main' ".

other similar logic that we don't implement is, in this case:

package main

type I interface { M() }
type J interface { M(int) }

func main() {
	var i I
	j := i.(J)
	_ = j
}

"anything implementing I must have a method M()
which means it cannot have a method M(int), because
it can only have one method named M."

both are a separate issue from the one i'm fixing.

in general i think we've taken a fairly lenient attitude
toward x.(I) for interface I - it's the programmer asking for
a run-time check, so the programmer gets a run-time check.

russ

[gri, 2011-04-21 00:03:02]

LGTM.
ok. seems perfectly reasonable.
- gri

On Wed, Apr 20, 2011 at 4:25 PM, Russ Cox <rsc@golang.org> wrote:
>> test/fixedbugs/bug324.dir/main.go:46: x = px.(Exported)
>> couldn't this be a compile-time failure?
>
> it could but only by the logic "anything implementing
> px must have a method named 'private from package p',
> so it cannot also have a method named 'private from package main' ".
>
> other similar logic that we don't implement is, in this case:
>
> package main
>
> type I interface { M() }
> type J interface { M(int) }
>
> func main() {
>        var i I
>        j := i.(J)
>        _ = j
> }
>
> "anything implementing I must have a method M()
> which means it cannot have a method M(int), because
> it can only have one method named M."
>
> both are a separate issue from the one i'm fixing.
>
> in general i think we've taken a fairly lenient attitude
> toward x.(I) for interface I - it's the programmer asking for
> a run-time check, so the programmer gets a run-time check.
>
> russ
>

[rsc, 2011-04-21 12:14:57]

*** Submitted as http://code.google.com/p/go/source/detail?r=ca71e7735593 ***

gc: correct handling of unexported method names in embedded interfaces
go/types: update for export data format change
reflect: require package qualifiers to match during interface check
runtime: require package qualifiers to match during interface check
test: fixed bug324, adapt to be silent

Fixes issue 1550.
Issue 1536 remains open.

R=gri, ken2, r
CC=golang-dev
http://codereview.appspot.com/4442071