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>
This clarifies some of the titles so they're more "news" friendly and
less implementation-oriented.
Change-Id: Ied02aa1e6824b04db5d32ecdd58e972515b1f588
Reviewed-on: https://go-review.googlesource.com/29830
Reviewed-by: Rick Hudson <rlh@golang.org>
With help of a new interactive commit classifier tool (tool location
TBD, likely x/build/cmd/writenotes), classify all commits from go1.7
up to 56d35d4.
We can selectively cull this list later. When in doubt, I erred on the
side of inclusion for now.
Change-Id: I458945004e1b1a148fb2f294b454a390ef4f92c2
Reviewed-on: https://go-review.googlesource.com/30696
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This simply documents the status quo accepted by cmd/compile, gccgo,
and go/types. The new language matches the language used for indices
of index expressions for arrays and slices.
Fixes#16679.
Change-Id: I65447889fbda9d222f2a9e6c10334d1b38c555f0
Reviewed-on: https://go-review.googlesource.com/30474
Reviewed-by: Rob Pike <r@golang.org>
This is a backwards-compatible language change.
Per the proposal (#16085), the rules for conversions are relaxed
such that struct tags in any of the structs involved in the conversion
are ignored (recursively).
Because this is loosening the existing rules, code that compiled so
far will continue to compile.
For #16085.
Fixes#6858.
Change-Id: I0feef651582db5f23046a2331fc3f179ae577c45
Reviewed-on: https://go-review.googlesource.com/24190
Reviewed-by: Russ Cox <rsc@golang.org>
Effective Go has references to a function call f(c, req) made by ServeHTTP mixed with f(w,
req). c is dropped in favor of w to maintain consistency
Fixes#17128
Change-Id: I6746fd115ed5a58971fd24e54024d29d18ead1fa
Reviewed-on: https://go-review.googlesource.com/29311
Reviewed-by: Rob Pike <r@golang.org>
The download page says "OS X 10.8 or later", but other pages said 10.7.
Say 10.8 everywhere.
Turns out Go doesn't even compile on OS X 10.7 (details in bug) and we
only run builders for OS X 10.8+, which is likely why 10.7
regressed. Until recently we only had OS X 10.10 builders, even.
We could run 10.7 builders, but there's basically no reason to do so,
especially with 10.12 coming out imminently.
Fixes#16625
Change-Id: Ida6e20fb6c54aea0a3757235b708ac1c053b8c04
Reviewed-on: https://go-review.googlesource.com/28870
Reviewed-by: Chris Broadfoot <cbro@golang.org>
We relay this info in a few places, in a few different ways, but not
consistently everywhere. This led one of our users to start googling
and not find https://golang.org/doc/code.html#Workspaces, of which `go
help gopath` is the most equivalent.
Change-Id: I28a94375739f3aa4f200e145293ca2a5f65101e1
Reviewed-on: https://go-review.googlesource.com/28690
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Currently the footnote says "gcc is required only if you plan to use cgo",
but the footnote was referenced from the text:
"use the clang or gcc† that comes with Xcode‡ for cgo support"
That seems to imply that clang doesn't get you cgo support on OS X,
which isn't true. The update text matches what the install-source.html
page says.
Change-Id: Ib88464a0d138227d357033123f6675a77d5d777f
Reviewed-on: https://go-review.googlesource.com/28786
Reviewed-by: Minux Ma <minux@golang.org>
See the issue below for details.
Fixes#16794.
Change-Id: I7e338089fd80ddcb634fa80bfc658dee2772361c
Reviewed-on: https://go-review.googlesource.com/27356
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This truly is a common point of confusion that deserves
explanation in the FAQ.
Change-Id: Ie624e31a2042ca99626fe7570d9c8c075aae6a84
Reviewed-on: https://go-review.googlesource.com/28275
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I was confused by the current wording. This wording
answers the question more clearly.
Thanks to Robert Griesemer for suggestions.
Fixes#16916
Change-Id: I50187c8df2db661b9581f4b3c5d5c279d2f9af41
Reviewed-on: https://go-review.googlesource.com/28052
Reviewed-by: Robert Griesemer <gri@golang.org>
Recreated original favicon with svg. Note, the rasterizations are hand
tweaked for crispness and straight export will not give the same results.
Fixes#6938
Change-Id: I9bf7b59028711361c29365b145932d90af419b69
Reviewed-on: https://go-review.googlesource.com/26850
Reviewed-by: Chris Broadfoot <cbro@golang.org>
The enumerations didn't include the syntactic form where the lhs is
full variable declaration with type specification, as in:
var x, ok T = ...
Fixes#15782.
Change-Id: I0f7bafc37dc9dcf62cdb0894a0d157074ccd4b3e
Reviewed-on: https://go-review.googlesource.com/27670
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The changes match the existing compilers, and assume an adjusted
spec (per issue #16794).
Fixes#15686.
Change-Id: I72677ce75888c41a8f3c2963117a2f2d5501c42b
Reviewed-on: https://go-review.googlesource.com/27290
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It is no longer used by Go.
It's now moved to golang.org/x/tools/cmd/goyacc for anybody who needs it.
Fixes#11229
Change-Id: Ia431d5a380c7ff784a2050dee2f5bc8acee015da
Reviewed-on: https://go-review.googlesource.com/27325
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Updates #16396
Change-Id: I7b4f85610e66f2c77c17cf8898cc41d81b2efc8c
Reviewed-on: https://go-review.googlesource.com/25283
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Rather than saying "stop-the-world", say "garbage collection pauses".
Change-Id: Ifb2931781ab3094e04bea93f01f18f1acb889bdc
Reviewed-on: https://go-review.googlesource.com/25018
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Most of the runtime improvements are hard to quantify or summarize,
but it's worth mentioning some of the substantial improvements in STW
time, and that the scavenger now actually works on ARM64, PPC64, and
MIPS.
Change-Id: I0e951038516378cc3f95b364716ef1c183f3445a
Reviewed-on: https://go-review.googlesource.com/24966
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We decided that ppc64 should maintain power5 compatibility.
ppc64le requires power8.
Fixes#16372.
Change-Id: If5b309a0563f55a3c1fe9c853d29a463f5b71101
Reviewed-on: https://go-review.googlesource.com/24915
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Document that the http.Server is now stricter about rejecting
requests with invalid HTTP versions, and also that it rejects plaintext
HTTP/2 requests, except for `PRI * HTTP/2.0` upgrade requests.
The relevant CL is https://golang.org/cl/24505.
Updates #15810.
Change-Id: Ibbace23e001b5e2eee053bd341de50f9b6d3fde8
Reviewed-on: https://go-review.googlesource.com/24731
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
New Gophers sometimes misconstrue the advice in the "Generality" section
as "export interfaces instead of implementations" and add needless
interfaces to their code as a result. Down the road, they end up
needing to add methods and either break existing callers or have to
resort to unpleasant hacks (e.g. using "magic method" type-switches).
Weaken the first paragraph of this section to only advise leaving types
unexported when they will never need additional methods.
Change-Id: I32a1ae44012b5896faf167c02e192398a4dfc0b8
Reviewed-on: https://go-review.googlesource.com/24892
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
A follow-on to https://golang.org/cl/24852 that mentions the
documentation clarifications.
Updates #16308.
Change-Id: Ic2a6e1d4938d74352f93a6649021fb610efbfcd0
Reviewed-on: https://go-review.googlesource.com/24857
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
For better or for worse, it's IsExist, not IsExists.
Change-Id: I4503f961486edd459c0c81cf3f32047dff7703a4
Reviewed-on: https://go-review.googlesource.com/24819
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We had ~30 one way, and these four new occurrences the other way.
Updates #11626
Change-Id: Ic6403dc4905874916ae292ff739d33482ed8e5bf
Reviewed-on: https://go-review.googlesource.com/24683
Reviewed-by: Rob Pike <r@golang.org>
- Mention RFC 2616 conformation in which the server now only sends one
"Transfer-Encoding" header when "chunked" is explicitly set.
- Mention that a timeout handler now sends a 200 status code on
encountering an empty response body instead of sending back 0.
Change-Id: Id45e2867390f7e679ab40d7a66db1f7b9d92ce17
Reviewed-on: https://go-review.googlesource.com/24250
Reviewed-by: Andrew Gerrand <adg@golang.org>
Signed-off-by: Steven Phillips <steve@tryingtobeawesome.com>
Change-Id: Ie7c3253a5e1cd43be8fa12bad340204cc6c5ca76
Reviewed-on: https://go-review.googlesource.com/23677
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We say "cancelation," not "cancellation."
Fixes#15928.
Change-Id: I66d545404665948a27281133cb9050eebf1debbb
Reviewed-on: https://go-review.googlesource.com/23673
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Both compilers and also go/types don't permit duplicate types in
type switches; i.e., this spec change is documenting a status quo
that has existed for some time.
Furthermore, duplicate nils are not accepted by gccgo or go/types;
and more recently started causing a compiler error in gc. Permitting
them is inconsistent with the existing status quo.
Rather than making it an implementation restriction (as we have for
expression switches), this is a hard requirement since it was enforced
from the beginning (except for duplicate nils); it is also a well
specified requirement that does not pose a significant burden for
an implementation.
Fixes#15896.
Change-Id: If12db5bafa87598b323ea84418cb05421e657dd8
Reviewed-on: https://go-review.googlesource.com/23584
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The original draft mentioned support for json.Marshaler, but that's
not the case. JSON supports only string keys (not arbitrary JSON)
so only encoding.TextMarshaller is supported.
Change-Id: I7788fc23ac357da88e92aa0ca17b513260840cee
Reviewed-on: https://go-review.googlesource.com/23529
Reviewed-by: Andrew Gerrand <adg@golang.org>
Document the following:
* That the algorithmic changes are still compliant with RFC 1951. I remember
people having questions regarding this issue, and it would be good to re-assure
them that it is still standards compliant.
* io.EOF can now be returned early (c27efce66b)
* Use the term "decompress" when referred to as an action. The term "uncompressed"
or "decompressed" are both valid as ways to represent the current state of the data.
Change-Id: Ie29ebce709357359e7c36d3e7f3d53b260eaadfa
Reviewed-on: https://go-review.googlesource.com/23552
Reviewed-by: Andrew Gerrand <adg@golang.org>
Document new behavior about signal name printing
in panics as per CL golang.org/cl/22753.
For #15810
Change-Id: I9c677d5dd779b41e82afa25e3c797d8e739600d3
Reviewed-on: https://go-review.googlesource.com/23493
Reviewed-by: Russ Cox <rsc@golang.org>
