Reading from an incoming request body after the request handler aborts
with a panic can cause a panic, becuse http.Server does not (contrary
to its documentation) close the request body in this case.
Always close the incoming request body in ReverseProxy.ServeHTTP to
ensure that any in-flight outgoing requests using the body do not
read from it.
Updates #46866
Fixes CVE-2021-36221
Change-Id: I310df269200ad8732c5d9f1a2b00de68725831df
Reviewed-on: https://go-review.googlesource.com/c/go/+/333191
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
When returning from Go to C, it was possible for the goroutine to be
preempted after calling unlockOSThread. This could happen when there
a context function installed by SetCgoTraceback set a non-zero context,
leading to a defer call in cgocallbackg1. The defer function wrapper,
introduced in 1.17 as part of the regabi support, was not nosplit,
and hence was a potential preemption point. If it did get preempted,
the G would move to a new M. It would then attempt to return to C
code on a different stack, typically leading to a SIGSEGV.
Fix this in a simple way by postponing the unlockOSThread until after
the other defer. Also check for the failure condition and fail early,
rather than waiting for a SIGSEGV.
Without the fix to cgocall.go, the test case fails about 50% of the
time on my laptop.
Fixes#47441
Change-Id: Ib8ca13215bd36cddc2a49e86698824a29c6a68ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/338197
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This fixes a logic error introduced in CL 337850.
Fixes#47444
Change-Id: I6a49c8fc71fdde4ecb7f2e3329ad1f2cd286b7eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/338189
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Ironically, checkptrAlignment had a latent case of bad pointer
arithmetic: if ptr is nil, then `add(ptr, size-1)` might produce an
illegal pointer value.
The fix is to simply check for nil at the top of checkptrAlignment,
and short-circuit if so.
This CL also adds a more explicit bounds check in checkptrStraddles,
rather than relying on `add(ptr, size-1)` to wrap around. I don't
think this is necessary today, but it seems prudent to be careful.
Fixes#47430.
Change-Id: I5c50b2f7f41415dbebbd803e1b8e7766ca95e1fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/338029
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
When checking for updates, the go command checks whether the highest
compatible version has a go.mod file in order to determine whether
+incompatible versions may be considered "latest". Previously, to
perform this check, the go command would download the content of the
module (the .zip file) to see whether a go.mod file was present at the
root. This is slower than necessary, and it caused 'go list -m -u' to
try to save the sum for the .zip file in go.sum in some cases.
With this change, the go command only downloads the .mod file and
checks whether it appears to be a fake file generated for a version
that didn't have a go.mod file. This is faster and requires less
verification. Fake files only have a "module" directive. It's possible
to commit a file that passes this test, but it would be difficult to
do accidentally: Go 1.12 and later at least add a "go" directive. A
false positive here would cause version queries to have slightly
different results but would not affect builds.
Fixes#47377
Change-Id: Ie5ffd0b45e39bd0921328a60af99a9f6e5ab6346
Reviewed-on: https://go-review.googlesource.com/c/go/+/337850
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
According to the discussion, it is clear that T.Name returns a
distinct name among all tests. However, there is no specification
of how sub-tests with the same specified test name are constructed.
This change only clarifies the uniqueness and the components of the
name without suggesting any explicit format of the returned name.
Fixes#46488
Change-Id: I6cebd419b69fb08d8646cb744a129548452042ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/337392
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
CL 291316 fixed go/types to verify that untyped shift counts are
representable by uint, but as a side effect also converted their types
to uint.
Rearrange the logic to keep the check for representability, but not
actually convert untyped integer constants. Untyped non-integer
constants are still converted, to preserve the behavior of 1.16. This
behavior for non-integer types is a bug, filed as #47410.
Updates #47410Fixes#47243
Change-Id: I5eab4aab35b97f932fccdee2d4a18623ee2ccad5
Reviewed-on: https://go-review.googlesource.com/c/go/+/337529
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In CL 336432 we changed adjusttimers so that it no longer cleared
timerModifiedEarliest if there were no timersModifiedEarlier timers.
This caused some Google internal tests to time out, presumably due
to the increased contention on timersLock. We can avoid that by
simply not skipping the loop in adjusttimers, which lets us safely
clear timerModifiedEarliest. And if we don't skip the loop, then there
isn't much reason to keep the count of timerModifiedEarlier timers at all.
So remove it.
The effect will be that for programs that create some timerModifiedEarlier
timers and then remove them all, the program will do an occasional
additional loop over all the timers. And, programs that have some
timerModifiedEarlier timers will always loop over all the timers,
without the quicker exit when they have all been seen. But the loops
should not occur all that often, due to timerModifiedEarliest.
For #47329
Change-Id: I7b244c1244d97b169a3c7fbc8f8a8b115731ddee
Reviewed-on: https://go-review.googlesource.com/c/go/+/337309
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
There is an example for nil slice already, so adding example for non-nil
zero length slice, too, clarifying to the reader that the result is also
non-nil and different from nil slice case.
Updates #395
Change-Id: I019db1b1a1c0c621161ecaaacab5a4d888764b1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/336890
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Updates #44513
Change-Id: Ia0c6b48bde2719f3a99cb216b6166d82159198d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/336930
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, the ABI analysis assigns parameter/result offsets
to the fields of function *Type. In some cases, we may have
an ABI0 function reference and an ABIInternal reference share
the same function *Type. For example, for an ABI0 function F,
"f := F" will make f and (ABI0) F having the same *Type. But f,
as a func value, should use ABIInternal. Analyses on F and f will
collide and cause ICE.
Also, changing field offsets in ABI analysis has to be done very
carefully to avoid data races. It has been causing
trickiness/difficulty.
This CL removes the change of field offsets in ABI analysis
altogether. The analysis result is stored in ABIParamAssignment,
which is the only way to access parameter/result stack offset now.
Fixes#47317.
Fixes#47227.
Change-Id: I23a3e081a6cf327ac66855da222daaa636ed1ead
Reviewed-on: https://go-review.googlesource.com/c/go/+/336629
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This avoids a race when a new timerModifiedEarlier timer is created by
a different goroutine.
Fixes#47329
Change-Id: I6f6c87b4a9b5491b201c725c10bc98e23e0ed9d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/336432
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
It was not safe to do mcache profiling updates outside the critical
section, but we got lucky because the runtime was not preemptible.
Adding chunked memory clearing (CL 270943) created preemption
opportunities, which led to corruption of runtime data structures.
Fixes#47304.
Fixes#47302.
Change-Id: I461615470d62328a83ccbac537fbdc6dcde81c85
Reviewed-on: https://go-review.googlesource.com/c/go/+/336449
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Change-Id: I5a2f7203f83be02b03aa7be5fe386e485bf68ca3
Reviewed-on: https://go-review.googlesource.com/c/go/+/336189
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Findley <rfindley@google.com>
For #395
For #46746
Change-Id: I4bfc094cf1cecd27ce48e31f92384cf470f371a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/334669
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
No test because a real test requires installing two different compilers.
For #40042
For #47251
Change-Id: Iefddd67830d242a119378b7ce20be481904806e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/335409
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This test has been failing since the builder was updated to
NetBSD 9. While the issue is under investigation, skip the test
so that we do not miss other breakage.
Update issue #45026
Change-Id: Id083901c517f3f88e6b4bc2b51208f65170d47a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/335909
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
For traceback argument printing, we want to print at most 10
words, then print "..." if there are still more args and/or
fields. The current code has off-by-one error that for 11
non-aggregate typed args, it prints the first 10 but without the
"...". Also, for aggregate-typed args, in some cases it may print
an extra "..." when there is actually no more fields.
The problem for this is that visitType return false (meaning not
to continue visiting) if it reaches the limit anywhere during the
recursive visit. It doesn't distinguish whether it has printed
anything for the current arg. If it reaches the limit before it
prints anything, it means that we're visiting the extra arg/field,
so the caller should print "..." and stop. If it prints
something then reaches the limit, however, the caller should keep
going, and only print "..." at the next iteration when there is
actually an extra arg/field. This CL does so.
Fixes#47159.
Change-Id: I93fc25b73ada2b5a98df780c45e5b0c9565dc2fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/334710
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: I523d5fd810b82154a204670d46fc250a0fc66791
Reviewed-on: https://go-review.googlesource.com/c/go/+/333849
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 326211 a change was made to switch "go.map.zero" symbols from
non-pkg DUPOK symbols to hashed symbols. The intent of this change was
ensure that in cases where there are multiple competing go.map.zero
symbols feeding into a link, the largest map.zero symbol is selected.
The change was buggy, however, and resulted in duplicate symbols in
the final binary (see bug cited below for details). This duplication
was relatively benign for linux/ELF, but causes duplicate definition
errors on Windows.
This patch switches "go.map.zero" symbols back from hashed symbols to
non-pkg DUPOK symbols, and updates the relevant code in the loader to
ensure that we do the right thing when there are multiple competing
DUPOK symbols with different sizes.
Fixes#47185.
Change-Id: I8aeb910c65827f5380144d07646006ba553c9251
Reviewed-on: https://go-review.googlesource.com/c/go/+/334930
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: I7acda22c01c5350ebf5ddabb1c12af96d368de5d
GitHub-Last-Rev: 3e5c022f87
GitHub-Pull-Request: golang/go#47160
Reviewed-on: https://go-review.googlesource.com/c/go/+/334229
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Beginner and intermediate Go users periodically use TestMain when
requirements do not necessitate TestMain (exceeding least-mechanism
design). This commit expands package testing's documentation to convey
that the TestMain feature itself is somewhat low-level and potentially
unsuitable for casual testing where ordinary test functions would
suffice.
Fixes#42161
Updates #44200
Change-Id: I91ba0b048c3d6f79110fe8f0fbb58d896edca366
Reviewed-on: https://go-review.googlesource.com/c/go/+/334649
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
I neglected to run the 'longtest' builder, and the tests
that cover the error message changed in CL 332573 apparently
do not run in short mode.
Updates #36460
Updates #42661
Change-Id: I53500ddaca8ac9f0dfaab538923b3c9a4f71665e
Reviewed-on: https://go-review.googlesource.com/c/go/+/334889
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The compiler is relying on Sym.Def field to lookup symbol package in
DotImportRefs map. But the Sym.Def field is clear whenever the compiler
finish processing a file. If the dot import happen in file A, then the
redeclaration happen in file B, then the symbol lookup in file B will
see a nil Sym.Def, that cause the compiler crashes.
To fix this, we can interate over DotImportRefs and check for matching
symbol name and return the corresponding package. Though this operation
can be slow, but it only happens in invalid program, when printing error
message, so it's not worth to optimize it further.
Fixes#47201
Change-Id: I4ca1cb0a8e7432b19cf71434592a4cbb58d54adf
Reviewed-on: https://go-review.googlesource.com/c/go/+/334589
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For #46229
Change-Id: I54d01d90f2b0c892d76121f1350c0e8cf4b2772f
Reviewed-on: https://go-review.googlesource.com/c/go/+/334729
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Per discussion at #46229 we are taking the "loong64" GOARCH value for
the upcoming LoongArch 64-bit port. It is not clear whether any 32-bit
non-bare-metal userland will exist for LoongArch, so only reserve
"loong64" for now.
Change-Id: I97d262b4ab68ff61c22ccf83e26baf70eefd568d
GitHub-Last-Rev: ecdd8c53bd
GitHub-Pull-Request: golang/go#47129
Reviewed-on: https://go-review.googlesource.com/c/go/+/333909
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
The /doc link is currently a redirect (CL 334389),
but I plan to update it soon with a more detailed guide.
Updates #36460
Change-Id: I9e4a47ad0c8bcb7361cfa3e5b9d07ad241b13ba6
Reviewed-on: https://go-review.googlesource.com/c/go/+/332573
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
The initial "branch: master" configuration was inherited from when
the release-branch.go1.17 branch was branched off the master branch.
Update the "branch" key, otherwise a modern git-codereview will mail
CLs to the wrong branch.
We can set "parent-branch" so that 'git codereview sync-branch' works
to merge latest master into release-branch.go1.17, something we want
to do for subsequent RCs, maybe up to the final release. (At some point
the release freeze will end and tree will open for Go 1.18 development,
so we'll be switching to using cherry-picks only. Having parent-branch
will not be useful then, but I think harmless.)
Change-Id: I36ab977eaeb52bc0a84cc59e807572054f54c789
Reviewed-on: https://go-review.googlesource.com/c/go/+/334376
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
For #46366
Change-Id: Ie9735027a3c4c0f4a604df30ca4d64dcdc62b45a
Reviewed-on: https://go-review.googlesource.com/c/go/+/334375
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: Idc207e34c54b9bff0ae59348e4bc97474b1c11d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/334254
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
a98589711d crypto/tls: test key type when casting
cfbd73ba33 doc/go1.17: editing pass over the "Compiler" section
ab4085ce84 runtime/pprof: call runtime.GC twice in memory profile test
Change-Id: I5b19d559629353886752e2a73ce8f37f983772df
When casting the certificate public key in generateClientKeyExchange,
check the type is appropriate. This prevents a panic when a server
agrees to a RSA based key exchange, but then sends an ECDSA (or
other) certificate.
Fixes#47143
Fixes CVE-2021-34558
Thanks to Imre Rad for reporting this issue.
Change-Id: Iabccacca6052769a605cccefa1216a9f7b7f6aea
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1116723
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Reviewed-by: Katie Hockman <katiehockman@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/334031
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This change fixes#46500 by working around #45315 which may cause freed
objects to get missed in the heap profile published for the test.
By calling runtime.GC one more time this change ensures that all freed
objects are accounted for.
Fixes#46500.
Change-Id: Iedcd0b37dbaffa688b0ff8631a8b79f7a1169634
Reviewed-on: https://go-review.googlesource.com/c/go/+/333549
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Instead of hard failing on a single bad record, filter the bad records
and return anything valid. This only applies to the methods which can
return multiple records, LookupMX, LookupNS, LookupSRV, and LookupAddr.
When bad results are filtered out, also return an error, indicating
that this filtering has happened.
Updates #46241Fixes#46979
Change-Id: I6493e0002beaf89f5a9795333a93605abd30d171
Reviewed-on: https://go-review.googlesource.com/c/go/+/332549
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Update comment cause gc/select.go has been moved to walk/select.go and gc/reflect.go has been moved to reflectdata/reflect.go
Change-Id: I6894527e1e9dbca50ace92a51bf942f9495ce88c
GitHub-Last-Rev: 6d6a447144
GitHub-Pull-Request: golang/go#45976
Reviewed-on: https://go-review.googlesource.com/c/go/+/317191
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Michael Pratt <mpratt@google.com>
I'm not sure why blank was special-cased here before, but it's
wrong. Blank is a non-exported identifier, and writing it out without
package-qualification can result in linker symbol collisions.
Fixes#47087.
Change-Id: Ie600037c8e54e3d4fdaeec21e2ca212badbd830b
Reviewed-on: https://go-review.googlesource.com/c/go/+/333163
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Now that symfmt is simpler, we can simply manually inline it into
sconv. Importantly, this allows us to avoid allocating a buffer +
writing a string + re-interning it when we don't need to qualify the
identifier.
Passes toolstash -cmp.
Updates #47087.
Change-Id: I47b57aef22301ba242556a645346f478f0c1a7d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/333162
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The logic in symfmt for deciding how to package-qualify an identifier
is easily refactored into a separate function, loosely similar to
go/types.Qualifier's API.
Passes toolstash -cmp.
Updates #47087.
Change-Id: Ib3e7cc35a6577dc28df8eca79ba3457c48168e86
Reviewed-on: https://go-review.googlesource.com/c/go/+/333161
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
