M0110 possible nil dereference
A pointer is dereferenced, or a map written to, where it can be nil: it is nil on one path into the use (var p *T; if c { p = &T{} }; p.f), or it comes from a function that returns nil with a nil error (or with ok true), in this package or another.
A use dominated by a nil check is not reported.
The mistake and the fix
func find(id int) (*User, error) {
if id == 0 {
return nil, nil
}
...
}
u, err := find(id)
if err != nil {
return err
}
fmt.Println(u.Name) // u is nil for id 0u, err := find(id)
if err != nil {
return err
}
if u == nil {
return errNotFound
}
fmt.Println(u.Name) The fix
Check for nil before the use, or make the function return an error instead of nil, nil.
See also all error codes and marmot explain.
M0109 switch misses cases
A switch on an enum-like type (a defined integer or string type with package level constants of that type) does not handle every constant, or a type switch on a sealed interface (one with an unexported method, so only its package implements it) does not handle every implementation, and there is no default clause.
M0111 heap allocation
marmot build -allocs lists where the program allocates on the heap and why the object could not live in the frame: it is returned, stored in memory that outlives the function or in a global, passed to a call that may keep it, captured by an escaping closure, converted to an interface, kept across loop iterations, or too large for the frame.