The error on L15 is the correct one.

For eg., something like this is valid Go code.

func main() {
	send := make(chan int)
	go func() {
		// True error on line below. Missing value to send
		send <- 
	10 }()
	fmt.Println(<-send)
}

Leaving upto @griesemer and @mdempsky to see if something can be done about L12.

As @agnivade points out, Go's syntax allows newlines between the <- token and the following expression. That's why we currently report at line 15 that we found a } when we expected an expression: we're still looking for an expression. So I think the proposed "unexpected \n" error message is inappropriate.

But we could maybe recognize cases like this somehow and emit a "missing expression" error instead?

As for the error on line 12, off hand I don't know what's causing that. I'm guessing error recovery gone wrong. @griesemer might have ideas on how to address that, and whether it's worthwhile.

I agree that the error on line 15 is correct. The error on line 12 is because the parser skips the closing '}' and then gets out of sync. Fix forthcoming.

The correct error message already says "expecting expression" which is close to "missing expression" (but a bit less definitive). I filed #33415 as a reminder.

@mdempsky / @griesemer what if the parser were to recognize it checked the next line for an expression and did not find one and then decrement the line number in the error message?

Again, for any of this let me know if you'd like a PR, I've been interested in contributing

@MaerF0x0 It's not so simple in general. For one, there could be arbitrary many empty lines before the closing '}'. There could be comments, also arbitrary many. One could record the last valid token perhaps, and then use the position immediately after that token. But if that token is followed by comments than it's weird to get an error message before that comment. We provide the error when we see the first token that is unexpected. That is simple, sensible, consistent, and expected by many tests. A single slightly unfortunate case is not a good reason to change that. Generally, good error reporting by a recursive-descent parser is more of an art than a science. The fix here is simple I believe - I just need to test it a bit more before sending it out.

Change https://golang.org/cl/188502 mentions this issue: cmd/compile/internal/syntax: better error recovery after missing expression