On Tuesday, December 29, 2020 at 1:21:04 PM UTC-5 k.alex...@gmail.com wrote:
> I'd like to solicit some input from the community regarding a decision > that could reduce the effort required in crowdsourcing. > > After thinking carefully about the loopclosure vet check > <https://github.com/golang/tools/blob/master/go/analysis/passes/loopclosure/loopclosure.go>, > > it seems to me that any time it reports an issue, there actually is an > issue. That has also been the case for everything I've seen GitHub Vet > report from loopclosure thus far. > > What loopclosure does is find instances where a range loop variable is > used inside a goroutine or defer statement. My understanding is that, in > every case, this raises the potential for a race-condition between updating > the range loop variable and reading from it within the body of the > goroutine. So unless I'm missing something, it seems to me that there is > not any need for a human to double-check loopclosure results. > Technically, I believe a range loop variable can be used in a goroutine safely. A very contrived example: https://play.golang.org/p/jgZbGg_XP6S . In practice I can not see much use for this kind of pattern, but it does exist. > > So my plan -- unless someone comes up with something I have missed -- is > to omit loopclosure findings from the crowdsourcing effort. Once this > change is made, loopclosure findings will be kept on disk, but not uploaded > to GitHub for crowdsourcing. > > It's worth mentioning that there are issues which loopclosure misses which > VetBot is able to find, and the community's effort will still be needed to > help sift through false-positives once the project has stabilized. > > > On Sun, Dec 20, 2020 at 12:08 PM K. Alex Mills <k.alex...@gmail.com> > wrote: > >> Hello Gophers! >> >> During a Q&A session at this year's GopherCon, some members of the Go >> language team indicated a willingness to modify the behavior of range >> loops <https://github.com/golang/go/issues/20733> *if* we can be >> reasonably certain that the change will not cause incorrect behavior in >> current programs. To make that determination, a large collection of >> real-world go programs would need to be vetted. If we can find that, in >> every case, modifying the compiler behavior does not lead to an undesirable >> outcome, we will have strong evidence that the change may only have a small >> impact. >> >> I've been working on a project to gather and crowdsource data for that >> sort of analysis. It has reached a point where I think that it's time to >> share it with the Go community. >> >> The GitHub Vet Project <https://github.com/github-vet> performs static >> analysis on public Go repositories hosted on GitHub in order to better >> understand the impact of this proposed language change >> <https://github.com/golang/go/issues/20733>. It consists of two bots. >> VetBot crawls GitHub to snippets of code it thinks could be interesting, it >> reports it as an issue in a separate repository >> <https://github.com/github-vet/rangeloop-pointer-findings>, for humans >> to analyze via crowdsourcing. TrackBot >> <https://github.com/github-vet/bots/tree/main/cmd/track-bot> manages the >> crowdsourcing workflow. >> >> At this point, all of the features I think are necessary for the >> project's success have been implemented. But I am only one Gopher, and so I >> would like to a) make the community aware of the project and b) ask the >> community to help review it in three ways: >> >> 1) Test out TrackBot and the project instructions by actually >> crowdsourcing through the issues found so far >> <https://github.com/github-vet/rangeloop-pointer-findings>. >> 2) Review the output >> <https://github.com/github-vet/rangeloop-pointer-findings/issues> and >> raise concern if anything that I claim ought to be excluded >> <https://github.com/github-vet/bots/tree/main/cmd/vet-bot#2-run-static-analysis> >> >> is somehow making it through. >> 3) Static analysis experts: review the analyzers >> <https://github.com/github-vet/bots/tree/main/cmd/vet-bot> and >> ruthlessly question anything that could lead to a false negative. I don't >> think anything exists, but one pair of eyes is often wrong, and there are >> many folks on this list with (much) more expertise than me. >> >> One final thing. The crowd-sourcing workflow I've designed relies on the >> opinion of experts to help estimate the reliability of the community >> assessment. In order for that to work, I need the help of some Go experts >> who are willing to commit some time to reviewing the findings. If you'd >> like to participate in this way, first, read the TrackBot documentation >> <https://github.com/github-vet/bots/tree/main/cmd/track-bot> to >> understand what being an expert entails. If you're still interested, email >> me with the subject line 'GitHub Vet Expert' and include your GitHub >> username and a brief outline of your experience with Go. >> >> It's my hope that this project can provide some data that can help to >> move Go forward. To that end, I'm also interested in any and all feedback >> and suggestions. Contributions are also welcome >> <https://github.com/github-vet/bots/issues>. >> >> Thanks for reading, >> >> K. Alex Mills, Ph.D >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/72281283-6824-4396-abd2-0dcb2b08ad62n%40googlegroups.com.
