cmd/compile: incorrect name in error message

[dsnet]

Consider the following (invalid) Go code:

type x struct{}

func (x) Read()

The Go1.9 compiler complains with:

./main.go:7:6: missing function body for "_"

On Go1.8, it complained with:

./main.go:7: missing function body for "x.Read"

Edit: added type x struct{}

[odeke-em]

@dsnet it seems like the new error is a premature report, but on tip it currently reports undefined: x but after the first seemingly misleading message. Please take a look at the version comparisons below:

Go1.8

$ go version && go run main.go 
go version go1.8.3 darwin/amd64
# command-line-arguments
./main.go:3: undefined: x

Go1.9+

$ go version && go run main.go 
go version devel +f74b52c Fri Sep 1 00:42:21 2017 +0000 darwin/amd64
# command-line-arguments
./main.go:3:6: missing function body for "_"
./main.go:3:7: undefined: x

I guess we should report 3:7 before 3:6 or suppress the content of 3:6.
/cc @mdempsky @griesemer

[mdempsky]

Interesting. I'm inclined to just truncate the for %q part of the error message. With position information, I don't think it's necessary to include the name.

We can continue including the name, but it's actually complicated somewhat because of type aliases (which is why this changed in 1.9).

[gopherbot]

Change https://golang.org/cl/61311 mentions this issue: cmd/compile: simplify "missing function body" error message

[mdempsky]

For posterity, the two changes that happened in 1.9 that are relevant to this issue:

1. Methods have names like "T.m". We used to compute these immediately during parsing; but because of type aliases, we have to compute them during type checking instead. E.g., "func (T) m()" might end up needing the name "(*U).m" if we later find "type T = *U".
2. We used to check for missing bodies during code generation, but we're trying to move all user errors into the compiler frontend. The parser was the natural place to relocate this check to.

If we decide we want to restore the function name, moving the error to type checking would probably work too.

[dsnet]

I think dropping the function name is sufficient since the line should be sufficient. Usually there isn't more than one function declaration on a single line.

[odeke-em]

Reopening for cherry picking to the Go1.9.1 branch.

[mdempsky]

@dsnet Yeah, and even if there were multiple functions on a single line, we now have column information. We also don't include function name in any other (standard) error messages. (We do include it in some optional diagnostics used for debugging the compiler itself.)

[ianlancetaylor]

This is a bad-error-on-invalid. I'm not sure this qualifies for a 1.9 backport.