- fix link for `Time.Format`
- fix closing tag for `go get`
- add links for `runtime.Caller`, `runtime.Callers`
- remove link for `TypedArrayOf` since it has been removed (CL 177537)
Change-Id: I1dc38226e6d91c68fbd2f02c1acfad5327f4ebe8
Reviewed-on: https://go-review.googlesource.com/c/go/+/185038
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
When reading tip.golang.org/doc/go1.13.html, the spec links in
the "Changes to the language" section should point to the updated
spec, not the old one.
Change-Id: I6b13ca0b4c722ed52b84a12a680bece876a4e478
Reviewed-on: https://go-review.googlesource.com/c/go/+/184118
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Looking at the live release notes on tip.golang.org, the Modules
section is much more verbose than the other sections.
To some extent that's to be expected, but too much detail in the
release notes might discourage folks from consulting the actual
documentation. Ensure that topics have clear links and omit
unnecessary details.
Change-Id: I1ccbc1697fccaf7ca7094c606bd11696c46d87f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/183987
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
As suggested by thepudds in CL 183630.
Also adjust the paragraph to harmonize the transitions between the
newly-adjacent paragraphs.
Change-Id: Ie85abea946db81804c1995d27be4951d5db6b812
Reviewed-on: https://go-review.googlesource.com/c/go/+/183918
Reviewed-by: Jay Conrod <jayconrod@google.com>
Fixup for two typos from CL 183630.
Change-Id: I7968a736680e8a6bbd1f4691d443b217702bc190
Reviewed-on: https://go-review.googlesource.com/c/go/+/183843
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Also fix up markup in the “Version validation” section to correct
indentation on Chrome.
Change-Id: Ib930d324567c086bbd0c67b105272bdfcca77b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/183630
Reviewed-by: Jay Conrod <jayconrod@google.com>
Also alphabetize port listing.
Change-Id: I4cc552a74856c9955571d721deb6223438c7d856
Reviewed-on: https://go-review.googlesource.com/c/go/+/183637
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Previously, most operations involving pseudo-versions allowed any
arbitrary combination of version string and date, and would resolve to
the underlying revision (typically a Git commit hash) as long as that
revision existed.
There are a number of problems with that approach:
• The pseudo-version participates in minimal version selection. If its
version prefix is inaccurate, the pseudo-version may appear to have
higher precedence that the releases that follow it, effectively
“pinning” the module to that commit. For release tags, module
authors are the ones who make the decision about release tagging;
they should also have control over the pseudo-version precedence
within their module.
• The commit date within the pseudo-version provides a total order
among pseudo-versions. If it is not accurate, the pseudo-version
will sort into the wrong place relative to other commits with the
same version prefix.
To address those problems, this change restricts the pseudo-versions
that the 'go' command accepts, rendering some previously
accepted-but-not-canonical versions invalid. A pseudo-version is now
valid only if all of:
1. The tag from which the pseudo-version derives points to the named
revision or one of its ancestors as reported by the underlying VCS
tool, or the pseudo-version is not derived from any tag (that is,
has a "vX.0.0-" prefix before the date string and uses the lowest
major version appropriate to the module path).
2. The date string within the pseudo-version matches the UTC timestamp
of the revision as reported by the underlying VCS tool.
3. The short name of the revision within the pseudo-version (such as a
Git hash prefix) is the same as the short name reported by the
underlying cmd/go/internal/modfetch/codehost.Repo. Specifically, if
the short name is a SHA-1 prefix, it must use the same number of
hex digits (12) as codehost.ShortenSHA1.
4. The pseudo-version includes a '+incompatible' suffix only if it is
needed for the corresponding major version, and only if the
underlying module does not have a go.mod file.
We believe that all releases of the 'go' tool have generated
pseudo-versions that meet these constraints. However, a few
pseudo-versions edited by hand or generated by third-party tools do
not. If we discover invalid-but-benign pseudo-versions in widely-used
existing dependencies, we may choose to add a whitelist for those
specific path/version combinations.
―
To work around invalid dependencies in leaf modules, users may add a
'replace' directive from the invalid version to its valid equivalent.
Note that the go command's go.mod parser automatically resolves commit
hashes found in 'replace' directives to the appropriate
pseudo-versions, so in most cases one can write something like:
replace github.com/docker/docker v1.14.0-0.20190319215453-e7b5f7dbe98c => github.com/docker/docker e7b5f7dbe98c
and then run any 'go' command (such as 'go list' or 'go mod tidy') to
resolve it to an appropriate pseudo-version. Note that the invalid
version will still be used in minimal version selection, so this use
of 'replace' directives is an incomplete workaround.
―
One of the common use cases for higher-than-tagged pseudo-versions is
for projects that do parallel development on release branches. For
example, if a project cuts a 'v1.2' release branch at v1.2.0, they may
want future commits on the main branch to show up as pre-releases for
v1.3.0 rather than for v1.2.1 — especially if v1.2.1 is already tagged
on the release branch. (On the other hand, a backport of a patch to
the v1.2 branch should not show up as a pre-release for v1.3.0.)
To address this use-case, module authors can make use of our existing
support for pseudo-versions derived from pre-release tags: if the
author adds an explicit pre-release tag (such as 'v1.3.0-devel') to
the first commit after the branch, then the pseudo-versions for that
commit and its descendents will be derived from that tag and will sort
appropriately in version selection.
―
Updates #27171Fixes#29262Fixes#27173Fixes#32662Fixes#32695
Change-Id: I0d50a538b6fdb0d3080aca9c9c3df1040da1b329
Reviewed-on: https://go-review.googlesource.com/c/go/+/181881
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
There is a subtle distinction between a value
*being* the zero value vs being *equal to* the zero value.
This was discussed at length in #31450.
Using "a zero value" in the docs suggests that there may
be more than zero value. That is possible on the "equal to
zero value" reading, but not the "is zero" reading that we
selected for the semantics of IsZero.
This change attempts to prevent any confusion on this front by
switching to "the zero value" in the documentation.
And while we're here, eliminate a double-space.
(Darn macbook keyboards.)
Change-Id: Iaa02ba297438793f5a90be9919a4d53baef92f8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/182617
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Write release notes for a few reflect, runtime, and syscall changes.
The init randomization has been reverted.
Change-Id: Idae481ca015e325eb7302abaa15b2792312f4c32
Reviewed-on: https://go-review.googlesource.com/c/go/+/181577
Reviewed-by: Austin Clements <austin@google.com>
* In doc/install-source.html, clarify the meaning of $GOBIN and
describe where executables from the Go distribution are
installed. Also describe $GOPATH, since it provides a default value
for $GOBIN and may conflict with $GOROOT.
* Add more detail to 'go help install' as well.
Fixes#31576
Change-Id: Ib8a8c21677c3aa0ebef97a3b587b6f8fe338b80e
Reviewed-on: https://go-review.googlesource.com/c/go/+/182341
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change makes the release notes for Go 1.13 more complete
by mentioning a new function in the os package.
Change-Id: I0d637fd70ff6d14782bbfb7c13985a0f83b19d6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/181945
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: Idb5bf2a61bff635e3ebd926bdeacf943578ac874
Reviewed-on: https://go-review.googlesource.com/c/go/+/181681
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The additions were generated using golang.org/x/build/cmd/relnote.
Change-Id: Ie7322f7d01a2dd4a7bca89b9ef9c1ce93bc2671a
Reviewed-on: https://go-review.googlesource.com/c/go/+/180778
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Some <h3>s were missing ids due to which the anchor links
weren't getting generated.
Fixes#32415
Change-Id: Ica21425c1a7c49735231c1de96b6c77dd594ce64
Reviewed-on: https://go-review.googlesource.com/c/go/+/180397
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The spec was not very precise as to what happens with respect to sharing
if a sliced operand is (a pointer to) an array. Added a small clarification
and a supporting example.
Fixes#31689.
Change-Id: Ic49351bec2033abd3f5428154ec3e9a7c2c9eaa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/177139
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Add a small paragraph and example pointing out
the difference for the case where T is a slice
or map. This is a common error for Go novices.
Fixes#29425.
Change-Id: Icdb59f25361e9f6a09b190fbfcc9ae0c7d90077b
Reviewed-on: https://go-review.googlesource.com/c/go/+/176338
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
