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>
Named returned values should only be used on public funcs and methods
when it contributes to the documentation.
Named return values should not be used if they're only saving the
programmer a few lines of code inside the body of the function,
especially if that means there's stutter in the documentation or it
was only there so the programmer could use a naked return
statement. (Naked returns should not be used except in very small
functions)
This change is a manual audit & cleanup of public func signatures.
Signatures were not changed if:
* the func was private (wouldn't be in public godoc)
* the documentation referenced it
* the named return value was an interesting name. (i.e. it wasn't
simply stutter, repeating the name of the type)
There should be no changes in behavior. (At least: none intended)
Change-Id: I3472ef49619678fe786e5e0994bdf2d9de76d109
Reviewed-on: https://go-review.googlesource.com/20024
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
