checklocks: always allow calls to methods of atomic wrappers

[jkowalski]

This allows the use of wrappers such as atomic.Int32 introduced in Go 1.19 without triggering the unexpected call to atomic function.

I tried running recent checklocks on github.com/kopia/kopia and got a ton of such errors, which I don't think should be reported since the wrappers are there to ensure safety of atomic operations. This PR fixes the issue.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[jkowalski]

@amscanne would you mind taking a look at this change?

[jkowalski]

any interest in that fix?

[jkowalski]

@avagin gentle ping, anything I can do to help this get merged? I would really like to re-enable checklocks on Kopia

[avagin]

Why is it safe to call methods of atomic wrappers in this case?

A few lines bellow, we check that it is not one of Load functions. Why do we want skip Load methods?

 		if !strings.HasPrefix(fn.Name(), "Load") && ar == readOnlyAtomic {

Could you add tests in tools/checklocks/test/? I think it will help to understand the problem.

[jkowalski]

atomic.Int32,Int64,etc. are opaque wrappers around int32,int64,... that no longer require calls to package-level functions, such as atomic.LoadNNN(). Instead they handle such things internally and expose type-safe methods.

Current logic will incorrectly flag access such as:

var x atomic.Int32

x.Add(1)
x.Load()
x.Store(3)

My PR simply adds a heuristic which threats all calls to methods (functions with a receiver) in the atomic package as safe.
Let me try to add a test.

[avagin]

atomic.Int32,Int64,etc. are opaque wrappers around int32,int64,... that no longer require calls to package-level functions, such as atomic.LoadNNN(). Instead they handle such things internally and expose type-safe methods.

I know what atomic.Int32,Int64,etc mean... I was talking about this check:
https://cs.opensource.google/gvisor/gvisor/+/master:tools/checklocks/analysis.go;l=149?q=tools%2Fchecklocks%2Fanalysis.go&ss=gvisor%2Fgvisor
I forgot that these atomic wrappers don't allow to do non-atomic operations or what we call here as mixed access. In gVisor, we have our wrappers that have RaceLoad/RaceStore methods:
https://cs.opensource.google/gvisor/gvisor/+/master:pkg/atomicbitops/aligned_64bit.go;l=80;drc=755c1f242cd410b7311f18807e9cd6d8a116ed09

[avagin]

Overall, changes look good to me. Please, merge the second commit into the first one or write a normal commit message for it.