When reading along the article, the extra code added in the final
version is not explained. The main function calls flag.Parse(), for
example, which will cause an error, unless the readers looks at the
entirety of final.go to see the import added.
The file shown to the users no longer has the extra flags. The testing
code is now in a patch that gets applied to final.go in order to create
final-test.go. This is the file that will be used to test the code,
matching final.go as much as possible.
Change-Id: I022f5f6c88e107c8ba5623661d74a8d260d05266
Reviewed-on: https://go-review.googlesource.com/11061
Reviewed-by: Andrew Gerrand <adg@golang.org>
Suggested by mdempsky (see also issue #11161).
Change-Id: I1ab28febe19b7a092029499015073ce8749b4d99
Reviewed-on: https://go-review.googlesource.com/10960
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These were found by grepping the comments from the go code and feeding
the output to aspell.
Change-Id: Id734d6c8d1938ec3c36bd94a4dbbad577e3ad395
Reviewed-on: https://go-review.googlesource.com/10941
Reviewed-by: Aamir Khan <syst3m.w0rm@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reflect the process changes where AUTHORS and CONTRIBUTORS
files are updated automatically based on commit logs
and Google committers no longer need to do it manually
on the first contributors.
The documentation update will help to avoid requests to be
added from new contributors.
Change-Id: I67daae5bd21246cf79fe3724838889b929bc5e66
Reviewed-on: https://go-review.googlesource.com/10824
Reviewed-by: Rob Pike <r@golang.org>
I think it's worth mentioning.
But the final decision is up to you.
Change-Id: I3959132600ecc554988524ede73a7f6e8eac8353
Reviewed-on: https://go-review.googlesource.com/10551
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
- no "visible" change to spec but for updated date
- retired several outdated TODO items
- filed non-urgent issues 10953, 10954, 10955 for current TODOs
Change-Id: If87ad0fb546c6955a6d4b5801e06e5c7d5695ea2
Reviewed-on: https://go-review.googlesource.com/10382
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL removes the remaining visible uses of the "architecture letter" concept.
(They are no longer in tool names nor in source directory names.)
Because the architecture letter concept is now gone, delete GOCHAR
from "go env" output, and change go/build.ArchChar to return an
error always.
The architecture letter is still used in the compiler and linker sources
as a clumsy architecture enumeration, but that use is not visible to
Go users and can be cleaned up separately.
Change-Id: I4d97a38f372003fb610c9c5241bea440d9dbeb8d
Reviewed-on: https://go-review.googlesource.com/10289
Reviewed-by: Rob Pike <r@golang.org>
This is a duplicate of CL 9491.
That CL broke the build due to pprof shortcomings
and was reverted in CL 9565.
CL 9623 fixed pprof, so this can go in again.
Fixes#10659.
Change-Id: If470fc90b3db2ade1d161b4417abd2f5c6c330b8
Reviewed-on: https://go-review.googlesource.com/10212
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The spec explains later in the "Operator precedence" section that *
has a higher precedence than +, but the current production rule
requires that "1 + 2 * 3" be parsed as "(1 + 2) * 3", instead of the
intended "1 + (2 * 3)".
The new production rule better matches cmd/internal/gc/go.y's grammar:
expr:
uexpr
| expr LOROR expr
| expr LANDAND expr
| ...
Fixes#10151.
Change-Id: I13c9635d6ddf1263cafe7cc63e68f3e5779e24ba
Reviewed-on: https://go-review.googlesource.com/9163
Reviewed-by: Robert Griesemer <gri@golang.org>
In the Slices section of Effective Go, the os package's File.Read
function is used as an example. Unfortunately the function signature
does not match the function's code in the example, nor the os package's
documentation. This change updates the function signature to match
the os package and the pre-existing function code.
Change-Id: Iae9f30c898d3a1ff8d47558ca104dfb3ff07112c
Reviewed-on: https://go-review.googlesource.com/9845
Reviewed-by: Rob Pike <r@golang.org>
Change-Id: I70dfc2bad13c513c376c7c41058774b40af73dce
Reviewed-on: https://go-review.googlesource.com/9775
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Solaris, like Windows, NetBSD and OpenBSD, uses macros for stdin, stdout,
and stderr. Cgo can't access them without getters/setters written in
C. Because of this we disable affected tests like for the other platforms.
Updates #10715.
Change-Id: I3d33a5554b5ba209273dbdff992925a38a281b42
Reviewed-on: https://go-review.googlesource.com/8264
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This reverts commit c26fc88d56.
This broke pprof. See the comments at 9491.
Change-Id: Ic99ce026e86040c050a9bf0ea3024a1a42274ad1
Reviewed-on: https://go-review.googlesource.com/9565
Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Package time already has enough inherently flaky tests covering its
behavior. No need for more of them.
Fixes#10632.
Change-Id: I1229e9fcc2e28ba2c9b0b79f73638e35dbbe8bbf
Reviewed-on: https://go-review.googlesource.com/9517
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The heap statistics were only written if asked for a profile with debug > 0,
but that also prints a stack trace for each profile line, which is comparatively
much noisier. The statistics are short enough and separate enough
(they only appear at the end) and useful enough that we can print them
always.
This means that people using -test.memprofile in tests will get a memory
profile with statistics included now. Pprof won't care, but if people care to
look, the numbers will be there.
This avoids the need for hacks like using -memprofilerate=1 to find
the number of allocations.
Change-Id: I10a4f593403d0315aad11b37c6e554b734caa73f
Reviewed-on: https://go-review.googlesource.com/9491
Reviewed-by: David Chase <drchase@google.com>
github.com/kr/goven says it's deprecated and anyway
it would be preferable to point users to a standard Go tool.
Change-Id: Iac4a0d13233604a36538748d498f5770b2afce19
Reviewed-on: https://go-review.googlesource.com/8969
Reviewed-by: Minux Ma <minux@golang.org>
This avoids a race condition with go1.go wanting to examine files in
the current directory with filepath.Walk(".", walkFn).
Fixes#10497.
Change-Id: I2159f40a08d1a768195dbb7ea3c27e38cf9740bb
Reviewed-on: https://go-review.googlesource.com/9110
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The tests in doc/progs appear to have been originally written
for use with the old test driver. At some later point,
they acquired their own test driver.
Both ran tests in serial.
This CL rewrites the current test driver in Go,
runs tests concurrently, and cleans up
historical artifacts from the old drivers.
The primary motivation is to speed up all.bash.
On my laptop, using tip, this CL reduces doc/progs test
wall time from 26s to 7s. The savings will remain
even when the compiler gets faster. Using Go 1.4,
this CL reduces test wall time from 15s to 4s.
Change-Id: Iae945a8490222beee76e8a2118a0d7956092f543
Reviewed-on: https://go-review.googlesource.com/8410
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
to map element keys
Composite literals containing element values that are themselves composite
literals may leave away the element's literal types if they are identical
to the enclosing composite literal's element type.
(http://golang.org/ref/spec#Composite_literals)
When we made this change, we forgot to apply the analogous rule to map
literal keys. This change generalizes that rule. Added more examples,
including one showing the recursive application of the elision rules.
This is a fully backward-compatible language change. It was discussed
some time back.
Fixes#8589.
To be submitted once all compilers accept the extension.
Change-Id: I4d45b64b5970f0d5501572945d5a097e64a9458b
Reviewed-on: https://go-review.googlesource.com/2591
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
While we're here, also fix two HTML issues.
Fixes#9235.
Change-Id: I6e2f50931c0f387881271484a726ac2308518cf4
Reviewed-on: https://go-review.googlesource.com/7602
Reviewed-by: Rob Pike <r@golang.org>
When printing the type of the function there was no newline printed in
case of unexpected type.
Change-Id: I5946413f0864f712a1b955f488b436793018e0e0
Reviewed-on: https://go-review.googlesource.com/7480
Reviewed-by: Minux Ma <minux@golang.org>
- Fixed term in preceding section: submitted -> merged.
- Clear transitions between web sites.
- Clarify "types" of G Accounts.
- Less verbose "Configure Git" instructions. [l10n]
- Google uses the term "sign in".
- Mention .gitcookie file created.
Update "Register with Gerrit".
- Link directly to gerrit /login/ .
HTML
- Removed non-ascii "hidden characters".
- Encoded some & and >.
Change-Id: I0d99102def6b32e09b8e42fa40e20227ad5e7568
Reviewed-on: https://go-review.googlesource.com/5892
Reviewed-by: Andrew Gerrand <adg@golang.org>
- added a new field ast.EmptyStmt.Implicit to indicate explicit
or implicit semicolon
- fix ast.EmptyStmt.End() accordingly
- adjusted parser and added test case
Fixes#9979.
Change-Id: I72b0983b3a0cabea085598e1bf6c8df629776b57
Reviewed-on: https://go-review.googlesource.com/5720
Reviewed-by: Russ Cox <rsc@golang.org>
e.g. ·Name instead of package·Name for automatic stack map to
be applied from its Go prototype.
The underlying reason is that liblink look up name with suffix
".args_stackmap" for the stackmap coming from its Go prototype,
but all the Go functions are named "".Name as this stage. Thus
an assembly function named package·Name will never find its
stackmap, which is named "".package.Name.args_stackmap.
Perhaps cmd/vet should give a warning for this.
Change-Id: I10d154a73ec969d574d20af877f747424350fbd1
Reviewed-on: https://go-review.googlesource.com/2588
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Only documentation / comment changes. Update references to
point to golang.org permalinks or go.googlesource.com/go.
References in historical release notes under doc are left as is.
Change-Id: Icfc14e4998723e2c2d48f9877a91c5abef6794ea
Reviewed-on: https://go-review.googlesource.com/4060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#9756.
Change-Id: If4ee6fe10f8f90294ff9c5e7480371494094b111
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/3740
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
These are no longer used by anything.
Change-Id: I50c971418b07cafc983242833a196ba2028a2723
Reviewed-on: https://go-review.googlesource.com/3603
Reviewed-by: Rob Pike <r@golang.org>
This manually reverts 555da73 from #6372 which implies a
minimum FreeBSD version of 8-STABLE.
Updates docs to mention new minimum requirement.
Fixes#9627
Change-Id: I40ae64be3682d79dd55024e32581e3e5e2be8aa7
Reviewed-on: https://go-review.googlesource.com/3020
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The existing go code document did not link to the GOPATH documentation.
This will link to it, in hopes of making it more discoverable.
Change-Id: Ie4ded2fdce08f412e4acbcc93acdd76f5791b84a
Reviewed-on: https://go-review.googlesource.com/2265
Reviewed-by: Andrew Gerrand <adg@golang.org>
Mostly I need to tickle the builders, since I'm working on the
dashboard builders right now.
Change-Id: I833fc22bc942758a58791ed038634cdd812f5411
Reviewed-on: https://go-review.googlesource.com/2261
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Vitess and protobuf has moved to GitHub; update the links.
Change-Id: I2d90bde1a7f2b590c8b7b08ce73d6faa13b51da0
Reviewed-on: https://go-review.googlesource.com/2166
Reviewed-by: Andrew Gerrand <adg@golang.org>
These are the references that affect current Go users.
I left intact references in older release notes;
we can figure out what to do with them later.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/186140043
Conflicts:
doc/go1.4.html
Change-Id: I1032686f2b3ac6dacaf8f114b8c35cdf221330ca
Language clarification.
The existing rules for selector expressions imply
automatic dereferencing of pointers to struct fields.
They also implied automatic dereferencing of selectors
denoting methods. In almost all cases, such automatic
dereferencing does indeed take place for methods but the
reason is not the selector rules but the fact that method
sets include both methods with T and *T receivers; so for
a *T actual receiver, a method expecting a formal T
receiver, also accepts a *T (and the invocation or method
value expression is the reason for the auto-derefering).
However, the rules as stated so far implied that even in
case of a variable p of named pointer type P, a selector
expression p.f would always be shorthand for (*p).f. This
is true for field selectors f, but cannot be true for
method selectors since a named pointer type always has an
empty method set.
Named pointer types may never appear as anonymous field
types (and method receivers, for that matter), so this
only applies to variables declared of a named pointer
type. This is exceedingly rare and perhaps shouldn't be
permitted in the first place (but we cannot change that).
Amended the selector rules to make auto-deref of values
of named pointer types an exception to the general rules
and added corresponding examples with explanations.
Both gc and gccgo have a bug where they do auto-deref
pointers of named types in method selectors where they
should not:
See http://play.golang.org/p/c6VhjcIVdM , line 45.
Fixes#5769.
Fixes#8989.
LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/168790043
People viewing this locally will not have a /s/ on their local godoc.
tip.golang.org doesn't have one either.
Also change all golang.org links to https, to avoid mixed content
warnings when viewing https://golang.org/.
Fixes#9028.
LGTM=bradfitz, r
R=r, bradfitz
CC=adg, golang-codereviews
https://golang.org/cl/168250043
Add a short introductory section saying what most Go
programmers really need to know, which is that you
shouldn't have to read this document to understand
the behavior of your program.
LGTM=bradfitz, adg, tracey.brendan, iant, rsc, dsymonds
R=golang-codereviews, bradfitz, tracey.brendan, adg, iant, rsc, dsymonds
CC=golang-codereviews
https://golang.org/cl/158500043
Not a language change.
This is simply documenting the status quo which permits
builtin function names to be parenthesized in calls; e.g.,
both
len(s)
and
(((len)))(s)
are accepted by all compilers and go/types.
Changed the grammar by merging the details of BuiltinCall
with ordinary Calls. Also renamed the Call production to
Arguments which more clearly identifies that part of the
grammar and also matches better with its counterpart on
the declaration side (Parameters).
The fact that the first argument can be a type (for builtins)
or cannot be a type (for regular function calls) is expressed
in the prose, no need to make the grammar more complicated.
Fixes#9001.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, dave
CC=golang-codereviews
https://golang.org/cl/160570043
Move the release notes into an HTML file.
Start writing the text.
LGTM=rsc
R=golang-codereviews, bradfitz, kamil.kisiel, tracey.brendan, rsc
CC=golang-codereviews
https://golang.org/cl/161350043
Wrong article, one stylistic point that bothers someone (but not me).
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/156680043
The compatibility guideline needs to be clear about this even
though it means adding a clause that was not there from the
beginning. It has always been understood, so this isn't really
a change in policy, just in its expression.
LGTM=bradfitz, gri, rsc
R=golang-codereviews, bradfitz, gri, rsc
CC=golang-codereviews
https://golang.org/cl/162060043
Per suggestion from rsc as a result of the dicussion of
(abandoned) CL 153110044.
Fixes#7192.
LGTM=r, rsc, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/163050043
This new text won't stop the whining but it might focus the whining a little more.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/146680044
Not a language change.
Several inaccuracies were fixed:
1) A variable declaration may declare more than just one
variable.
2) Variable initialization follows the rules of assignments,
including n:1 assignments. The existing wording implied a 1:1
or n:n rule and generally was somewhat unspecific.
3) The rules for variable declarations with no types and
untyped initialization expressions had minor holes (issue 8088).
4) Clarified the special cases of assignments of untyped values
(we don't just have untyped constants, but also untyped bools,
e.g. from comparisons). The new wording is more direct.
To that end, introduced the notion of an untyped constant's
"default type" so that the same concept doesn't have to be
repeatedly introduced.
Fixes#8088.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/142320043
The existing spec rules on package initialization were
contradictory: They specified that 1) dependent variables
are initialized in dependency order, and 2) independent
variables are initialized in declaration order. This 2nd
rule cannot be satisfied in general. For instance, for
var (
c = b + 2
a = 0
b = 1
)
because of its dependency on b, c must be initialized after b,
leading to the partial order b, c. Because a is independent of
b but is declared before b, we end up with the order: a, b, c.
But a is also independent of c and is declared after c, so the
order b, c, a should also be valid in contradiction to a, b, c.
The new rules are given in form of an algorithm which outlines
initialization order explicitly.
gccgo and go/types already follow these rules.
Fixes#8485.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, gordon.klaus, adonovan
CC=golang-codereviews
https://golang.org/cl/142880043
The proposed text in the last CL had a comma that was missing from the submitted spec.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/150720043
This CL adjusts code referring to src/pkg to refer to src.
Immediately after submitting this CL, I will submit
a change doing 'hg mv src/pkg/* src'.
That change will be too large to review with Rietveld
but will contain only the 'hg mv'.
This CL will break the build.
The followup 'hg mv' will fix it.
For more about the move, see golang.org/s/go14nopkg.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/134570043
Preparation for fixing issue 5769 (method selectors
do not auto-dereference): The actual fix may require
some cleanups in all these sections, and syntactically,
method expressions and method values are selector
expressions. Moving them next to each other so that
it's easy to see the actual changes (next CL).
No content changes besides the section moves.
LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/132300043
The file is used by assembly code to define symbols like NOSPLIT.
Having it hidden inside the cmd directory makes it hard to access
outside the standard repository.
Solution: As with a couple of other files used by cgo, copy the
file into the pkg directory and add a -I argument to the assembler
to access it. Thus one can write just
#include "textflag.h"
in .s files.
The names in runtime are not updated because in the boot sequence the
file has not been copied yet when runtime is built. All other .s files
in the repository are updated.
Changes to doc/asm.html, src/cmd/dist/build.c, and src/cmd/go/build.go
are hand-made. The rest are just the renaming done by a global
substitution. (Yay sam).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/128050043
You talked me into it. This and other links should be updated
once the new import paths for the subrepos are established.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/124260043
Add a clause to the doc comment for the package and a
paragraph in the compatibility document explaining the
situation.
LGTM=bradfitz, adg, rsc
R=golang-codereviews, adg, bradfitz, minux, rsc
CC=golang-codereviews
https://golang.org/cl/129820043
Technically a language change, this cleanup is a completely
backward compatible change that brings the boolean results
of comma-ok expressions in line with the boolean results of
comparisons: they are now all untyped booleans.
The implementation effort should be minimal (less than a
handfull lines of code, depending how well factored the
implementation of comma-ok expressions is).
Fixes#8189.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/112320045
golang.org now serves HTTPS with a valid cert, so it's reasonable
that users should click through to the HTTPS versions of *.golang.org
and other known sites.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/112650043
I've found this very useful for generating
good test case lists for -short mode for
the disassemblers.
Fixes#7959.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/98150043
This is a fully backward-compatible language change.
There are not a lot of cases in the std library, but
there are some. Arguably this makes the syntax a bit
more regular - any trailing index variable that is _
can be left away, and there's some analogy to type
switches where the temporary can be left away.
Implementation-wise the change should be trivial as
it can be done completely syntactically. For instance,
the respective change in go/parser is a dozen lines
(see https://golang.org/cl/112970044 ).
Fixes#6102.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/104680043
The runtime has historically held two dedicated values g (current goroutine)
and m (current thread) in 'extern register' slots (TLS on x86, real registers
backed by TLS on ARM).
This CL removes the extern register m; code now uses g->m.
On ARM, this frees up the register that formerly held m (R9).
This is important for NaCl, because NaCl ARM code cannot use R9 at all.
The Go 1 macrobenchmarks (those with per-op times >= 10 µs) are unaffected:
BenchmarkBinaryTree17 5491374955 5471024381 -0.37%
BenchmarkFannkuch11 4357101311 4275174828 -1.88%
BenchmarkGobDecode 11029957 11364184 +3.03%
BenchmarkGobEncode 6852205 6784822 -0.98%
BenchmarkGzip 650795967 650152275 -0.10%
BenchmarkGunzip 140962363 141041670 +0.06%
BenchmarkHTTPClientServer 71581 73081 +2.10%
BenchmarkJSONEncode 31928079 31913356 -0.05%
BenchmarkJSONDecode 117470065 113689916 -3.22%
BenchmarkMandelbrot200 6008923 5998712 -0.17%
BenchmarkGoParse 6310917 6327487 +0.26%
BenchmarkRegexpMatchMedium_1K 114568 114763 +0.17%
BenchmarkRegexpMatchHard_1K 168977 169244 +0.16%
BenchmarkRevcomp 935294971 914060918 -2.27%
BenchmarkTemplate 145917123 148186096 +1.55%
Minux previous reported larger variations, but these were caused by
run-to-run noise, not repeatable slowdowns.
Actual code changes by Minux.
I only did the docs and the benchmarking.
LGTM=dvyukov, iant, minux
R=minux, josharian, iant, dave, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/109050043
This CL removes the special syntax for method receivers and
makes it just like other parameters. Instead, the crucial
receiver-specific rules (exactly one receiver, receiver type
must be of the form T or *T) are specified verbally instead
of syntactically.
This is a fully backward-compatible (and minor) syntax
relaxation. As a result, the following syntactic restrictions
(which are completely irrelevant) and which were only in place
for receivers are removed:
a) receiver types cannot be parenthesized
b) receiver parameter lists cannot have a trailing comma
The result of this CL is a simplication of the spec and the
implementation, with no impact on existing (or future) code.
Noteworthy:
- gc already permits a trailing comma at the end of a receiver
declaration:
func (recv T,) m() {}
This is technically a bug with the current spec; this CL will
legalize this notation.
- gccgo produces a misleading error when a trailing comma is used:
error: method has multiple receivers
(even though there's only one receiver)
- Compilers and type-checkers won't need to report errors anymore
if receiver types are parenthesized.
Fixes#4496.
LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/101500044
This is a clone of 101370043, which I accidentally applied to the
release branch first.
No big deal, it needed to be applied there anyway.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/108090043
The current wording is reversed in 2 places.
Not sure how it got 4 LGTMs (mine was there as well).
Update #6242.
LGTM=dan.kortschak, r, rsc
R=golang-codereviews, 0xjnml, dan.kortschak, r, rsc
CC=golang-codereviews
https://golang.org/cl/101980047
