The cryptographic checksums operate in blocks of 64 or 128 bytes,
which means that the last 128 bytes or so of the input may be encoded
in its original (plaintext) form as part of the state.
Document this so users do not falsely assume that the encoded state
carries no reversible information about the input.
Change-Id: I823dbb87867bf0a77aa20f6ed7a615dbedab3715
Reviewed-on: https://go-review.googlesource.com/77372
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 45412 started hiding autogenerated wrapper functions from call
stacks so that call stack semantics better matched language semantics.
This is based on the theory that the wrapper function will call the
"real" function and all the programmer knows about is the real
function.
However, this theory breaks down in two cases:
1. If the wrapper is at the top of the stack, then it didn't call
anything. This can happen, for example, if the "stack" was actually
synthesized by the user.
2. If the wrapper panics, for example by calling panicwrap or by
dereferencing a nil pointer, then it didn't call the wrapped
function and the user needs to see what panicked, even if we can't
attribute it nicely.
This commit modifies the traceback logic to include the wrapper
function in both of these cases.
Fixes#22231.
Change-Id: I6e4339a652f73038bd8331884320f0b8edd86eb1
Reviewed-on: https://go-review.googlesource.com/76770
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The Go compiler assumes that pointers escape when passed into assembly
functions. To override this behavior we can annotate assembly functions
with go:noescape, telling the compiler that we know pointers do not
escape from it.
By annotating the assembly functions in the s390x P256 code in this way
we enable more variables to be allocated on the stack rather than
the heap, reducing the number of heap allocations required to execute
this code:
name old alloc/op new alloc/op delta
SignP256 3.66kB ± 0% 2.64kB ± 0% -27.95% (p=0.008 n=5+5)
VerifyP256 4.46kB ± 0% 1.23kB ± 0% -72.40% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
SignP256 40.0 ± 0% 31.0 ± 0% -22.50% (p=0.008 n=5+5)
VerifyP256 41.0 ± 0% 24.0 ± 0% -41.46% (p=0.008 n=5+5)
Change-Id: Id526c30c9b04b2ad79a55d76cab0e30cc8d60402
Reviewed-on: https://go-review.googlesource.com/66230
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Split typecheckrange into two, separating the bigger chunk of code that
takes care of the range expression. It had to sometimes exit early,
which was done via a goto in the larger func. This lets us simplify many
declarations and the flow of the code. While at it, also replace the
toomany int with a bool.
In the case of walkselect, split it into two funcs too since using a
defer for all the trailing work would be a bit much. It also lets us
simplify the declarations and the flow of the code, since now
walkselectcases has a narrower scope and straightforward signature.
Also replace the gotos in typecheckaste with a lineno defer.
Passes toolstash -cmp on std cmd.
Change-Id: Iacfaa0a34c987c44f180a792c473558785cf6823
Reviewed-on: https://go-review.googlesource.com/72374
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
If people are interested in contributing to Go, but not sure what
change they'd like to make just yet, we can point them to the scratch
repo, so they can go through the process of submitting and merging
something now, and make more useful contributions later.
My evidence that sending people to the scratch repo would encourage
future contributions is that a number of people who went through the
workshop at Gophercon have continued to send CL's after submitting to
the scratch repo, even though I doubt they planned to before going
through the workshop.
Change-Id: Ieb48415773c0ee7dc400f8bf6f57f752eca8eeb5
Reviewed-on: https://go-review.googlesource.com/49970
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This test fails on 1.9.2, but is ok on tip.
CL 77331 has both the 1.9.2 fix and this test, and is on the 1.9 release branch.
This CL is just the test, and is on HEAD. The buggy code doesn't exist on tip.
Update #22683
Change-Id: I04a24bd6c2d3068e18ca81da3347e2c1366f4447
Reviewed-on: https://go-review.googlesource.com/77332
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 60410 fixes a bug in reflect that allows assignments to an embedded
field of a pointer to an unexported struct type.
This breaks the json package because unmarshal is now unable to assign
a newly allocated struct to such fields.
In order to be consistent in the behavior for marshal and unmarshal,
this CL changes both marshal and unmarshal to always ignore
embedded pointers to unexported structs.
Fixes#21357
Change-Id: If62ea11155555e61115ebb9cfa5305caf101bde5
Reviewed-on: https://go-review.googlesource.com/76851
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
GitHub has defined a set of standard meta files to include with projects
hosted on GitHub. According to the GitHub Insights Community page for
go project the only one missing is the code of conduct.
Go has a code of conduct on it's website and we should link to it in the
prescribed `.github/CODE_OF_CONDUCT.md` so that people can find it in
the standard location on GitHub. This would be consistent with the
contribution guidelines that are linked to in `.github/CONTRIBUTING.md`.
Ref: https://help.github.com/articles/adding-a-code-of-conduct-to-your-project/Fixes#22685
Change-Id: Ie89aa39d3df741d7d6ed2dba5c8ba3d0e0dbf618
Reviewed-on: https://go-review.googlesource.com/77231
Reviewed-by: Gabriel Aszalos <gabriel.aszalos@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also, with this change, error locations don't print absolute positions
in [] brackets following positions relative to line directives. To get
the absolute positions as well, specify the -L flag.
Fixes#22660.
Change-Id: I9ecfa254f053defba9c802222874155fa12fee2c
Reviewed-on: https://go-review.googlesource.com/77090
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
cmd/cover rewrites Go source code to add coverage annotations.
The approach to date has been to parse the code to AST, analyze it,
rewrite the AST, and print it back out. This approach fails to preserve
line numbers in the original code and has a very difficult time with
comments, because go/printer does as well.
This CL changes cmd/cover to decide what to modify based on the
AST but to apply the modifications as purely textual substitutions.
In this way, cmd/cover can be sure it never adds or removes a newline
character, nor a comment, so all line numbers and comments are
preserved.
This also allows us to emit a single //line comment at the beginning
of the translated file and have the compiler report errors with
correct line numbers in the original file.
Fixes#6329.
Fixes#15757.
Change-Id: Ia95f6f894bb498e80d1f91fde56cd4a8009d7f9b
Reviewed-on: https://go-review.googlesource.com/77150
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Per discussion with David Chase, need to check GOSSAHASH$n
for increasing n until one is missing. Also if GSHS_LOGFILE is set,
the compiler writes to that file, so arrange never to cache in that case.
Change-Id: I3931b4e296251b99abab9bbbbbdcf94ae8c1e2a6
Reviewed-on: https://go-review.googlesource.com/77111
Reviewed-by: David Chase <drchase@google.com>
It's nice that
go build -gcflags=-m errors
go build -gcflags=-m errors
uses the cache for the second command.
Even nicer is to make the second command
print the same output as the first command.
Fixes#22587.
Change-Id: I64350839f01c86c9a095d9d22f6924cd7a0b9105
Reviewed-on: https://go-review.googlesource.com/77110
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Another one that is possible thanks to the new -trimprefix stringer
flag.
The only subtle difference is that, in the previous version, some values
such as TUNSAFEPTR were stringified as "TUNSAFEPTR" instead of
"UNSAFEPTR". The new String method is always consistent in removing the
"T" prefix.
Passes toolstash -cmp on std cmd.
Change-Id: I68407f391795403dfcbbfa68c813018c0235bbb5
Reviewed-on: https://go-review.googlesource.com/77250
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Since the slice of names is almost exactly the same as what stringer is
already generating for us.
Passes toolstash -cmp on std cmd.
Change-Id: I3f1e95efc690c0108236689e721627f00f79a461
Reviewed-on: https://go-review.googlesource.com/77190
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
This allows better precision and (the motivation) empty strings to
be handled correctly. With that in place tests for the behaviour of
empty name constraints can be added.
Also fixes a compatibility issue with NSS. See #22616.
Fixes#22616
Change-Id: I5139439bb58435d5f769828a4eebf8bed2d858e8
Reviewed-on: https://go-review.googlesource.com/74271
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 76873 added TestGoTestJSON. However, this test
is only succeeding on SMP machines.
This change skips TestGoTestJSON on uniprocessor machines.
Fixes#22665.
Change-Id: I3989d3331fb71193a25a3f0bbb84ff3e1b730890
Reviewed-on: https://go-review.googlesource.com/77130
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Sometimes getmac lists many interfaces for the same MAC address,
while Interfaces returns only single name for that address. Adjust
the test to ignore the names that are not returned by the Interfaces.
Fixes#21027
Change-Id: I08d98746a7c669f2d730dba2da36e07451a6f405
Reviewed-on: https://go-review.googlesource.com/59411
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
If you run
go test -coverpkg=all fmt
one possible interpretation is that you want coverage for all the
packages involved in the fmt test, not all the packages in the world.
Because coverpkg was previously defined as a list of packages
to be loaded, however, it meant all packages in the world.
Now that the go command has a concept of package notation
being used as a matching filter instead of a direct enumeration,
apply that to -coverpkg, so that -coverpkg=all now has the
more useful filter interpretation.
Fixes#10271.
Fixes#21283.
Change-Id: Iddb77b21ba286d3dd65b62507af27e244865072d
Reviewed-on: https://go-review.googlesource.com/76876
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It's easy to merge the coverage profiles from the
multiple executed tests, so do that.
Also ensures that at least an empty coverage profile
is always written.
Fixes#6909.
Fixes#18909.
Change-Id: I28b88e1fb0fb773c8f57e956b18904dc388cdd82
Reviewed-on: https://go-review.googlesource.com/76875
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is already documented in the time.Time package
but people might not look there.
Followup to CL 76872, which I submitted accidentally
(Gerrit has placed the Submit button next to Reply again.)
Change-Id: Ibfd6a4da241982d591a8698282a0c15fe9f2e775
Reviewed-on: https://go-review.googlesource.com/77010
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL finally adds one of our longest-requested cmd/go features:
a way for test-running harnesses to access test output in structured form.
In fact the structured json output is more informative than the text
output, because the output from multiple parallel tests can be
interleaved as it becomes available, instead of needing to wait for
the previous test to finish before showing any output from the
next test.
See CL 76872 for the conversion details.
Fixes#2981.
Change-Id: I749c4fc260190af9fe633437a781ec0cf56b7260
Reviewed-on: https://go-review.googlesource.com/76873
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also add cmd/internal/test2json, the actual implementation,
which will be called directly from cmd/go in addition to being
a standalone command (like cmd/buildid and cmd/internal/buildid).
For #2981.
Change-Id: I244ce36d665f424bbf13f5ae00ece10b705d367d
Reviewed-on: https://go-review.googlesource.com/76872
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In past releases, whether test output appears on stdout or stderr
has varied depending on exactly how go test was invoked and
also (indefensibly) on the number of CPUs available.
Standardize on standard output for all test output.
This is easy to explain and makes go test | go tool test2json work nicely.
Change-Id: I605641213fbc6c7ff49e1fd38a0f732045a8383d
Reviewed-on: https://go-review.googlesource.com/76871
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Now possible, since stringer just got the -trimprefix flag added.
While at it, simplify a few Op stringifications since we can now use %v,
and no longer have to worry about o<len(opnames).
Passes toolstash -cmp on std cmd.
Fixes#15462.
Change-Id: Icdcde0b0a5eb165d18488918175024da274f782b
Reviewed-on: https://go-review.googlesource.com/76790
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dave Cheney <dave@cheney.net>
The old code only worked for double-quoted strings, and only checked
that the end of the literal value was \n". This worked most of the time,
except for some strings like "foo\\n", which doesn't actually translate
into a trailing newline when unquoted.
To fix this, unquote the string first and look for a real newline at the
end of it. Ignore errors, as we don't have anything to do with string
literals using back quotes.
Fixes#22613.
Change-Id: I7cf96916dd578b7068216c2051ec2622cce0b740
Reviewed-on: https://go-review.googlesource.com/76194
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
See CL 40291. ctx.Err() is defined to only return non-nil exactly
when ctx.Done() returns a closed channel.
Change-Id: I12f51d8c42228f759273319b3ccc28012cb9fc73
Reviewed-on: https://go-review.googlesource.com/71310
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This means {Read,Write}Msg{UDP,IP} now work on windows.
Fixes#9252
Change-Id: Ifb105f9ad18d61289b22d7358a95faabe73d2d02
Reviewed-on: https://go-review.googlesource.com/76393
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
A header line with leading whitespaces is not valid in HTTP as per
RFC7230. This change ignores these invalid lines in ReadMIMEHeader.
Updates #22464
Change-Id: Iff9f00380d28a9617a55ff7888a76fba82001402
Reviewed-on: https://go-review.googlesource.com/75350
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
this change removes the state field from the lexer,
because it's only used by the run method and can be
replaced with a local variable
Change-Id: Ib7a90ab6e9a894716cba2c7d9ed71bf2ad1240c0
Reviewed-on: https://go-review.googlesource.com/47338
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This changes improves the ConstantTimeByteEq and ConstantTimeEq
primitives to both simplify them and improve their performance.
Also, since there were no benchmarks for this package before,
this change adds benchmarks for ConstantTimeByteEq,
ConstantTimeEq, and ConstantTimeLessOrEq.
benchmarks on darwin/amd64, 10 runs on old vs new code:
name old time/op new time/op delta
ConstantTimeByteEq-4 2.28ns ±16% 1.53ns ± 2% -33.09% (p=0.000 n=10+9)
ConstantTimeEq-4 2.77ns ±10% 1.51ns ± 2% -45.59% (p=0.000 n=10+9)
ConstantTimeLessOrEq-4 1.52ns ± 8% 1.50ns ± 2% ~ (p=0.866 n=9+9)
Change-Id: I29b8cbcf158e1f30411720db82d38b4ecd166b15
Reviewed-on: https://go-review.googlesource.com/45310
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
cmd/go/internal/work.Builder.updateBuildID left a file opened.
But opened files cannot be deleted on Windows, so cmd/go just
leaves these files in %TMP% directory.
Close the file so deletion can succeed.
Fixes#22650
Change-Id: Ia3ea62f6ec7208d73972eae2e17fb4a766407914
Reviewed-on: https://go-review.googlesource.com/76810
Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The former is more succinct and readable.
Change-Id: Ic249d1261a705ad715aeb611c70c7fa91db98254
Reviewed-on: https://go-review.googlesource.com/76830
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix a buglet in the go command support for 'go test -n': check for
nil output buffer in action routine.
Fixes#22644
Change-Id: I2566e3bb3d53d0324c4ddd6fec5d30224bf290df
Reviewed-on: https://go-review.googlesource.com/76710
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The lastPos field used in the past to track the line number of a token.
it's irrelevant anymore, and we can remove it.
Change-Id: I42c0bf55e884b79574a7da4926489f2d77618cd0
Reviewed-on: https://go-review.googlesource.com/49591
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I added this in CL 76024 in order to do compile+link+run. This
is no longer necessary after CL 76551, which changed it back to
"go run". Remove it.
Change-Id: Ifa744d4b2f73f33cad056b24051821e43638cc7f
Reviewed-on: https://go-review.googlesource.com/76690
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The linker will refuse to work on objects larger than
2e9 bytes (see issue #9862 for why).
With this change, the compiler gives a useful error
message explaining this, instead of leaving it to the
linker to give a cryptic message later.
Fixes#1700.
Change-Id: I3933ce08ef846721ece7405bdba81dff644cb004
Reviewed-on: https://go-review.googlesource.com/74330
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The recent vendored pprof update broke the iOS builders. The issue was
reported and patched upstream. Re-vendor the internal pprof copy.
Updates vendored pprof to commit 9e20b5b106e946f4cd1df94c1f6fe3f88456628d
from github.com/google/pprof (2017-11-08).
Fixes#22612
Change-Id: I74c46c75e92ce401e605c55e27d8545c0d66082c
Reviewed-on: https://go-review.googlesource.com/76651
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Even if the go command can see that the target is up-to-date
an mtime-based build system invoking the go command may not
be able to tell. Update the mtime to make clear that the target is
up-to-date, and also to hide exactly how smart the go command
is or is not. This keeps users (and programs) from depending on
the exact details of the go command's staleness determination.
Without this I believe we will get a stream of (completely reasonable)
bug reports that "go install (or go test -c) did not update the binary
after I trivially changed the source code or touched a source file".
Change-Id: I920e4aaed2a57319e3c0c37717f872bc059e484e
Reviewed-on: https://go-review.googlesource.com/76590
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
We want test caching to work even for people with scripts
that set a non-default test timeout. But then that raises the
question of what to do about runs with different timeouts:
is a cached success with one timeout available for use when
asked to run the test with a different timeout?
This CL answers that question by saying that the timeout applies
to the overall execution of either running the test or displaying
the cached result, and displaying a cached result takes no time.
So it's always OK to record a cached result, regardless of timeout,
and it's always OK to display a cached result, again regardless of timeout.
Fixes#22633.
Change-Id: Iaef3602710e3be107602267bbc6dba9a2250796c
Reviewed-on: https://go-review.googlesource.com/76552
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It has always been problematic that there was no way to specify
tool flags that applied only to the build of certain packages;
it was only to specify flags for all packages being built.
The usual workaround was to install all dependencies of something,
then build just that one thing with different flags. Since the
dependencies appeared to be up-to-date, they were not rebuilt
with the different flags. The new content-based staleness
(up-to-date) checks see through this trick, because they detect
changes in flags. This forces us to address the underlying problem
of providing a way to specify per-package flags.
The solution is to allow -gcflags=pattern=flags, which means
that flags apply to packages matching pattern, in addition to the
usual -gcflags=flags, which is now redefined to apply only to
the packages named on the command line.
See #22527 for discussion and rationale.
Fixes#22527.
Change-Id: I6716bed69edc324767f707b5bbf3aaa90e8e7302
Reviewed-on: https://go-review.googlesource.com/76551
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It needs to refer to packages, so it can no longer be in cfg.
No semantic changes here.
Can now be unexported, so that was a net win anyway.
Change-Id: I58bf6cdcd435e6e019291bb8dcd5d5b7f1ac03a3
Reviewed-on: https://go-review.googlesource.com/76550
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
In the current implementation, it is possible for a client to
continuously send warning alerts, which are just dropped on the floor
inside readRecord.
This can enable scenarios in where someone can try to continuously
send warning alerts to the server just to keep it busy.
This CL implements a simple counter that triggers an error if
we hit the warning alert limit.
Fixes#22543
Change-Id: Ief0ca10308cf5a4dea21a5a67d3e8f6501912da6
Reviewed-on: https://go-review.googlesource.com/75750
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
