- TODO: https://golang.org/cl/299532: cmd/vet: bring in sigchanyzer to report unbuffered channels to signal.Notify +
+ TODO(rsc): Describe changes to buildtags https://golang.org/cl/240609
-- TODO: complete the Vet section +
signal.Notify on unbuffered channels
+ The vet tool now warns about calls to signal.Notify
+ with incoming signals being sent to an unbuffered channel. Using an unbuffered channel
+ risks missing signals sent on them as signal.Notify does not block when
+ sending to a channel. For example:
+c := make(chan os.Signal) +// signals are sent on c before the channel is read from. +// This signal may be dropped as c is unbuffered. +signal.Notify(c, os.Interrupt) ++ +
+ Users of signal.Notify should use channels with sufficient buffer space to keep up with the
+ expected signal rate.
+
+ The vet tool now warns about methods named As, Is or Unwrap
+ on types implementing the error interface that have a different signature than the
+ one expected by the errors package. The errors.{As,Is,Unwrap} functions
+ expect such methods to implement either Is(error) bool,
+ As(interface{}) bool, or Unwrap() error
+ respectively. The functions errors.{As,Is,Unwrap} will ignore methods with the same
+ names but a different signature. For example:
+
+type MyError struct { hint string }
+func (m MyError) Error() string { ... } // MyError implements error.
+func (MyError) Is(target interface{}) bool { ... } // target is interface{} instead of error.
+func Foo() bool {
+ x, y := MyError{"A"}, MyError{"B"}
+ return errors.Is(x, y) // returns false as x != y and MyError does not have an `Is(error) bool` function.
+}
+
+