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/compile, go/types: erroneously accepts method expressions with anonymous receiver type #15721

Closed
mdempsky opened this issue May 17, 2016 · 1 comment
Milestone

Comments

@mdempsky
Copy link
Member

@mdempsky mdempsky commented May 17, 2016

The Go spec's grammar restricts method expressions to using either a named type or pointer to a named type:

MethodExpr    = ReceiverType "." MethodName .
ReceiverType  = TypeName | "(" "*" TypeName ")" | "(" ReceiverType ")" .

cmd/compile erroneously accepts this Go source:

package p
var _ = struct{ error }.Error

go/types erroneously accepts it too.

gccgo correctly rejects with the error message "method expression requires named type or pointer to named type"

/cc @griesemer @ianlancetaylor

@mdempsky mdempsky added this to the Go1.8 milestone May 17, 2016
mdempsky added a commit to mdempsky/gocode that referenced this issue May 18, 2016
An extraction and rewrite of the logic from package suggest. In
particular, this code now handles many more subtle cases correctly.

Writing it also revealed multiple inconsistencies in the Go spec
and/or standard implementations: golang/go#15708, golang/go#15721,
golang/go#15722.
@griesemer
Copy link
Contributor

@griesemer griesemer commented May 18, 2016

This is so closely related to #9060 that I'm going to close it as duplicate. I believe we should just accept this code and adjust the spec.

Loading

@griesemer griesemer closed this May 18, 2016
@golang golang locked and limited conversation to collaborators May 18, 2017
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
3 participants