These are the easy, automated cases. There were some more where we
need to fight Gerrit and the CLA system to extract the appropriate
metadata.

Updates #12042

Change-Id: Id63ae635ee7efeec4cd372c7d85bb5b1f557951b
Reviewed-on: https://go-review.googlesource.com/18264Reviewed-by: Ian Lance Taylor <iant@golang.org>

Try to reduce feature request bug reports.

Change-Id: I713bb715d25d23e084b054aea8e1c3197dde90d4
Reviewed-on: https://go-review.googlesource.com/18222Reviewed-by: Ian Lance Taylor <iant@golang.org>

In the beginning, there was no way to cancel an HTTP request.

We later added Transport.CancelRequest to cancel an in-flight HTTP
request by breaking its underlying TCP connection, but it was hard to
use correctly and didn't work in all cases. And its error messages
were terrible. Some of those issues were fixed over time, but the most
unfixable problem was that it didn't compose well. All RoundTripper
implementations had to choose to whether to implement CancelRequest
and both decisions had negative consequences.

In Go 1.5 we added Request.Cancel, which composed well, worked in all
phases, had nice error messages, etc. But we forgot to use it in the
implementation of Client.Timeout (a timeout which spans multiple
requests and reading request bodies).

In Go 1.6 (upcoming), we added HTTP/2 support, but now Client.Timeout
didn't work because the http2.Transport didn't have a CancelRequest
method.

Rather than add a CancelRequest method to http2, officially deprecate
it and update the only caller (Client, for Client.Cancel) to use
Request.Cancel instead.

The http2 Client timeout tests are enabled now.

For compatibility, we still use CancelRequest in Client if we don't
recognize the RoundTripper type. But documentation has been updated to
tell people that CancelRequest is deprecated.

Fixes #13540

Change-Id: I15546b90825bb8b54905e17563eca55ea2642075
Reviewed-on: https://go-review.googlesource.com/18260Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Slightly rephrased sentence to emphasize the contents of the
Unicode categories w/o repeating the full category name each
time.

Fixes #13414.

Change-Id: Icd32ff1547fa81e866c5937a631c3344bb6087c6
Reviewed-on: https://go-review.googlesource.com/18265Reviewed-by: Rob Pike <r@golang.org>

In debugging the flaky test in #13825, I discovered that my previous
change to tighten and simplify the communication protocol between
Transport.roundTrip and persistConn.readLoop in
https://golang.org/cl/17890 wasn't complete.

This change simplifies it further: the buffered-vs-unbuffered
complexity goes away, and we no longer need to re-try channel reads in
the select case. It was trying to prioritize channels in the case that
two were readable in the select. (it was only failing in the race builder
because the race builds randomize select scheduling)

The problem was that in the bodyless response case we had to return
the idle connection before replying to roundTrip. But putIdleConn
previously both added it to the free list (which we wanted), but also
closed the connection, which made the caller goroutine
(Transport.roundTrip) have two readable cases: pc.closech, and the
response. We guarded against similar conditions in the caller's select
for two readable channels, but such a fix wasn't possible here, and would
be overly complicated.

Instead, switch to unbuffered channels. The unbuffered channels were only
to prevent goroutine leaks, so address that differently: add a "callerGone"
channel closed by the caller on exit, and select on that during any unbuffered
sends.

As part of the fix, split putIdleConn into two halves: a part that
just returns to the freelist, and a part that also closes. Update the
four callers to the variants each wanted.

Incidentally, the connections were closing on return to the pool due
to MaxIdleConnsPerHost (somewhat related: #13801), but this bug
could've manifested for plenty of other reasons.

Fixes #13825

Change-Id: I6fa7136e2c52909d57a22ea4b74d0155fdf0e6fa
Reviewed-on: https://go-review.googlesource.com/18282
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

This test triggers a large number of usleep(100)s. linux/arm, openbsd,
and solaris have very poor timer resolution on the builders, so
usleep(100) actually gives up the whole scheduling quantum. On Linux
and OpenBSD (and probably Solaris), profiling signals are only
generated when a process completes a whole scheduling quantum, so this
test often gets zero profiling signals and fails.

Until we figure out what to do about this, skip this test on these
platforms.

Updates #13405.

Change-Id: Ica94e4a8ae7a8df3e5a840504f83ee2ec08727df
Reviewed-on: https://go-review.googlesource.com/18252Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Austin Clements <austin@google.com>

Previously, when a program died because of a SIGHUP, SIGINT, or SIGTERM
signal it would exit with status 2.  This CL fixes the runtime to exit
with a status indicating that the program was killed by a signal.

Change-Id: Ic2982a2562857edfdccaf68856e0e4df532af136
Reviewed-on: https://go-review.googlesource.com/18156Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

Use the current ability to say that we don't do anything with SIGCONT by
default, but programs can catch it using signal.Notify if they want.

Fixes #8953.

Change-Id: I67d40ce36a029cbc58a235cbe957335f4a58e1c5
Reviewed-on: https://go-review.googlesource.com/18185Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Added a format option to inhibit output of .Note field in
printing, and enabled that option during export.
Added test.

Fixes #13777.

Change-Id: I739f9785eb040f2fecbeb96d5a9ceb8c1ca0f772
Reviewed-on: https://go-review.googlesource.com/18217Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>

For #10571.

Change-Id: I9a42226078b9c52dbe0c65cb101b5f452233e911
Reviewed-on: https://go-review.googlesource.com/18205Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

For #13789.

Change-Id: I83973298a35afcf55627f0a72223098306a51f4b
Reviewed-on: https://go-review.googlesource.com/18233Reviewed-by: Ian Lance Taylor <iant@golang.org>

When 'go tool dist test' stops, it was intended that it first wait for
pending background tests, like a failed compilation waits for pending
background compiles. But these three lines prevented that.
Fix by deleting them. (The actual loop already contains the correct
logic to avoid running the others and to wait for what's left.)

Change-Id: I4e945495ada903fb0af567910626241bc1c52ba6
Reviewed-on: https://go-review.googlesource.com/18232Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The CloseNotifier implementation and documentation was
substantially changed in https://golang.org/cl/17750 but it was a bit
too aggressive.

Issue #13666 highlighted that in addition to breaking external
projects, even the standard library (httputil.ReverseProxy) didn't
obey the new rules about not using CloseNotifier until the
Request.Body is fully consumed.

So, instead of fixing httputil.ReverseProxy, dial back the rules a
bit. It's now okay to call CloseNotify before consuming the request
body. The docs now say CloseNotifier may wait to fire before the
request body is fully consumed, but doesn't say that the behavior is
undefined anymore. Instead, we just wait until the request body is
consumed and start watching for EOF from the client then.

This CL also adds a test to ReverseProxy (using a POST request) that
would've caught this earlier.

Fixes #13666

Change-Id: Ib4e8c29c4bfbe7511f591cf9ffcda23a0f0b1269
Reviewed-on: https://go-review.googlesource.com/18144Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #13346.

Change-Id: Ic903ee90575e8dbe23905d0678d3295745d1d47f
Reviewed-on: https://go-review.googlesource.com/18154
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: Ia8c1c77590115a5ffda144962436d489ed77a423
Reviewed-on: https://go-review.googlesource.com/18227Reviewed-by: Ian Lance Taylor <iant@golang.org>

Old behavior: 10 consecutive EPIPE errors on any descriptor cause the
program to exit with a SIGPIPE signal.

New behavior: an EPIPE error on file descriptors 1 or 2 cause the
program to raise a SIGPIPE signal.  If os/signal.Notify was not used to
catch SIGPIPE signals, this will cause the program to exit with SIGPIPE.
An EPIPE error on a file descriptor other than 1 or 2 will simply be
returned from Write.

Fixes #11845.
Update #9896.

Change-Id: Ic85d77e386a8bb0255dc4be1e4b3f55875d10f18
Reviewed-on: https://go-review.googlesource.com/18151Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #13034.
Fixes #13042.
Update #9896.

Change-Id: I189f381090223dd07086848aac2d69d2c00d80c4
Reviewed-on: https://go-review.googlesource.com/18062Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I2b61f3b3ecf28d8f6a8dff94d194b6d3d450ea22
Reviewed-on: https://go-review.googlesource.com/17996Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I155633b58e1823344a26c3edf11f5626fae080ee
Reviewed-on: https://go-review.googlesource.com/18204Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

For #10571.

Change-Id: I4bdad64e2dfd692ef2adccf2e5e82e9b1996a8ea
Reviewed-on: https://go-review.googlesource.com/18206Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>

This CL changes the source file information in the
standard library's .a files to say "$GOROOT/src/runtime/chan.go"
(with a literal "$GOROOT") instead of spelling out the actual directory.
The linker then substitutes the actual $GOROOT (or $GOROOT_FINAL)
as appropriate.

If people download a binary distribution to an alternate location,
following the instructions at https://golang.org/doc/install#install,
the code before this CL would end up with source paths pointing to
/usr/local/go no matter where the actual sources were.
Now the source paths for built binaries will point to the actual sources
(hopefully).

The source line information in distributed binaries is not affected:
those will still say /usr/local/go. But binaries people build themselves
(their own programs, not the go distribution programs) will be correct.

Fixing this path also fixes the lookup of the runtime-gdb.py file.

Fixes #5533.

Change-Id: I03729baae3fbd8cd636e016275ee5ad2606e4663
Reviewed-on: https://go-review.googlesource.com/18200
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Following the parallelization of some tests, a race condition can
occur in testcarchive, testshared and testcshared.

In some cases, it can result in the go env GOROOT command returning
corrupted data, which are then passed to a rm command.

Make the shell script more robust by not trusting the result of
the go env GOROOT command. It does not really fix the issue, but
at least prevent the entire repository to be deleted.

Updates #13789

Change-Id: Iaf04a7bd078ed3a82e724e35c4b86e6f756f2a2f
Reviewed-on: https://go-review.googlesource.com/18173
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

https://golang.org/cl/18087 added a bunch of t.Parallel calls, which
aren't compatible with the afterTest func. But in short mode, afterTest
is a no-op. To keep all.bash (short mode) fast, conditionally set
t.Parallel when in short mode, but keep it unset for compatibility with
afterFunc otherwise.

Fixes #13804

Change-Id: Ie841fbc2544e1ffbee43ba1afbe895774e290da0
Reviewed-on: https://go-review.googlesource.com/18143Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I491197e1505d02cd107a8788e5377cf1d0a9828c
Reviewed-on: https://go-review.googlesource.com/18157Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I0280d478b7d0a59d8e2082aa87fab6d7d9f36a18
Reviewed-on: https://go-review.googlesource.com/18158Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>

Change-Id: I6ea7339ff9412111319e46f2962c6b3880987a1e
Reviewed-on: https://go-review.googlesource.com/18174Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I617abd53f5fc883b972a1ef090886b85607e00bb
Reviewed-on: https://go-review.googlesource.com/18155Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>

Fixes #13780.

Change-Id: I629e2ba79b74d693e04c3747812c9a686cae5335
Reviewed-on: https://go-review.googlesource.com/18218Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I85caba8c743dcd82954de75df947053b3d206bdc
Reviewed-on: https://go-review.googlesource.com/18117Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Open(`C:`) currently opens root directory on C:. Change that to open
current directory on C:. Just like cmd.exe's "dir C:" command does.
Just like FindFirstFile("C:*") Windows API does. It is also consistent
with what filepath.Join("C:", "a") currently does.

Fixes #13763

Change-Id: I60b6e7d80215d110bbbb6265c9f32717401638c6
Reviewed-on: https://go-review.googlesource.com/18184Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>

Change-Id: I374dabed6bf9783839d637e9d7fd6f4e61c7eecf
Reviewed-on: https://go-review.googlesource.com/18183Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #13752

Change-Id: I53cfc4ecae90c35b6f1074f3be08489c408a6464
Reviewed-on: https://go-review.googlesource.com/18181Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Now there are just three programs to compile instead of many,
and repeated tests can reuse the compilation result instead of
rebuilding it.

Combined, these changes reduce the time spent testing runtime
during all.bash on my laptop from about 60 to about 30 seconds.
(All.bash itself runs in 5½ minutes.)

For #10571.

Change-Id: Ie2c1798b847f1a635a860d11dcdab14375319ae9
Reviewed-on: https://go-review.googlesource.com/18085Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>

Change-Id: I4a6928b4674b6aaab3611cad7526347923a0015f
Reviewed-on: https://go-review.googlesource.com/18153Reviewed-by: Ian Lance Taylor <iant@golang.org>

I broke the rule: never click the Submit button on the web.

Change-Id: If81a5cc31c1f28664960bad124cc596f5cab1222
Reviewed-on: https://go-review.googlesource.com/18203Reviewed-by: Russ Cox <rsc@golang.org>

Saves 15 seconds from all.bash on my laptop (3:20 -> 3:05).

Change-Id: Ic5dc3c7804e78b584789dd856a3dada94000a8e2
Reviewed-on: https://go-review.googlesource.com/18199Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

These find approximately nothing.
Takes 5% off my all.bash run time.

For #10571.

Change-Id: I21d3a844af756eb37f59bba0064f24995626da0d
Reviewed-on: https://go-review.googlesource.com/18198Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Takes 15% off my all.bash run time
(after this and earlier CLs, now down to 3½ from 5½ minutes).

For #10571.

Change-Id: Iac316ffb730c9ff0a0faa7cc3b82ed4f7e6d4361
Reviewed-on: https://go-review.googlesource.com/18088Reviewed-by: Ian Lance Taylor <iant@golang.org>

Mostly we just care that the test binaries link and start up.
No need to run the full test suites.

Takes 12% off my all.bash run time.

For #10571.

Change-Id: I01af618f3d51deb841ea638424e1389a2df7d746
Reviewed-on: https://go-review.googlesource.com/18086Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>

Takes 3% off my all.bash run time.

For #10571.

Change-Id: I8f00f523d6919e87182d35722a669b0b96b8218b
Reviewed-on: https://go-review.googlesource.com/18087Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>