In CL 129061, a check was added for patterns that reference
nonexistent local directories. While this prevented unnecessary
network lookups (fixing #26874), it caused "go list -e" to exit with
an error instead of listing packages with error messages.

This change avoids the network lookup and does not exit for these
kinds of packages. Errors are still reported by
internal/load.LoadImport for packages that don't exist.

Fixes #28023

Change-Id: I0a648269e437aed3a95bfb05461a397264f3793f
Reviewed-on: https://go-review.googlesource.com/c/151800
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Updates #29087

Change-Id: I0bab45818119176c2ba5de9c0e457b7717485d6f
Reviewed-on: https://go-review.googlesource.com/c/152162
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The type checker may be called incrementally (by repeatedly calling
Checker.Files), for instance when adding _test.go files to a set of
already checked files.

The existing code reset a cache of (already computed) interface
information with each Checker.Files call, causing interfaces to be
recomputed in some cases, albeit with different receiver information
(see comments in this CL for details).

Don't reset the interface cache to avoid this problem.

While adding a test case, also factor out some common testing logic.

Fixes #29029.

Change-Id: I2e2d6d6bb839b3a76522fbc4ba7355c71d3bb80b
Reviewed-on: https://go-review.googlesource.com/c/152259Reviewed-by: Alan Donovan <adonovan@google.com>

Fix unannounced trailers when body is empty and without announced trailers.

Fixes #29031

Change-Id: If49951a42fe56d4be4436a999627db4c2678659d
GitHub-Last-Rev: 3469adc8f5fd977438350274134950687853a468
GitHub-Pull-Request: golang/go#29032
Reviewed-on: https://go-review.googlesource.com/c/151898
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

To pull in the fix for #28858, which we want to include for Go 1.12.

Fixes #28858.

Change-Id: Id4964cfd38e3d44d6317a2ee124fe2d35038b5fd
Reviewed-on: https://go-review.googlesource.com/c/152277
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

Fixes #28069

Change-Id: I7e0f96b8b6d123de283325fcb78ec76455050f6d
Reviewed-on: https://go-review.googlesource.com/c/152158
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

And remove some unnecessary textproto references. (The net/http
package's CanonicalHeaderKey just calls textproto's
CanonicalMIMEHeaderKey)

Fixes #28894

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

Darwin doesn't support the multiple copies of the runtime package
implied by linking a c-shared library into a Go program.

Updates #29061

Change-Id: I6cf5d00babf82f1de05689c1345aaa5ae0b0659c
Reviewed-on: https://go-review.googlesource.com/c/152159
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

staticcopy of a struct or array should recursively call itself, not
staticassign.

This fixes an issue where a struct with a slice in it is copied during
static initialization. In this case, the backing array for the slice
is duplicated, and each copy of the slice refers to a different
backing array, which is incorrect.  That issue has existed since at
least Go 1.2.

I'm not sure why this was never noticed. It seems like a pretty
obvious bug if anyone modifies the resulting slice.

In any case, we started to notice when the optimization in CL 140301
landed.  Here is basically what happens in issue29013b.go:
1) The error above happens, so we get two backing stores for what
   should be the same slice.
2) The code for initializing those backing stores is reused.
   But not duplicated: they are the same Node structure.
3) The order pass allocates temporaries for the map operations.
   For the first instance, things work fine and two temporaries are
   allocated and stored in the OKEY nodes. For the second instance,
   the order pass decides new temporaries aren't needed, because
   the OKEY nodes already have temporaries in them.
   But the order pass also puts a VARKILL of the temporaries between
   the two instance initializations.
4) In this state, the code is technically incorrect. But before
   CL 140301 it happens to work because the temporaries are still
   correctly initialized when they are used for the second time. But then...
5) The new CL 140301 sees the VARKILLs and decides to reuse the
   temporary for instance 1 map 2 to initialize the instance 2 map 1
   map. Because the keys aren't re-initialized, instance 2 map 1
   gets the wrong key inserted into it.

Fixes #29013

Change-Id: I840ce1b297d119caa706acd90e1517a5e47e9848
Reviewed-on: https://go-review.googlesource.com/c/152081
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

This is just the first step in attempting to make all network connection have
timeouts as a "safe default". TCP keepalives only protect against certain
classes of network and host issues (e.g. server/OS crash), but do nothing
against application-level issues (e.g. an application that accepts connections
but then fails to serve requests).

The actual keep-alive duration (15s) is chosen to cause broken connections
to be closed after 2~3 minutes (depending on the OS, see #23549 for details).
We don't make the actual default value part of the public API for a number of
reasons:
- because it's not very useful by itself: as discussed in #23549 the actual
  "timeout" after which the connection is torn down is duration*(KEEPCNT+1),
  and we use the OS-wide value for KEEPCNT because there's currently no way
  to set it from Go.
- because it may change in the future: if users need to rely on a specific
  value they should explicitly set this value instead of relying on the default.

Fixes #23459

Change-Id: I348c03be97588d5001e6de0f377e7a93b51957fd
Reviewed-on: https://go-review.googlesource.com/c/107196
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

StatusTooEarly can be returned to indicate that a server is unwilling
to accept early data as introduced in TLS 1.3.
The status code was specified in RFC 8470, section 5.2.

Major supported browsers are:
- Firefox as of version 58
  https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/425#Browser_compatibility
- Chromium as of version 73.0.3628.1
  https://chromium.googlesource.com/chromium/src/+/58097ec3823e0f340ab5abfcaec1306e1d954c5a

Change-Id: I3f62f4193bae198994d08fde7e92e0ccd080e59a
GitHub-Last-Rev: fa885040eaf80e0e33b571567108d8a9ded67801
GitHub-Pull-Request: golang/go#29073
Reviewed-on: https://go-review.googlesource.com/c/152118Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Before this change, location list construction would extend
from the previous (in linear order) block, even if was not a
flow predecessor.  This can cause a debugger to tell lies.

Fix accounts for this in block merging code by (crudely)
"changing" all variables live from a previous block if it
is not also a predecessor.

Fixes #28486.

Change-Id: I11336b0b969f0cd09f40f4e5f2bdfdeb02f377a4
Reviewed-on: https://go-review.googlesource.com/c/146718
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>

Follow-up for CL 147037 and after Brad noticed the "returns whether"
pattern during the review of CL 150621.

Go documentation style for boolean funcs is to say:

    // Foo reports whether ...
    func Foo() bool

(rather than "returns whether")

Created with:

    $ perl -i -npe 's/returns whether/reports whether/' $(git grep -l "returns whether" | grep -v vendor)

Change-Id: I15fe9ff99180ad97750cd05a10eceafdb12dc0b4
Reviewed-on: https://go-review.googlesource.com/c/150918
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

golang.org/cl/151977 slightly decreased the cost of inlining an extra
call from 60 to 57, since it was a safe change that could help in some
scenarios.

One notable change spotted in that CL is that bytes.Buffer.Grow is now
inlinable, meaning that a fixedbugs test needed updating.

For consistency, add the test case to TestIntendedInlining too,
alongside other commonly used bytes.Buffer methods.

Change-Id: I4fb402fc684ef4c543fc65aea343ca1a4d73a189
Reviewed-on: https://go-review.googlesource.com/c/151979
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

A Go user made a well-documented request for a slightly
lower threshold.  I tested against a selection of other
people's benchmarks, and saw a tiny benefit (possibly noise)
at equally tiny cost, and no unpleasant surprises observed
in benchmarking.

I.e., might help, doesn't hurt, low risk, request was
delivered on a silver platter.

It did, however, change the behavior of one test because
now bytes.Buffer.Grow is eligible for inlining.

Updates #19348.

Change-Id: I85e3088a4911290872b8c6bda9601b5354c48695
Reviewed-on: https://go-review.googlesource.com/c/151977
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Avoid redefinition errors when a Go file uses a cgo comment to
There is no particularly good reason to do this, but there is also no
particularly good reason that it should fail.

Fixes #27019

Change-Id: Icd6f8197a89be4ee6b03ddae675667998a8b4189
Reviewed-on: https://go-review.googlesource.com/c/152079
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This CL adds several test cases of arithmetic operations for
386/amd64/arm/arm64.

Change-Id: I362687c06249f31091458a1d8c45fc4d006b616a
Reviewed-on: https://go-review.googlesource.com/c/151897
Run-TryBot: Ben Shi <powerman1st@163.com>
Reviewed-by: Keith Randall <khr@golang.org>

This updates x/net/http2 to x/net git rev 351d144f for:

   http2: revert Transport's strict interpretation of MAX_CONCURRENT_STREAMS
   https://golang.org/cl/151857

   http2: don't leak streams on broken body
   https://golang.org/cl/132715

   http2: remove support for Go 1.8 and earlier
   https://golang.org/cl/145677

   http2: reduce init-time work & allocations
   https://golang.org/cl/127664

And some CLs fixing typos.

Fixes #27044
Fixes #27208

Change-Id: I11cc32576c690199ceb4c0bd1448d01e3cab3097
Reviewed-on: https://go-review.googlesource.com/c/152080
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

The stat(2) man page contain this comment about the 64-bit versions
of the system file functions:

"Platforms that were released after these updates only have the
newer variants available to them.  These platforms have the macro
_DARWIN_FEATURE_ONLY_64_BIT_INODE defined."

It turns out that on iOS the _DARWIN_FEATURE_ONLY_64_BIT_INODE is
defined and that even though the "64"-postfixed versions are
accessible they are deemed private. Apps that refer to private
API are not admissible on App Store, and after the Go runtime
started using libSystem instead of direct syscalls, the App Store
submission checks reject apps built with Go tip.

The fix is simple: use the non-postfixed versions on iOS.

getdirentries(2) is not changed; it is not available at all on iOS
and needs replacement.

Updates #28984

Change-Id: Icb8d44e271456acaa1913ba486fcf5b569722fa9
Reviewed-on: https://go-review.googlesource.com/c/151938
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

While here, rename nonnegintconst to indexconst (because that's
what it is) and add Fatalf calls where we are not expecting the
indexconst call to fail, and fixed wrong comparison in smallintconst.

Fixes #23781.

Change-Id: I86eb13081c450943b1806dfe3ae368872f76639a
Reviewed-on: https://go-review.googlesource.com/c/151599
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

This change fixes an error in HACKING.md which claims all pointers
which live in unmanaged memory but point to the heap must be marked
as GC roots explicitly by runtime.markroot. This isn't technically
necessary if the pointer is accessible through a global variable.

Change-Id: I632b25272fdb2f789c5259dd1685d517f45fd435
Reviewed-on: https://go-review.googlesource.com/c/151539Reviewed-by: Rick Hudson <rlh@golang.org>

In TestObjImporter skip tests that use type aliases when using a
version of gccgo before GCC 7, since that is when type aliases were
added.

Fixes #29006

Change-Id: I676bae9f023931cf95ac9b4d4de893fe8517af9b
Reviewed-on: https://go-review.googlesource.com/c/152078Reviewed-by: Than McIntosh <thanm@google.com>

TestInstallationImporter checks that it can read the export data for a
list of known standard library packages. It was failing on the SmartOS
builder which has GCC 4.7 installed. Skip packages that did not exist
in GCC 4.7. Most packages are still there and the missing packages are
fairly simple, so this doesn't really affect test quality.

Updates #29006

Change-Id: If7ae6f83d51d40168a9692acb0b99c9bf21f2a4d
Reviewed-on: https://go-review.googlesource.com/c/152077
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fix a bug in the reading of elderly export data. In such export data
when reading type information it's possible to encounter a named type N1
defined as a typedef of some other named type N2 at a point when the
underying type of N1 has not yet been finalized. Handle this case by
generating a fixup, then process fixups at the end of parsing to
set the correct underlying type.

Fixes #29006.

Change-Id: I6a505c897bd95eb161ee04637bb6eebad9f20d52
Reviewed-on: https://go-review.googlesource.com/c/151997
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #28960

Change-Id: I0d049d4776dc42ef165a1da15f63de08677fbb85
Reviewed-on: https://go-review.googlesource.com/c/151661
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

signatureSchemesForCertificate was written to be used with TLS 1.3, but
ended up used for TLS 1.2 client certificates in a refactor. Since it
only supported TLS 1.3 signature algorithms, it would lead to no RSA
client certificates being sent to servers that didn't support RSA-PSS.

TestHandshakeClientCertRSAPKCS1v15 was testing *specifically* for this,
but alas the OpenSSL flag -verify accepts an empty certificates list as
valid, as opposed to -Verify...

Fixes #28925

Change-Id: I61afc02ca501d3d64ab4ad77bbb4cf10931e6f93
Reviewed-on: https://go-review.googlesource.com/c/151660
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

Updates golang/go#27992

Change-Id: Ic327df7cc5002a3d537f9117559c25f30e1eab9c
Reviewed-on: https://go-review.googlesource.com/c/151799
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The call to os.Rename was failing on the darwin builders, despite having passed in the TryBots.
(I tested this change by running 'go test cmd/go' manually on a darwin gomote.)

This fixes the builder failures after CL 146382.

Updates #26794
Fixes #29030

Change-Id: I3644773421789f65e56f183d077b4e4fd17b8325
Reviewed-on: https://go-review.googlesource.com/c/151798Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I0390b382db0ca36de20af0ef15204c5bfc084d3d
Reviewed-on: https://go-review.googlesource.com/c/151937
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

We don't need a write barrier if:
1) The location we're writing to doesn't hold a heap pointer, and
2) The value we're writing isn't a heap pointer.

The freshly returned value from runtime.newobject satisfies (1).
Pointers to globals, and the contents of the read-only data section satisfy (2).

This is particularly helpful for code like:
p := []string{"abc", "def", "ghi"}

Where the compiler generates:
   a := new([3]string)
   move(a, statictmp_)  // eliminates write barriers here
   p := a[:]

For big slice literals, this makes the code a smaller and faster to
compile.

Update #13554. Reduces the compile time by ~10% and RSS by ~30%.

Change-Id: Icab81db7591c8777f68e5d528abd48c7e44c87eb
Reviewed-on: https://go-review.googlesource.com/c/151498
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

This adds several new checks to help debug #27993. It adds a mechanism
for freezing write barriers and gcWork puts during the mark completion
algorithm. This way, if we do detect mark completion, we can catch any
puts that happened during the completion algorithm. Based on build
dashboard failures, this seems to be the window of time when these are
happening.

This also double-checks that all work buffers are empty immediately
upon entering mark termination (much earlier than the current check).
This is unlikely to trigger based on the current failures, but is a
good safety net.

Change-Id: I03f56c48c4322069e28c50fbc3c15b2fee2130c2
Reviewed-on: https://go-review.googlesource.com/c/151797
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

The old code ignored the field alignment, and only looked at the field
offset: if the field offset required padding, cgo added padding. But
while that approach works for Go (at least with the gc toolchain) it
doesn't work for C code using packed structs. With a packed struct the
added padding may leave the struct at a misaligned position, and the
inserted alignment, which cgo is not considering, may introduce
additional, unexpected, padding. Padding that ignores alignment is not
a good idea when the struct is not packed, and Go structs are never
packed. So don't ignore alignment.

Fixes #28896

Change-Id: Ie50ea15fa6dc35557497097be9fecfecb11efd8a
Reviewed-on: https://go-review.googlesource.com/c/150602
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

We refactor the conversion of quotes to their unicode equivalent
to a separate function so that it can be called from ToText and Synopsis.

And we introduce a temp buffer to write the escaped HTML and convert
the unicode quotes back to html escaped entities. This simplifies the logic
and gets rid of the need to track the index of the escaped text.

Fixes #27759

Change-Id: I71cf47ddcd4c6794ccdf2898ac25539388b393c1
Reviewed-on: https://go-review.googlesource.com/c/150377
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Adjust mTreap ordering logic to reflect the description of mTreap ordering.
Before it was using unsafe.Pointer in order to gather the base address of
a span. This has been changed to use base, which is the startAddress of a
span as the description is telling us in mgclarge.go.

Fixes: golang/go#28805

Change-Id: Ib3cd94a0757e23d135b5d41830f38fc08bcf16a3
GitHub-Last-Rev: 93f749b6700b1e179de16607a18395d5e162ecc1
GitHub-Pull-Request: golang/go#28973
Reviewed-on: https://go-review.googlesource.com/c/151499Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>

Previously, we were looking for the string go.mod specifically, but
the module-mode-outside-a-module logic added in CL 148517 sets GOMOD
to os.DevNull

Updates #28992

Change-Id: I62a4baaa911a495350294d78bae96be3fe4866cb
Reviewed-on: https://go-review.googlesource.com/c/151617
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I4717964234fca0c8c5889ed710b66f39eb53a809
Reviewed-on: https://go-review.googlesource.com/c/151562
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

The test that used that module was removed in
https://golang.org/cl/128900.

Change-Id: Id96270a52398c8ccc09821efb2a6a6b4764f44d9
Reviewed-on: https://go-review.googlesource.com/c/151560
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

This assignment became a no-op in CL 36196, where both it and the
preceding assignment were changed to cfg.GOROOTbin (from gorootBin and
gobin respectively).

Change-Id: If74969c4cc3ffc5d8394ff9d8e8bcec9e0a4e3b0
Reviewed-on: https://go-review.googlesource.com/c/151561
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Also test that Download restores deleted files.

Updates #27783

Change-Id: If50074dbcffd74ff08fbaa9ad8c314cfdce0b02d
Reviewed-on: https://go-review.googlesource.com/c/151559
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

This is as minimal a change as I could comfortably make to enable 'go
get' outside of a module for 1.12.

In general, commands invoked in module mode while outside of a module
operate as though they are in a module with an initially-empty go.mod
file. ('go env GOMOD' reports os.DevNull.)

Commands that operate on the current directory (such as 'go list' and
'go get -u' without arguments) fail: without a module definition, we
don't know the package path. Likewise, commands whose sole purpose is
to write files within the main module (such as 'go mod edit' and 'go
mod vendor') fail, since we don't know where to write their output.

Since the go.sum file for the main module is authoritative, we do not
check go.sum files when operating outside of a module. I plan to
revisit that when the tree opens for 1.13.

We may also want to revisit the behavior of 'go list': it would be
useful to be able to query individual packages (and dependencies of
those packages) within versioned modules, but today we only allow
versioned paths in conjunction with the '-m' flag.

Fixes #24250

RELNOTE=yes

Change-Id: I028c323ddea27693a92ad0aa4a6a55d5e3f43f2c
Reviewed-on: https://go-review.googlesource.com/c/148517
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>