What steps will reproduce the problem?
- use gofmt (for instance) to parse the program below
What is the expected output? What do you see instead?
- the first error message is confusing; the actual error is the 2nd error
- should try to handle cases like this better
Test case:
package main
func f() {
var m Mutex
c := MakeCond(&m)
percent := 0
const step = 10
for i := 0; i < 5; i++ {
go func() { // #### FIRST ERROR REPORTED HERE
for {
// Emulates some useful work.
time.Sleep(1e8)
m.Lock()
defer // #### ACTUAL PROBLEM IS HERE
if percent == 100 {
m.Unlock()
break
}
percent++
if percent % step == 0 {
//c.Signal()
}
m.Unlock()
}
}()
}
for {
m.Lock()
if percent == 0 || percent % step != 0 {
c.Wait()
}
fmt.Print(",")
if percent == 100 {
m.Unlock()
break
}
m.Unlock()
}
}
gofmt -l example_test.go
example_test.go:9:6: expected function/method call
example_test.go:15:5: expected function/method call
example_test.go:25:4: expected ';', found '('
example_test.go:27:2: expected declaration, found 'for'
example_test.go:28:3: expected declaration, found 'IDENT' m
example_test.go:29:3: expected declaration, found 'if'
example_test.go:30:4: expected declaration, found 'IDENT' c
example_test.go:31:3: expected declaration, found '}'
example_test.go:32:3: expected declaration, found 'IDENT' fmt
example_test.go:33:3: expected declaration, found 'if'
example_test.go:34:4: expected declaration, found 'IDENT' m
example_test.go:35:4: expected declaration, found 'break'
example_test.go:36:3: expected declaration, found '}'
example_test.go:37:3: expected declaration, found 'IDENT' m
example_test.go:38:2: expected declaration, found '}'
example_test.go:39:1: expected declaration, found '}'
The text was updated successfully, but these errors were encountered:
I'm not sure this is an ordering problem so much as
just getting too confused by a lone defer keyword.
If the parser realized that it should give up on the defer
and start a new statement at the if token, then I think you'd
get just the one error.
Agreed. I was not implying that this is an ordering problem. What happens is that the
parse of the function call for the go statement returns a function literal instead of a
call, which then causes the spurious first error message (first only because the
messages are sorted by position). The parser should either synchronize better when
encountering the flawed defer; and/or return a BadExpr for the function call which could
be used as a signal to not issue another error.
The text was updated successfully, but these errors were encountered: