Is there a way to detect following data race code using golangci-lint or other linter??

[raeperd]

Hi big fan of golangci-lint here! thanks a lot for saving me tons of times.

I have question about some hard to find data race error on code.
source is here

package main

import (
        "fmt"
        "time"
)

type RPC struct {
        result int
        done   chan struct{}
}

func (rpc *RPC) compute() {
        time.Sleep(time.Second) // strenuous computation intensifies
        rpc.result = 42
        close(rpc.done)
}

func (RPC) version() int {
        return 1 // never going to need to change this
}

func main() {
        rpc := &RPC{done: make(chan struct{})}

        go rpc.compute()         // kick off computation in the background
        version := rpc.version() // grab some other information while we're waiting
        <-rpc.done               // wait for computation to finish
        result := rpc.result

        fmt.Printf("RPC computation complete, result: %d, version: %d\n", result, version)
}

By fixing func (RPC) version() to func (RPC*) version solves data race which is... very hard to noticed by human reader.
It would be great to catch this by linters

I tried to enable all linters in golangci-lint and many possible linters rules but none of linter catches this data race code.
Am I missing something? or is there any linter that can catch?
Thanks for reading

[ldez]

Hello,

I'm not sure with a static analysis, it is possible to detect this race condition but it can be possible to detect receiver "inconsistency".

[raeperd]

Thanks for reply. is there any linter to check this inconsistency rule? I couldn't find any even outside of golangci-lint supported linters

[ldez]

Some IDEs handle this rule, but I think there is no existing linter on this topic.

[raeperd]

Thanks for reply
I did extra research, I found another reference about this type of err

From Go Wiki: Go Code Review Comments

Don’t mix receiver types. Choose either pointers or struct types for all available methods.
Finally, when in doubt, use a pointer receiver.

Maybe I might try to build new linter to handle this kind of error..

[raeperd]

WIP in https://github.com/raeperd/recvcheck

[raeperd]

Thank you for your apology.
I appreciate your honesty and understand that miscommunication can happen.
Will watch your PR and think about if there are any parts that I can contribute or improve.

[ldez]

I have an idea if you want: an improvement of "recv" can be to detect the usage of sync.Mutex as a struct field and in this specific context forces the usage of a pointer receiver.

I will not work on it, so feel free to do a PR on https://github.com/ldez/recv if you want.

[raeperd]

Thanks I'll try it tomorrow

[ldez]

We will change the plan: I will close my PR and we will use your linter.

But you will need to change your linter to do the same thing as mine: the report must be on the structure (not on the method) and no recommendation of a pointer receiver by default.

[raeperd]

@ldez
Got it. I'll refer to your code to revise it and put you in the reviewer