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: confusing and inconsistent error messages for syntactically incorrect method expressions #8605

Open
griesemer opened this Issue Aug 28, 2014 · 5 comments

Comments

Projects
None yet
4 participants
@griesemer
Contributor

griesemer commented Aug 28, 2014

The following program:

http://play.golang.org/p/2qX3CIh_Cx

compiles with a confusing error:

main.main: call to external function go.(*struct { main.T }).main.m
main.main: undefined: go.(*struct { main.T }).main.m

Per the spec ( http://tip.golang.org/ref/spec#Method_expressions ), method expressions
must have a (possibly parenthesized) named (or pointer to named) type. The error message
is (at the very least) confusing.

For reference, gccgo produces for this case:

x.go:8:14: error: method expression requires named type or pointer to named type
  (*struct{T}).m(nil)

That said, the following (equally syntactically incorrect) program compiles and runs w/o
problems using gc:

http://play.golang.org/p/qpAtL6sEVW

For reference, gccgo produces for this case:

x.go:8:15: error: method expression requires named type or pointer to named type
  (struct{ T }).m(struct{ T }{42})

go/types (arguably incorrectly) accepts both programs w/o complaints.

I see 2 possible solutions:

1) Let's fix gc and go/types to make it spec compliant.

2) Relax the spec and adjust gccgo and the one case in cmd/gc.

I am in favor of 2) for the following reasons:

- A method expression T.m is essentially a syntactic construct: It can always be
rewritten to m' where m is roughly defined as:

func m'(x T, args m_params) {
   x.m(args)
}

If m exists for T, m' can always be written independent of the syntactic form of T, for
instance:

http://play.golang.org/p/kflAOxp2Gr

for our first example.

- It already appears to work in 1/2 of the cases for cmd/gc.
- It's more general and simplifies the spec.
- It's backward compatible.
- It doesn't require a 2nd syntax check (of technically a selector expression) after the
type checker has determined that x in x.m is a type (rather than a value). This ought to
simplify the implementation slightly.
@paranoiacblack

This comment has been minimized.

Contributor

paranoiacblack commented Aug 28, 2014

Comment 1:

Making these cases pass in GCCGo is pretty trivial as well:
https://golang.org/cl/139790043/.  Letting this case pass also allows GCCGo to
give out a more consistent error message in situations like issue4458.go.
@paranoiacblack

This comment has been minimized.

Contributor

paranoiacblack commented Nov 10, 2014

Comment 2:

Status changed to Started.

@paranoiacblack

This comment has been minimized.

Contributor

paranoiacblack commented Nov 10, 2014

Comment 3:

Owner changed to @paranoiacblack.

@paranoiacblack

This comment has been minimized.

Contributor

paranoiacblack commented Nov 11, 2014

Comment 4:

Solution for gc started here: https://golang.org/cl/166600043.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@rsc rsc changed the title from cmd/gc: confusing and inconsistent error messages for syntactically incorrect method expressions to cmd/compile: confusing and inconsistent error messages for syntactically incorrect method expressions Jun 8, 2015

@griesemer

This comment has been minimized.

Contributor

griesemer commented May 18, 2016

See also #9060 .

@bradfitz bradfitz removed the Started label Jan 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment