Why does go vet's copylocks check flag a value receiver on a struct holding a sync.Mutex?

## The mechanism `sync.Mutex` is not a handle or a reference. It is a small struct with fields holding the lock's state, and Go copies structs by value — on assignment, on passing an argument, on returning, and on calling a method with a value receiver. Copy a struct that contains a mutex and you now have two mutexes, each with its own independent state. Consider: ```go type Counter struct { mu sync.Mutex n int } func (c Counter) Inc() { // value receiver c.mu.Lock() defer c.mu.Unlock() c.n++ } ``` Two separate things are broken here, and a good answer names both: 1. **Exclusion is gone.** Each call to `Inc` receives its own copy of `Counter`, so `c.mu` is a private mutex belonging to that call. Two goroutines calling `Inc` concurrently both acquire their own copies without contention. The lock is decorative. 2. **The mutation is lost.** `c.n++` increments a field of the copy, which is discarded when the method returns. The original counter never changes. And there is a third failure mode when the copy is made at the wrong moment: if a mutex is copied **while it is held**, the copy's state says "locked" and nobody will ever unlock it, so a later `Lock` on the copy blocks forever. That one shows up as a goroutine wedged in `sync.(*Mutex).Lock` in a stack dump, with no obvious owner. ## What copylocks looks for The `copylocks` analyzer, part of the suite shipped with `go vet`, reports any operation that copies a value whose type contains a `sync.Locker` — that is, something with pointer-receiver `Lock`/`Unlock` methods, which covers `sync.Mutex`, `sync.RWMutex`, and by extension `sync.WaitGroup`, `sync.Cond` and structs that embed any of them. The shapes it catches: - a method with a value receiver whose type contains a lock (`Inc passes lock by value: Counter contains sync.Mutex`); - passing such a struct to a function by value, or returning it by value; - assigning one such value to another, including `x := *ptr`; - `for _, c := range counters` — the loop variable is a copy of each element; - appending such a value to a slice, or storing it in a map, both of which copy. The fix in each case is to use `*Counter`: a pointer receiver, pointer parameters, a `[]*Counter`. A pointer copy is just an address, and everyone shares the one lock. ## Why the tests are green This is the part that makes it a senior question. Copying a mutex is legal Go. It compiles, it runs, and a table-driven unit test that calls `Inc` a hundred times sequentially passes with a correct-looking answer only if the test reads the counter through the same broken path — and if it reads it correctly, the failure looks like an off-by-everything bug rather than a locking bug. Nothing in the language or the runtime objects to a copied lock. `go test` will not object either, because `copylocks` is **not** in the curated vet subset `go test` runs before your tests; you only see it from a full `go vet ./...`. The race detector is a partial safety net at best. `go test -race` reports races that actually happen during the run: if the test exercises the concurrent path and the interleaving occurs, you get a report; if the concurrency only exists in production, you get silence. `-race` is a dynamic check, so a clean run proves nothing about paths that were not executed. `copylocks` is static, so it fires whether or not the code is ever run concurrently — which is precisely why reading `go vet ./...` output line by line finds things a green test suite does not. ## Its neighbours in the suite Two more shipped checks belong to the same family of "real bugs a test run passes over": - **`lostcancel`** — the `cancel` function returned by `context.WithCancel`, `WithTimeout` or `WithDeadline` is not called on some path. The derived context and its timer stay alive until the parent finishes, which on a long-lived parent is a leak that grows with traffic. The idiom `ctx, cancel := context.WithTimeout(...); defer cancel()` exists to satisfy exactly this. - **`unusedresult`** — the result of a pure call such as `fmt.Sprintf` or `errors.New` is discarded. `errors.New("boom")` on a line by itself does nothing at all; somebody meant to return it. ## The practical posture In a repository with dozens of drive-by contributors and no shared house style beyond the tools, these checks are how a lost lock gets caught by a machine instead of by a reviewer who happened to be paying attention. Treat a `copylocks` line as a defect report, not as lint noise: unlike a style rule, it is describing code whose concurrency guarantee is already gone.