Description
When I uncommented the Example-executing code in #380, I ran into the following bug, which I have now condensed into a minimal reproduction case. It may be that I'm running into GopherJS's limitation that the main Go routine can't block, but even in that case, some more informative and consistent error reporting would be nice.
Here's the code:
package main
import "fmt"
func main() {
foo()
}
func foo() {
outC := make(chan string)
go func() {
outC <- ""
}()
defer func() {
_ = <-outC
}()
fmt.Printf("Some output. Without this, GopherJS hangs.\n")
return
}
Go:
Some output. Without this, GopherJS hangs
GopherJS:
gopherjs: Source maps disabled. Use Node.js 4.x with source-map-support module for nice stack traces.
Some output. Without this, GopherJS hangs
/home/jonhall/go/src/github.com/flimzy/extest/extest.go.328785025:1473
throw err;
^
TypeError: _r.$blk is not a function
at Object.$packages.main.foo [as $blk] (/home/jonhall/go/src/github.com/flimzy/extest/extest.go.328785025:16211:137)
at Object.$packages.main.main [as $blk] (/home/jonhall/go/src/github.com/flimzy/extest/extest.go.328785025:16186:66)
at Object.$packages.main.$init [as $blk] (/home/jonhall/go/src/github.com/flimzy/extest/extest.go.328785025:16223:68)
at fun (/home/jonhall/go/src/github.com/flimzy/extest/extest.go.328785025:1465:37)
at $goroutine (/home/jonhall/go/src/github.com/flimzy/extest/extest.go.328785025:1463:19)
at $runScheduled [as _onTimeout] (/home/jonhall/go/src/github.com/flimzy/extest/extest.go.328785025:1501:7)
at Timer.listOnTimeout (timers.js:92:15)
Note in particular that in the deferred function, err := recover() happens before the blocking code _ = <-outC, which leads to the appearance that the error is not related to blocking code. However, if I remove the blocking operation, by commenting out _ = <-outC, the code executes successfully in GopherJS as well.
Also, if I comment out the only fmt.Printf line (leaving _ = <-outC in place), the execution simply hangs, rather than generating an error.