None of them need to be called out in the release notes.
Change-Id: I143a1879b25063574e4107c1e89264434d45d1d5
Reviewed-on: https://go-review.googlesource.com/33676
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 32796 changes the SIGPIPE behaviour for c-archive and c-shared
programs. Add it to go1.8.txt.
Change-Id: I31200187033349c642965a4bb077bcc77d5329a3
Reviewed-on: https://go-review.googlesource.com/33397
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This matches what we already do for switch statements and makes
this large section more visibly organized. No other changes besides
introducing the titles.
Fixes#4486.
Change-Id: I73f274e4fdd27c6cfeaed79090b4553e57a9c479
Reviewed-on: https://go-review.googlesource.com/33410
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
- organize examples better
- add an example illustrating behavior if element type is a named pointer type
- both compilers and go/types (per https://go-review.googlesource.com/33358)
follow this now
See the issue for detailed discussion.
Fixes#17954.
Change-Id: I8d90507ff2347d9493813f75b73233819880d2b4
Reviewed-on: https://go-review.googlesource.com/33361
Reviewed-by: Rob Pike <r@golang.org>
Both automated updates with a few tweaks.
Change-Id: I24579a8dcc32a84a4fff5c2212681ef30dda61d1
Reviewed-on: https://go-review.googlesource.com/33297
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The tree is inconsistent about single l vs double l in those
words in documentation, test messages, and one error value text.
$ git grep -E '[Mm]arshall(|s|er|ers|ed|ing)' | wc -l
42
$ git grep -E '[Mm]arshal(|s|er|ers|ed|ing)' | wc -l
1694
Make it consistently a single l, per earlier decisions. This means
contributors won't be confused by misleading precedence, and it helps
consistency.
Change the spelling in one error value text in newRawAttributes of
crypto/x509 package to be consistent.
This change was generated with:
perl -i -npe 's,([Mm]arshal)l(|s|er|ers|ed|ing),$1$2,' $(git grep -l -E '[Mm]arshall' | grep -v AUTHORS | grep -v CONTRIBUTORS)
Updates #12431.
Follows https://golang.org/cl/14150.
Change-Id: I85d28a2d7692862ccb02d6a09f5d18538b6049a2
Reviewed-on: https://go-review.googlesource.com/33017
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We thought it would at the time, but then Beta 4 changed the ABI
again, so it wasn't true in practice.
Fixes#17643
Change-Id: I36b747bd69a56adc7291fa30d6bffdf67ab8741b
Reviewed-on: https://go-review.googlesource.com/32238
Reviewed-by: Russ Cox <rsc@golang.org>
As agreed upon by the Code of Conduct working group, "race" may refer to
an attempt to classify people based on "defining characteristics",
regardless of how this people view themselves, while "ethnicity" refers
to how people identify themselves.
The Code of Conduct working group believes that the term "ethnicity"
will be more comprehensive and inclusive, and will better serve the Go
community.
Change-Id: I724b72cadb8cf29b4bac8f83017b0303feae3c94
Reviewed-on: https://go-review.googlesource.com/32133
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
For some reason git won't let me write
doc/effective_go.html: reword confusing sentence
or even
doc/effective_go: reword confusing sentence
as the subject line for this CL, but that's not important. The
actual CL just rewrites one sentence and adds an option to grep in
the associated example.
Fixes#15875
Change-Id: Iee159ea751caf4b73eacf3dfc86e29032646373f
Reviewed-on: https://go-review.googlesource.com/32110
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A 16bit binary exponent permits a constant range covering roughly the range
from 7e-9865 to 7e9863 which is more than enough for any practical and
hypothetical constant arithmetic.
Furthermore, until recently cmd/compile could not handle very large exponents
correctly anyway; i.e., the chance that any real programs (but for tests that
explore corner cases) are affected are close to zero.
Finally, restricting the minimum supported range significantly reduces the
implementation complexity in an area that hardly matters in reality for new
or alternative spec-compliant implementations that don't or cannot rely on
pre-existing arbitratry precision arithmetic packages that support a 32bit
exponent range.
This is technically a language change but for the reasons mentioned above
this is unlikely to affect any real programs, and certainly not programs
compiled with the gc or gccgo compilers as they currently support up to
32bit exponents.
Fixes#13572.
Change-Id: I970f919c57fc82c0175844364cf48ea335f17d39
Reviewed-on: https://go-review.googlesource.com/17711
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
