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>
Mostly complete but a few TODOs remain for future CLs.
For #15810.
Change-Id: I81ee19d1088d192cf709a5f7e6b7bcc44ad892ac
Reviewed-on: https://go-review.googlesource.com/23379
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Current number was out-of-date since adding MIPS.
Change-Id: I565342a92de3893b75cdfb76fa39f7fdf15672da
Reviewed-on: https://go-review.googlesource.com/22952
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Note that the spec already makes that point with a comment in the very first
example for struct field tags. This change is simply stating this explicitly
in the actual spec prose.
- gccgo and go/types already follow this rule
- the current reflect package API doesn't distinguish between absent tags
and empty tags (i.e., there is no discoverable difference)
Fixes#15412.
Change-Id: I92f9c283064137b4c8651630cee0343720717a02
Reviewed-on: https://go-review.googlesource.com/22391
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
A late response to CL 22163.
Change-Id: I5275a22af7081875af0256da296811f4fe9832dc
Reviewed-on: https://go-review.googlesource.com/22296
Reviewed-by: David Symonds <dsymonds@golang.org>
Per a suggestion from mdempsky.
Both gc and gccgo consider a statement list as terminating if the
last _non_empty_ statement is terminating; i.e., trailing semis are
ok. Only gotype followed the current stricter rule in the spec.
This change adjusts the spec to match gc and gccgo behavior. In
support of this change, the spec has a matching rule for fallthrough,
which in valid positions may be followed by trailing semis as well.
For details and examples, see the issue below.
Fixes#14422.
Change-Id: Ie17c282e216fc40ecb54623445c17be111e17ade
Reviewed-on: https://go-review.googlesource.com/19981
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This will allow us to mechanically substitute these strings
using javascript (in a forthcoming change to x/tools/godoc).
Updates #14371
Change-Id: I96e876283060ffbc9f3eabaf55d6b880685453e1
Reviewed-on: https://go-review.googlesource.com/22055
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
