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/go2go: receiver parameter inference for embedded methods fails (not implemented) #39901

Closed
lavalamp opened this issue Jun 28, 2020 · 6 comments
Closed
Assignees
Milestone

Comments

@lavalamp
Copy link

@lavalamp lavalamp commented Jun 28, 2020

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
Copy link
Author

@lavalamp lavalamp commented Jun 28, 2020

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
Copy link
Author

@lavalamp lavalamp commented Jun 28, 2020

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()
}
@ianlancetaylor ianlancetaylor added this to the Unreleased milestone Jun 28, 2020
@griesemer griesemer changed the title cmd/go2go: More embedding that doesn't work cmd/go2go: receiver parameter inference for embedded methods fails (not implemented) Jun 30, 2020
@griesemer
Copy link
Contributor

@griesemer griesemer commented Jun 30, 2020

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
Copy link
Contributor

@griesemer griesemer commented Jun 30, 2020

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
Copy link
Author

@lavalamp lavalamp commented Jun 30, 2020

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
Copy link
Contributor

@griesemer griesemer commented Jun 30, 2020

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.

@griesemer griesemer closed this Jun 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.