cmd/go2go: receiver parameter inference for embedded methods fails (not implemented)

[lavalamp]

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

dev.go2go branch @ 10ea225e28a9ca3a5b18dd4609bcc41a7c26e8dd

Does this issue reproduce with the latest release?

Yes

What did you do?

I ran this file:

package main

type base(type T) struct{}
func (b base(T)) A() {}

type foo struct {
        base (*foo)
}

type bar struct{
        base(foo)
}

func main() {
        x := &foo{}
        x.A()
        y := bar{}
        y.A()
}

What did you expect to see?

I expected at least one of x or y to have an A() method from embedding.

What did you see instead?

type checking failed for main
/tmp/go2go-run938616244/embedding2.go2:16:4: x.A undefined (type *foo has no field or method A)
/tmp/go2go-run938616244/embedding2.go2:18:4: y.A undefined (type bar has no field or method A)

(thanks for the quick fix for #39881!)

[lavalamp]

I'm not sure if it's the same issue or not, but the below works if you name the member of foo, otherwise complains about a type cycle

package main

type base(type T) struct{
        pointer *T
}

type foo struct {
        base (foo)
}

func main() {
}

type checking failed for main
/tmp/go2go-run521384141/embedding3.go2:7:6: illegal cycle in declaration of foo
/tmp/go2go-run521384141/embedding3.go2:7:6:     foo refers to
/tmp/go2go-run521384141/embedding3.go2:7:6:     foo

In this example changing to (base(foo)) seems to work (no help from the error message).

However, making that change to the example in the OP causes a stack trace.

[lavalamp]

Here's the minimal crashing sample:

package main

type base(type T) struct{}
func (b base(T)) A() {}

type foo struct {
        (base (foo))
}

func main() {
        x := foo{}
        x.A()
}

[griesemer]

Thanks for this report. The initial error is known (as in "not fully implemented"). The 2nd issue you are mentioning is unrelated. I filed a separate issue #39938 for that.

[griesemer]

Quick follow-up: The 2nd error you are mentioning is expected: Note that in

type foo struct {
        base (foo)
}

the base(foo) is not parenthesized and thus is interpreted as field base of parenthesized type foo which is of course an error because that means the type foo contains itself and thus would lead to infinite expansion.

On the other hand, once you write, for instance

type foo struct {
        f base(foo)
}

you have a field f of type base(foo) which in this case would be permitted. The problem is that we don't get an error when the base.pointer type is changed from *T to T which would also lead to infinite expansion of foo. See #39938.

[lavalamp]

That makes sense, and I think highlights that using () for this many different things is confusing. It seems like half the generics complaints on the mailing list are about this and I'm starting to agree with the criticism :)

[griesemer]

The various sub-issues have been addressed here. The remaining issue (internal error: receiver type parameter inference failed) is a know bug. Closing this as a duplicate of #39758.