qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-09-23 13:30:13 -06:00
Code Releases Activity

doc/go1.17: mention new vet checks sigchanyzer and stdmethods.

Browse Source 
These vet checks were added in CL 299532 and CL 321389.

Also adds a TODO for buildtags.

Change-Id: I516dc77729f6d2dc147318260fe452831b115dfa
Reviewed-on: https://go-review.googlesource.com/c/go/+/322769
Trust: Tim King <taking@google.com>
Run-TryBot: Tim King <taking@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This commit is contained in:
Tim King 2021-05-25 19:23:02 -07:00 committed by Ian Lance Taylor
parent 6551763a60
commit 63dcab2e91
1 changed files with 45 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
doc/go1.17.html
View File

@ -277,14 +277,55 @@ Do not send CLs removing the interior tags from such phrases.
<h3 id="vet">Vet</h3>
<p><!-- CL 299532 -->
TODO: <a href="https://golang.org/cl/299532">https://golang.org/cl/299532</a>: cmd/vet: bring in sigchanyzer to report unbuffered channels to signal.Notify
<h4 id="vet-buildtags">New warning within buildtags</h4>
<p><!-- CL 240609 -->
TODO(rsc): Describe changes to buildtags <a href="https://golang.org/cl/240609">https://golang.org/cl/240609</a>
</p>
<p>
TODO: complete the Vet section
<h4 id="vet-sigchanyzer">New warning for calling <code>signal.Notify</code> on unbuffered channels</h4>
<p><!-- CL 299532 -->
The vet tool now warns about calls to <a href="/pkg/os/signal/#Notify">signal.Notify</a>
with incoming signals being sent to an unbuffered channel. Using an unbuffered channel
risks missing signals sent on them as <code>signal.Notify</code> does not block when
sending to a channel. For example:
</p>
<pre>
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)
</pre>
<p>
Users of <code>signal.Notify</code> should use channels with sufficient buffer space to keep up with the
expected signal rate.
</p>
<h4 id="vet-error-stdmethods">New warnings for Is, As and Unwrap methods</h4>
<p><!-- CL 321389 -->
The vet tool now warns about methods named <code>As</code>, <code>Is</code> or <code>Unwrap</code>
on types implementing the <code>error</code> interface that have a different signature than the
one expected by the <code>errors</code> package. The <code>errors.{As,Is,Unwrap}</code> functions
expect such methods to implement either <code>Is(error)</code> <code>bool</code>,
<code>As(interface{})</code> <code>bool</code>, or <code>Unwrap()</code> <code>error</code>
respectively. The functions <code>errors.{As,Is,Unwrap}</code> will ignore methods with the same
names but a different signature. For example:
</p>
<pre>
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.
}
</pre>
<h3 id="cover">Cover</h3>
<p><!-- CL 249759 -->