.

go/internal/xtracing/tracetest/chan.go

@@ -101,5 +101,5 @@ func (m *_Msg) nak(why string) {
 // newChan creates new _chan channel.
 func (t *T) newChan(name string) *_chan {
 	// NOTE T ensures not to create channels with duplicate names.
-	return &_chan{t: t, name: name, msgq: make(chan *_Msg), down: make(chan struct{}), }
+	return &_chan{t: t, name: name, msgq: make(chan *_Msg), down: make(chan struct{})}
 }

go/internal/xtracing/tracetest/tracetest.go

@@ -73,6 +73,34 @@
 // See example_test.go for more details.
 package tracetest
 
+// Note on detection of races
+//
+// Verify injects delays to empirically detect race conditions and if a test
+// incorrectly decomposed its system into serial streams: consider unrelated to
+// each other events A and B are incorrectly routed to the same channel. It
+// could be so happening that the order of checks on the test side is almost
+// always correct and so the error is not visible. However
+//
+//	if we add delays to delivery of either A or B
+//	and test both combinations
+//
+// we will for sure detect the error as, if A and B are indeed
+// unrelated, one of the delay combination will result in events
+// delivered to test in different to what it expects order.
+//
+// the time for delay could be taken as follows:
+//
+//	- run the test without delay; collect δt between events on particular stream
+//	- take delay = max(δt)·10
+//
+// to make sure there is indeed no different orderings possible on the
+// stream, rerun the test N(event-on-stream) times, and during i'th run
+// delay i'th event.
+//
+// See also on this topic:
+// http://www.1024cores.net/home/relacy-race-detector
+// http://www.1024cores.net/home/relacy-race-detector/rrd-introduction
+
 import (
 	"flag"
 	"fmt"
@@ -438,34 +466,6 @@ func Verify(t *testing.T, f func(t *T)) {
 	tT0 := run(t, f, nil)
 
 	// now, if f succeeds, verify f with injected delays.
-	//
-	// We inject delays to empirically detect race conditions and if a test
-	// incorrectly decomposed its system into serial streams: consider
-	// unrelated to each other events A and B are incorrectly routed to the
-	// same channel. It could be so happening that the order of checks on
-	// the test side is almost always correct and so the error is not
-	// visible. However
-	//
-	//	if we add delays to delivery of either A or B
-	//	and test both combinations
-	//
-	// we will for sure detect the error as, if A and B are indeed
-	// unrelated, one of the delay combination will result in events
-	// delivered to test in different to what it expects order.
-	//
-	// the time for delay could be taken as follows:
-	//
-	//	- run the test without delay; collect δt between events on particular stream
-	//	- take delay = max(δt)·10
-	//
-	// to make sure there is indeed no different orderings possible on the
-	// stream, rerun the test N(event-on-stream) times, and during i'th run
-	// delay i'th event.
-	//
-	// See also on this topic:
-	// http://www.1024cores.net/home/relacy-race-detector
-	// http://www.1024cores.net/home/relacy-race-detector/rrd-introduction
-
 	if tT0.Failed() {
 		return
 	}