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

[walidghallab]

Thanks for sharing the example. I have two comments about this:

1. Would you mind to share where is the race condition? You are saying that it is fixed by making Version ptr receiver, but never mentioned where is the race condition is and if it even exists.
2. The existence of this linter is good, but please note there are some cases where this is not recommended. For example "String()" method that implements fmt.Stringer, it is recommended in a lot of places to have it as a value receiver (regardless of what other methods uses) due to usability, otherwise if you implement it as pointer receiver anyone with a value to the struct (and not a pointer) won't have correct formatting, while value receiver works for both value and pointer.

[raeperd]

@walidghallab
Hi sorry i'm late. I was busy on day job

Example code is completely executable, but data race can be found only when u add -race option

$ go build -race -o app - && •/app
WARNING: DATA RACE
Write at 0x00c000094020 by goroutine 6:
    main. (*RPC) . compute ()
        ~/recvcheck/main.go:15 +0x44
    main.main.gowrap1()
        ~/recvcheck/main.go:26 +0x20
        
Previous read at 0x00c000094020 by main goroutine:
    main-main ()
        ~/recvcheck/main. go:27 +0x120
        
Goroutine 6 (running) created at:
    main main ()
        ~/recvcheck/main.go: 26 +0x114
ニニニニニニニニニニニニニニニ
RPC computation complete, result: 42, version: 1
Found 1 data race(s)

About Stringer interface, if you mix receiver type then it also causes data race.
I could say those recommendations are wrong in terms of concurrent safety.
if you do not mix the type (using value type only), then you are fine