The race in go/packages reported in #31749 was fixed at tip, but is still an issue for Go 1.13 and earlier, and is showing up in the go/packages race failure reported in #36605.
That race is caused by a race in go/types which in turn is caused by go/constant.Float64Val() calling Rat.Float64 in math/big, which has a race reported in #34919 , and subsequently fixed in tip.
Fixing this race in go/types on Go 1.13 and earlier requires backporting CL 201205 to those releases. (Alternatively, we could fix the race by adding a workaround in go/constant or go/types, but that would be more work). I'm not sure if fixing this is worth a backport but we might as well have the discussion. If we decide not to go with the backport, we'll have to accept a race in go/packages and disable some of its tests in race mode in Go 1.13 and earlier.
The text was updated successfully, but these errors were encountered:
I'm not sure if fixing this is worth a backport but we might as well have the discussion.
A data race in go/packages seems likely to translate to flakiness in gopls and similar tools. If we will support gopls on Go versions older than 1.14, then we should backport the fix for the data race.
gopls (as well as the rest of the tools repo) is supported for 2 Go versions behind the current release, so once Go 1.14 is out, we will still support 1.13 and 1.12. I'd support backporting a fix, though I'm not sure how much this has affected gopls.
This data race in go/types was resolved in Go 1.14 via a fix to the math/big package in CL 201205. I'll set the appropriate milestone and close this issue, because there's nothing actionable left here to do.
This fix is being considered for backporting to Go 1.13.x in issue #36689.