go version)?go version go1.8rc2 darwin/amd64
go env)?GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
https://play.golang.org/p/hebuAYQ6eo
Take the program above, that on go 1.7.4 prints out "The right thing.", and run that with a go compiler of version 1.8rc2. You now find that it prints out "The wrong thing." Additionally interesting, if you comment out line 15, the second call to "panicWhen", then the first call behaves correctly.
I expect the program to panic with "The right thing."
The first call to panicWhen gets the argument cond as false, and panics with "The wrong thing."
Confirmed. This is a bug that appeared in 1.8.
/cc @randall77 @mdempsky @griesemer
The bug is in nilcheck phase, where there is a NilCheck Op in the same block as IsNonNil and happened to be stored before it (since values are not stored in order, until the scheduling phase). But logically NilCheck is after the IsNonNil.
I think we should explicitly check the memory to set/clear nonNilValues.
If it helps, git-bisect shows the offending commit as: 3134ab3c2d58d2c9f93471c85405cb26ccdf0f4d, which is a trivial change of only a thousand or so lines ;)
@dsnet, yes, that is it. Before that commit, NilCheck always introduces a new block (BlockCheck) which enforces the value ordering. After that, it no longer introduces new block, so NilCheck could affect values in the same block but logically before it.
Not sure where gopherbot is, there's a CL at http://golang.org/cl/35495
Also proposed CLs at https://golang.org/cl/35496 (Cherry's) and https://golang.org/cl/35485 (mine).
CL https://golang.org/cl/35496 mentions this issue.
Most helpful comment
If it helps, git-bisect shows the offending commit as: 3134ab3c2d58d2c9f93471c85405cb26ccdf0f4d, which is a trivial change of only a thousand or so lines ;)