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

Jump to bottom

go/types: better error message for invalid method receiver #27996

Closed
griesemer opened this issue Oct 3, 2018 · 4 comments
Closed

go/types: better error message for invalid method receiver #27996

griesemer opened this issue Oct 3, 2018 · 4 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.12

Comments

@griesemer
Copy link
Contributor

For

package p

type T struct{}

type T1 = *T

func (T1) m() {}

func _() {
	(&T{}).m()
}

go/types reports

x.go:10:9: invalid operation: (&(T literal)) (value of type *T) has no field or method m

which is misleading. The reason is that it drops the method m on the floor completely. Instead it should complain about the receiver.

See also issue #27995 .
@griesemer griesemer added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 3, 2018
@griesemer griesemer added this to the Go1.12 milestone Oct 3, 2018
@griesemer griesemer self-assigned this Oct 3, 2018
@griesemer griesemer changed the title go/types: better error message for invalid method received go/types: better error message for invalid method receiver Oct 3, 2018
@beoran
Copy link

beoran commented Oct 4, 2018 •
edited

But when I look in the spec at the definition of aliases I see this:

Alias declarations

An alias declaration binds an identifier to the given type.

AliasDecl = identifier "=" Type .

Within the scope of the identifier, it serves as an alias for the type.

type (
nodeList = []*Node // nodeList and []*Node are identical types
Polar = polar // Polar and polar denote identical types
)

This suggests to me that T1 is identical to *T, and thus a valid method receiver.
I think with the current spec both examples should compile, although I admit using a type alias to hide a pointer is bad style. Otherwise the spec should be clarified on how aliases work together with method definitions.

@go101
Copy link

go101 commented Oct 4, 2018

It looks gc think the code is valid.

@griesemer
Copy link
Contributor Author

@beoran @go101 Please discuss the validity of this at #27995. That's why I opened that one. This issue is just a reminder to follow up on go/types. Thanks.

@griesemer
Copy link
Contributor Author

This was fixed with https://golang.org/cl/143179 which made this kind of declaration valid in the first place. Closing.

@golang golang locked and limited conversation to collaborators Oct 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.12
Development

No branches or pull requests
4 participants
@beoran @griesemer @gopherbot @go101