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

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
Assignees
Milestone

Comments

@griesemer
Copy link
Contributor

@griesemer griesemer commented Oct 3, 2018

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 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 beoran commented Oct 4, 2018

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.

Loading

@go101
Copy link

@go101 go101 commented Oct 4, 2018

It looks gc think the code is valid.

Loading

@griesemer
Copy link
Contributor Author

@griesemer griesemer commented Oct 4, 2018

@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.

Loading

@griesemer
Copy link
Contributor Author

@griesemer griesemer commented Oct 22, 2018

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

Loading

@griesemer griesemer closed this Oct 22, 2018
@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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants