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>
The very first paragraph on "Package initialization" stated that
"variables are initialized in declaration order, but after any
variables they might depend on". This phrasing was easily
misread as "declaration order is the first sorting criteria"
and then contradicted what the subsequent paragraphs spelled
out in precise detail.
Instead, variable initialization proceeds by repeatedly determining
a set of ready to initialize variables, and then selecting from that
set the variable declared earliest. That is, declaration order is the
second sorting criteria.
Also, for the purpose of variable initialization, declarations
introducing blank (_) variables are considered like any other
variables (their initialization expressions may have side-effects
and affect initialization order), even though blank identifiers
are not "declared".
This CL adds clarifying language regarding these two issues
and the supporting example.
Both gccgo and go/types implement this behavior. cmd/compile
has a long-standing issue (#22326).
The spec also did not state in which order multiple variables
initialized by a single (multi-value) initialization expression are
handled. This CL adds a clarifying paragraph: If any such variable
is initialized, all that declaration's variables are initialized at
the same time.
This behavior matches user expectation: We are not expecting to
observe partially initialized sets of variables in declarations
such as "var a, b, c = f()".
It also matches existing cmd/compile and go/types (but not gccgo)
behavior.
Finally, cmd/compile, gccgo, and go/types produce different
initialization orders in (esoteric) cases where hidden (not
detected with existing rules) dependencies exist. Added a
sentence and example clarifying how much leeway compilers have
in those situations. The goal is to preserve the ability to
use static initialization while at the same time maintain
the relative initialization order of variables with detected
dependencies.
Fixes #31292.
Updates #22326.
Change-Id: I0a369abff8cfce27afc975998db875f5c580caa2
Reviewed-on: https://go-review.googlesource.com/c/go/+/175980
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Previous section of documentation said that if GOPATH is not set then
it will be default to "$HOME/go", not "$HOME/work".
This change fix the path in example code to "$HOME/go", and while at it
fix the output of git command after commit.
Change-Id: Ifedca6c3997efd07e865c27b7321d755acad0254
Reviewed-on: https://go-review.googlesource.com/c/go/+/175258
Reviewed-by: Andrew Bonventre <andybons@golang.org>
The compiler output shown in the doc is now quite old
(most of the changes happened in Go 1.5).
Update it to be more like what users will actually see.
Also explain how to get literal machine code again.
Prompted by #30968.
Change-Id: I0ce139c3fe299ccc43e85b6aca81c6e0aac1a2df
Reviewed-on: https://go-review.googlesource.com/c/go/+/175757
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
For example, can use `goroutine all bt` to dump all goroutines'
information.
Change-Id: I51b547c2b837913e4bdabf0f45b28f09250a3e34
GitHub-Last-Rev: d04dcd4f58
GitHub-Pull-Request: golang/go#26283
Reviewed-on: https://go-review.googlesource.com/c/go/+/122589
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
The top right menu in Gerrit is now a gear icon, and the link
has a slightly different title.
Change-Id: I3f5d194f31ad09a99416a45db392aa4b5c7d98ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/173400
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change adds the environment variable GOWASM, which is a comma
separated list of experimental WebAssembly features that the compiled
WebAssembly binary is allowed to use. The default is to use no
experimental features. Initially there are no features avaiable.
More information about feature proposals can be found at
https://github.com/WebAssembly/proposals
Change-Id: I4c8dc534c99ecff8bb075dded0186ca8f8decaef
Reviewed-on: https://go-review.googlesource.com/c/go/+/168881
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
ppc64{,le} processor level selection allows the compiler to generate instructions
targeting newer processors and processor-specific optimizations without breaking
compatibility with our current baseline. This feature introduces a new environment
variable, GOPPC64.
GOPPC64 is a GOARCH=ppc64{,le} specific option, for a choice between different
processor levels (i.e. Instruction Set Architecture versions) for which the
compiler will target. The default is 'power8'.
Change-Id: Ic152e283ae1c47084ece4346fa002a3eabb3bb9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/163758
Run-TryBot: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This CL documents the new binary and octal integer literals,
hexadecimal floats, generalized imaginary literals and digit
separators for all number literals in the spec.
Added empty lines between abutting paragraphs in some places
(a more thorough cleanup can be done in a separate CL).
A minor detail: A single 0 was considered an octal zero per the
syntax (decimal integer literals always started with a non-zero
digit). The new octal literal syntax allows 0o and 0O prefixes
and when keeping the respective octal_lit syntax symmetric with
all the others (binary_lit, hex_lit), a single 0 is not automatically
part of it anymore. Rather than complicating the new octal_lit syntax
to include 0 as before, it is simpler (and more natural) to accept
a single 0 as part of a decimal_lit. This is purely a notational
change.
R=Go1.13
Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.
Change-Id: Ib9fdc6e781f6031cceeed37aaed9d05c7141adec
Reviewed-on: https://go-review.googlesource.com/c/go/+/161098
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A recent edit broke the flow; add a paragraph break when the subject
switches from maps to structs.
No changes in wording.
Change-Id: I5df88ec36b9d81931cfdbc684424440d01ac06d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/165917
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
And explain that it does this. A minor change probably worth mentioning,
although (#28782) I'd still like to freeze this document against any substantial
changes.
Fix#30568.
Change-Id: I74c56744871cfaf00dc52a9b480ca61d3ed19a6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/165597
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Path should now appear with the correct slash, depending on which
platform install document is being viewed - keeping in line with the
rest of the document.
Fixes#30160
Change-Id: Ib10e5a4adf366c700bff6f8d246bd5e3111ed61c
Reviewed-on: https://go-review.googlesource.com/c/go/+/162918
Reviewed-by: Andrew Bonventre <andybons@golang.org>
There's a "lib/time" sub-section in the Go 1.12 relase notes that
points to a non-existent golang.org/pkg/lib/time page.
The note is about a change in the tz database in the src/lib/time
directory, but the section's title (and the link) should probably just
refer to the time package.
Change-Id: Ibf9dacd710e72886f14ad0b7415fea1e8d25b83a
Reviewed-on: https://go-review.googlesource.com/c/164977
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Using go get prevents the failure case of when the
user doesn't have the repo on their machine.
Change-Id: I9c1174087728b5b06b578b0d52df6eeb7e8c7a3c
Reviewed-on: https://go-review.googlesource.com/c/163718
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: I46fa43f6c5ac49386f4622e1363d8976f49c0894
Reviewed-on: https://go-review.googlesource.com/c/162019
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
install.html still insisted that GOROOT must be set if a binary install
of Go is set up in a custom directory. However, since 1.10, this has
been unnecessary as the GOROOT will be found based on the location of
the 'go' binary being run.
Likewise, install-source.html includes an 'export GOROOT' line in a
section that only talks about explicitly setting GOARCH and GOOS, which
is optional. We don't want to have users think it is recommended to set
GOROOT here either, so remove the unnecessary line.
Change-Id: I7dfef09f9a1d003e0253b793d63ea40d5cf1837f
Reviewed-on: https://go-review.googlesource.com/c/161758
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Most of the issues that led to the decision on #30055 were related to
incompatibility with or faulty support for RSA-PSS (#29831, #29779,
v1.5 signatures). RSA-PSS is required by TLS 1.3, but is also available
to be negotiated in TLS 1.2.
Altering TLS 1.2 behavior based on GODEBUG=tls13=1 feels surprising, so
just disable RSA-PSS entirely in TLS 1.2 until TLS 1.3 is on by default,
so breakage happens all at once.
Updates #30055
Change-Id: Iee90454a20ded8895e5302e8bcbcd32e4e3031c2
Reviewed-on: https://go-review.googlesource.com/c/160998
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Note the removal of the go tool tour command in the Go 1.12 release
notes.
Updates #24819
Change-Id: I258ab9401ea2cc06a83328c67299376fcf23c980
Reviewed-on: https://go-review.googlesource.com/c/158618
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
