go/types, math/big: data race in go/types due to math/big.Rat accessors unsafe for concurrent use [1.13 backport]

[gopherbot]

@matloob requested issue #36687 to be considered for backport to the next 1.13 minor release.

@gopherbot backport please 1.12 1.13

[toothrot]

@matloob Could you please include a short rationale for the backport, in accordance with https://golang.org/wiki/MinorReleases?

[matloob]

Including the rationale from the original change. go/types and go/packages (through the go/types dependency) will have a race in 1.13 without this fix.

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.

[dmitshur]

There is a new comment at #36605 (comment) that is relevant to this backport issue. /cc @matloob

[dmitshur]

We've discussed this cherry pick candidate in a release meeting.

To recap the latest status of this candidate, we know this is a serious problem and we have been investigating to see if there is a workaround. Based on various discussions, it doesn't seem there is a good workaround available, and we should only consider backporting math/big CL(s) to Go 1.13 that are necessary to fix #36687.

I understand the primary math/big CL that needs to be backported is:

• CL 201205 - math/big: make Rat accessors safe for concurrent use

@matloob has said earlier in #36605 (comment):

I tried cherrypicking the fix CL (golang.org/cl/201205) and running the tests in race mode and it seems to fix the issue.

So CL 201205 should be sufficient to resolve issue #36687.

However, the commit message of that CL says:

Fixes #34919.
Reopens #33792.

Issue #33792 took two more CLs to resolve:

• CL 202997 - math/big: normalize unitialized denominators ASAP - "Updates math/big: Rat.Denom has side effects #33792."
• CL 203059 - math/big: make Rat.Denom side-effect free - "Fixes math/big: Rat.Denom has side effects #33792. Updates Rat.Denom() and Num() work differently, Denom appears to return a copy and Num a pointer #3521."

To make a decision on whether to make this backport, we need to determine whether it is safe to backport just CL 201205, or if that requires CLs 202997 and 203059 to be backported as well and if all 3 CLs are safe to backport.

@griesemer Do you know if backporting CL 201205 to 1.13 by itself is safe, or is it unsafe to do that without also backporting CL 202997 and CL 203059?

[andybons]

ping @griesemer