Update prebuilts to go1.10 ab/4625579
Test: m -j blueprint_tools
Change-Id: I12d0286a2978fcbafa50880625700ba69c4581d8
diff --git a/doc/articles/go_command.html b/doc/articles/go_command.html
index 0fd83cb..9f4e8e0 100644
--- a/doc/articles/go_command.html
+++ b/doc/articles/go_command.html
@@ -134,7 +134,7 @@
example, if we allowed extra configuration such as compiler flags or
command line recipes, then that configuration would need to be updated
each time the build tools changed; it would also be inherently tied
-to the use of a specific tool chain.</p>
+to the use of a specific toolchain.</p>
<h2>Getting started with the go command</h2>
diff --git a/doc/articles/wiki/final-noclosure.go b/doc/articles/wiki/final-noclosure.go
index d72ca80..b4ce255 100644
--- a/doc/articles/wiki/final-noclosure.go
+++ b/doc/articles/wiki/final-noclosure.go
@@ -8,6 +8,7 @@
"errors"
"html/template"
"io/ioutil"
+ "log"
"net/http"
"regexp"
)
@@ -98,5 +99,5 @@
http.HandleFunc("/view/", viewHandler)
http.HandleFunc("/edit/", editHandler)
http.HandleFunc("/save/", saveHandler)
- http.ListenAndServe(":8080", nil)
+ log.Fatal(http.ListenAndServe(":8080", nil))
}
diff --git a/doc/articles/wiki/final-noerror.go b/doc/articles/wiki/final-noerror.go
index 86d8da7..42a22da 100644
--- a/doc/articles/wiki/final-noerror.go
+++ b/doc/articles/wiki/final-noerror.go
@@ -7,6 +7,7 @@
import (
"html/template"
"io/ioutil"
+ "log"
"net/http"
)
@@ -49,5 +50,5 @@
func main() {
http.HandleFunc("/view/", viewHandler)
http.HandleFunc("/edit/", editHandler)
- http.ListenAndServe(":8080", nil)
+ log.Fatal(http.ListenAndServe(":8080", nil))
}
diff --git a/doc/articles/wiki/final-parsetemplate.go b/doc/articles/wiki/final-parsetemplate.go
index 5ff8bf6..a9aa7f2 100644
--- a/doc/articles/wiki/final-parsetemplate.go
+++ b/doc/articles/wiki/final-parsetemplate.go
@@ -7,6 +7,7 @@
import (
"html/template"
"io/ioutil"
+ "log"
"net/http"
"regexp"
)
@@ -87,5 +88,5 @@
http.HandleFunc("/view/", makeHandler(viewHandler))
http.HandleFunc("/edit/", makeHandler(editHandler))
http.HandleFunc("/save/", makeHandler(saveHandler))
- http.ListenAndServe(":8080", nil)
+ log.Fatal(http.ListenAndServe(":8080", nil))
}
diff --git a/doc/articles/wiki/final-template.go b/doc/articles/wiki/final-template.go
index 719157d..7ea480e 100644
--- a/doc/articles/wiki/final-template.go
+++ b/doc/articles/wiki/final-template.go
@@ -7,6 +7,7 @@
import (
"html/template"
"io/ioutil"
+ "log"
"net/http"
)
@@ -61,5 +62,5 @@
http.HandleFunc("/view/", viewHandler)
http.HandleFunc("/edit/", editHandler)
http.HandleFunc("/save/", saveHandler)
- http.ListenAndServe(":8080", nil)
+ log.Fatal(http.ListenAndServe(":8080", nil))
}
diff --git a/doc/articles/wiki/final-test.patch b/doc/articles/wiki/final-test.patch
index 499ad78..fd7d625 100644
--- a/doc/articles/wiki/final-test.patch
+++ b/doc/articles/wiki/final-test.patch
@@ -1,36 +1,27 @@
-*** final.go 2015-06-14 23:59:22.000000000 +0200
---- final-test.go 2015-06-15 00:15:41.000000000 +0200
-***************
-*** 7,12 ****
---- 7,14 ----
- import (
- "html/template"
- "io/ioutil"
-+ "log"
-+ "net"
- "net/http"
- "regexp"
- )
-***************
-*** 85,89 ****
- http.HandleFunc("/edit/", makeHandler(editHandler))
- http.HandleFunc("/save/", makeHandler(saveHandler))
-
-! http.ListenAndServe(":8080", nil)
- }
---- 87,101 ----
- http.HandleFunc("/edit/", makeHandler(editHandler))
- http.HandleFunc("/save/", makeHandler(saveHandler))
-
-! l, err := net.Listen("tcp", "127.0.0.1:0")
-! if err != nil {
-! log.Fatal(err)
-! }
-! err = ioutil.WriteFile("final-test-port.txt", []byte(l.Addr().String()), 0644)
-! if err != nil {
-! log.Fatal(err)
-! }
-! s := &http.Server{}
-! s.Serve(l)
-! return
- }
+--- final.go 2017-08-31 13:19:00.422925489 -0700
++++ final-test.go 2017-08-31 13:23:43.381391659 -0700
+@@ -8,6 +8,7 @@
+ "html/template"
+ "io/ioutil"
+ "log"
++ "net"
+ "net/http"
+ "regexp"
+ )
+@@ -86,5 +87,15 @@
+ http.HandleFunc("/edit/", makeHandler(editHandler))
+ http.HandleFunc("/save/", makeHandler(saveHandler))
+
+- log.Fatal(http.ListenAndServe(":8080", nil))
++ l, err := net.Listen("tcp", "127.0.0.1:0")
++ if err != nil {
++ log.Fatal(err)
++ }
++ err = ioutil.WriteFile("final-test-port.txt", []byte(l.Addr().String()), 0644)
++ if err != nil {
++ log.Fatal(err)
++ }
++ s := &http.Server{}
++ s.Serve(l)
++ return
+ }
diff --git a/doc/articles/wiki/final.go b/doc/articles/wiki/final.go
index 139a323..0f6646b 100644
--- a/doc/articles/wiki/final.go
+++ b/doc/articles/wiki/final.go
@@ -7,6 +7,7 @@
import (
"html/template"
"io/ioutil"
+ "log"
"net/http"
"regexp"
)
@@ -85,5 +86,5 @@
http.HandleFunc("/edit/", makeHandler(editHandler))
http.HandleFunc("/save/", makeHandler(saveHandler))
- http.ListenAndServe(":8080", nil)
+ log.Fatal(http.ListenAndServe(":8080", nil))
}
diff --git a/doc/articles/wiki/http-sample.go b/doc/articles/wiki/http-sample.go
index ac8cc4f..9bc2084 100644
--- a/doc/articles/wiki/http-sample.go
+++ b/doc/articles/wiki/http-sample.go
@@ -2,6 +2,7 @@
import (
"fmt"
+ "log"
"net/http"
)
@@ -11,5 +12,5 @@
func main() {
http.HandleFunc("/", handler)
- http.ListenAndServe(":8080", nil)
+ log.Fatal(http.ListenAndServe(":8080", nil))
}
diff --git a/doc/articles/wiki/index.html b/doc/articles/wiki/index.html
index b6b080d..3e0d532 100644
--- a/doc/articles/wiki/index.html
+++ b/doc/articles/wiki/index.html
@@ -179,7 +179,7 @@
<pre>
$ go build wiki.go
$ ./wiki
-This is a sample page.
+This is a sample Page.
</pre>
<p>
@@ -214,6 +214,12 @@
</p>
<p>
+<code>ListenAndServe</code> always returns an error, since it only returns when an
+unexpected error occurs.
+In order to log that error we wrap the function call with <code>log.Fatal</code>.
+</p>
+
+<p>
The function <code>handler</code> is of the type <code>http.HandlerFunc</code>.
It takes an <code>http.ResponseWriter</code> and an <code>http.Request</code> as
its arguments.
diff --git a/doc/articles/wiki/notemplate.go b/doc/articles/wiki/notemplate.go
index be214d1..0fda7a9 100644
--- a/doc/articles/wiki/notemplate.go
+++ b/doc/articles/wiki/notemplate.go
@@ -7,6 +7,7 @@
import (
"fmt"
"io/ioutil"
+ "log"
"net/http"
)
@@ -52,5 +53,5 @@
func main() {
http.HandleFunc("/view/", viewHandler)
http.HandleFunc("/edit/", editHandler)
- http.ListenAndServe(":8080", nil)
+ log.Fatal(http.ListenAndServe(":8080", nil))
}
diff --git a/doc/articles/wiki/part2.go b/doc/articles/wiki/part2.go
index c023169..30f9dcf 100644
--- a/doc/articles/wiki/part2.go
+++ b/doc/articles/wiki/part2.go
@@ -7,6 +7,7 @@
import (
"fmt"
"io/ioutil"
+ "log"
"net/http"
)
@@ -37,5 +38,5 @@
func main() {
http.HandleFunc("/view/", viewHandler)
- http.ListenAndServe(":8080", nil)
+ log.Fatal(http.ListenAndServe(":8080", nil))
}
diff --git a/doc/articles/wiki/part3-errorhandling.go b/doc/articles/wiki/part3-errorhandling.go
index bb4ecda..34b13a6 100644
--- a/doc/articles/wiki/part3-errorhandling.go
+++ b/doc/articles/wiki/part3-errorhandling.go
@@ -7,6 +7,7 @@
import (
"html/template"
"io/ioutil"
+ "log"
"net/http"
)
@@ -69,5 +70,5 @@
http.HandleFunc("/view/", viewHandler)
http.HandleFunc("/edit/", editHandler)
http.HandleFunc("/save/", saveHandler)
- http.ListenAndServe(":8080", nil)
+ log.Fatal(http.ListenAndServe(":8080", nil))
}
diff --git a/doc/articles/wiki/part3.go b/doc/articles/wiki/part3.go
index 174f3ab..5e5d505 100644
--- a/doc/articles/wiki/part3.go
+++ b/doc/articles/wiki/part3.go
@@ -7,6 +7,7 @@
import (
"html/template"
"io/ioutil"
+ "log"
"net/http"
)
@@ -53,5 +54,5 @@
http.HandleFunc("/view/", viewHandler)
http.HandleFunc("/edit/", editHandler)
//http.HandleFunc("/save/", saveHandler)
- http.ListenAndServe(":8080", nil)
+ log.Fatal(http.ListenAndServe(":8080", nil))
}
diff --git a/doc/asm.html b/doc/asm.html
index 79dc7df..3a05d46 100644
--- a/doc/asm.html
+++ b/doc/asm.html
@@ -29,7 +29,7 @@
and instruction selection occurs partly after code generation.
The assembler works on the semi-abstract form, so
when you see an instruction like <code>MOV</code>
-what the tool chain actually generates for that operation might
+what the toolchain actually generates for that operation might
not be a move instruction at all, perhaps a clear or load.
Or it might correspond exactly to the machine instruction with that name.
In general, machine-specific operations tend to appear as themselves, while more general concepts like
@@ -139,7 +139,7 @@
<p>
There are four predeclared symbols that refer to pseudo-registers.
These are not real registers, but rather virtual registers maintained by
-the tool chain, such as a frame pointer.
+the toolchain, such as a frame pointer.
The set of pseudo-registers is the same for all architectures:
</p>
@@ -876,6 +876,12 @@
</ul>
+<p>
+The value of <code>GOMIPS</code> environment variable (<code>hardfloat</code> or
+<code>softfloat</code>) is made available to assembly code by predefining either
+<code>GOMIPS_hardfloat</code> or <code>GOMIPS_softfloat</code>.
+</p>
+
<h3 id="unsupported_opcodes">Unsupported opcodes</h3>
<p>
diff --git a/doc/conduct.html b/doc/conduct.html
index c40b007..bf52ef9 100644
--- a/doc/conduct.html
+++ b/doc/conduct.html
@@ -183,7 +183,6 @@
<li>Aditya Mukerjee <dev@chimeracoder.net>
<li>Andrew Gerrand <adg@golang.org>
<li>Peggy Li <peggyli.224@gmail.com>
- <li>Sarah Adams <sadams.codes@gmail.com>
<li>Steve Francia <steve.francia@gmail.com>
<li>Verónica López <gveronicalg@gmail.com>
</ul>
diff --git a/doc/contrib.html b/doc/contrib.html
index 0290923..df53d48 100644
--- a/doc/contrib.html
+++ b/doc/contrib.html
@@ -34,6 +34,7 @@
<p>A <a href="/doc/devel/release.html">summary</a> of the changes between Go releases. Notes for the major releases:</p>
<ul>
+ <li><a href="/doc/go1.10">Go 1.10</a> <small>(February 2018)</small></li>
<li><a href="/doc/go1.9">Go 1.9</a> <small>(August 2017)</small></li>
<li><a href="/doc/go1.8">Go 1.8</a> <small>(February 2017)</small></li>
<li><a href="/doc/go1.7">Go 1.7</a> <small>(August 2016)</small></li>
@@ -117,6 +118,6 @@
<p>
Check <a href="//golang.org/issue">the tracker</a> for
open issues that interest you. Those labeled
-<a href="https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3Ahelpwanted">helpwanted</a>
+<a href="https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22">help wanted</a>
are particularly in need of outside help.
</p>
diff --git a/doc/contribute.html b/doc/contribute.html
index f204b06..e5312be 100644
--- a/doc/contribute.html
+++ b/doc/contribute.html
@@ -30,7 +30,7 @@
You only need to do this once per Google Account.
</p>
-<h2 id="go-contrib-init">Automatically set up & diagnose your development environment</h3>
+<h2 id="go-contrib-init">Automatically set up & diagnose your development environment</h2>
<p>
The <code>go-contrib-init</code> tool configures and debugs your Go
development environment, automatically performing many of the steps
@@ -88,7 +88,7 @@
</p>
<p>
-Your secret authentication token is now in a <code>.gitcookie</code> file
+Your secret authentication token is now in a <code>.gitcookies</code> file
and Git is configured to use this file.
</p>
@@ -158,7 +158,7 @@
Changes to Go must be reviewed before they are accepted, no matter who makes the change.
A custom git command called <code>git-codereview</code>, discussed below,
helps manage the code review process through a Google-hosted
-<a href="https://go-review.googlesource.com/">instance</a> Gerrit.
+<a href="https://go-review.googlesource.com/">instance</a> of Gerrit.
</p>
<h3 id="git-codereview_install">Install the git-codereview command</h3>
@@ -187,7 +187,7 @@
On Windows, when using git-bash you must make sure that
<code>git-codereview.exe</code> is in your git exec-path.
Run <code>git --exec-path</code> to discover the right location then create a
-symbolic link or simply copy the executible from $GOPATH/bin to this directory.
+symbolic link or simply copy the executable from $GOPATH/bin to this directory.
</p>
<p>
@@ -208,12 +208,6 @@
<code>git-codereview</code> <code>hooks</code>.
</p>
-<p>
-The workflow described below assumes a single change per branch.
-It is also possible to prepare a sequence of (usually related) changes in a single branch.
-See the <a href="https://golang.org/x/review/git-codereview">git-codereview documentation</a> for details.
-</p>
-
<h3 id="git-config">Set up git aliases</h3>
<p>
@@ -305,6 +299,15 @@
sent during a feature freeze but will not be accepted until the freeze thaws.
</p>
+<h3 id="scratch">Not sure what change to make?</h3>
+
+<p>
+If you want to become familiar with Gerrit and the contribution process,
+but aren't sure what you'd like to contribute just yet, you can use the <a
+href="https://go.googlesource.com/scratch">scratch repository</a> to practice
+making a change.
+</p>
+
<h2 id="making_a_change">Making a change</h2>
<h3 id="checkout_go">Getting Go Source</h3>
@@ -383,7 +386,7 @@
<a href="https://golang.org/change">change log</a> and in the <a
href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file and perhaps the <a
href="/AUTHORS"><code>AUTHORS</code></a> file.
-These files are automatically generated from the commit logs perodically.
+These files are automatically generated from the commit logs periodically.
The <a href="/AUTHORS"><code>AUTHORS</code></a> file defines who “The Go
Authors”—the copyright holders—are.
</p>
@@ -391,7 +394,7 @@
<p>New files that you contribute should use the standard copyright header:</p>
<pre>
-// Copyright 2017 The Go Authors. All rights reserved.
+// Copyright 2018 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
</pre>
@@ -420,6 +423,12 @@
directly to that local branch.
</p>
+<p>
+The workflow described here assumes a single change per branch.
+It is also possible to prepare a sequence of (usually related) changes in a single branch.
+See the <a href="https://golang.org/x/review/git-codereview">git-codereview documentation</a> for details.
+</p>
+
<pre>
$ git change <i><branch></i>
</pre>
@@ -681,8 +690,8 @@
When done, the reviewer adds comments through the Gerrit user interface
and clicks "Reply" to send comments back.
You will receive a mail notification when this happens.
-You must reply through the web interface.
-(Unlike with the old Rietveld review system, replying by mail has no effect.)
+You may reply through the web interface or
+<a href="https://gerrit-review.googlesource.com/Documentation/intro-user.html#reply-by-email">via email</a>.
</p>
<h3 id="revise">Revise and resend</h3>
@@ -696,8 +705,8 @@
</p>
<p>
-You must respond to review comments through the web interface.
-(Unlike with the old Rietveld review system, responding by mail has no effect.)
+You may respond to review comments through the web interface or
+<a href="https://gerrit-review.googlesource.com/Documentation/intro-user.html#reply-by-email">via email</a>.
</p>
<p>
diff --git a/doc/debugging_with_gdb.html b/doc/debugging_with_gdb.html
index f0e65ea..19d36f7 100644
--- a/doc/debugging_with_gdb.html
+++ b/doc/debugging_with_gdb.html
@@ -3,51 +3,76 @@
"Path": "/doc/gdb"
}-->
-<p><i>
-This applies to the standard toolchain (the <code>gc</code> Go
-compiler and tools). Gccgo has native gdb support.
-Besides this overview you might want to consult the
-<a href="http://sourceware.org/gdb/current/onlinedocs/gdb/">GDB manual</a>.
-</i></p>
+<!--
+NOTE: In this document and others in this directory, the convention is to
+set fixed-width phrases with non-fixed-width spaces, as in
+<code>hello</code> <code>world</code>.
+Do not send CLs removing the interior tags from such phrases.
+-->
+
+<i>
+<p>
+The following instructions apply to the standard toolchain
+(the <code>gc</code> Go compiler and tools).
+Gccgo has native gdb support.
+</p>
+<p>
+Note that
+<a href="https://github.com/derekparker/delve">Delve</a> is a better
+alternative to GDB when debugging Go programs built with the standard
+toolchain. It understands the Go runtime, data structures, and
+expressions better than GDB. Delve currently supports Linux, OSX,
+and Windows on <code>amd64</code>.
+For the most up-to-date list of supported platforms, please see
+<a href="https://github.com/derekparker/delve/tree/master/Documentation/installation">
+ the Delve documentation</a>.
+</p>
+</i>
<p>
GDB does not understand Go programs well.
The stack management, threading, and runtime contain aspects that differ
enough from the execution model GDB expects that they can confuse
-the debugger, even when the program is compiled with gccgo.
-As a consequence, although GDB can be useful in some situations, it is
-not a reliable debugger for Go programs, particularly heavily concurrent ones.
-Moreover, it is not a priority for the Go project to address these issues, which
-are difficult.
-In short, the instructions below should be taken only as a guide to how
-to use GDB when it works, not as a guarantee of success.
+the debugger and cause incorrect results even when the program is
+compiled with gccgo.
+As a consequence, although GDB can be useful in some situations (e.g.,
+debugging Cgo code, or debugging the runtime itself), it is not
+a reliable debugger for Go programs, particularly heavily concurrent
+ones. Moreover, it is not a priority for the Go project to address
+these issues, which are difficult.
</p>
<p>
-In time, a more Go-centric debugging architecture may be required.
+In short, the instructions below should be taken only as a guide to how
+to use GDB when it works, not as a guarantee of success.
+
+Besides this overview you might want to consult the
+<a href="http://sourceware.org/gdb/current/onlinedocs/gdb/">GDB manual</a>.
+</p>
+
+<p>
</p>
<h2 id="Introduction">Introduction</h2>
<p>
When you compile and link your Go programs with the <code>gc</code> toolchain
-on Linux, Mac OS X, FreeBSD or NetBSD, the resulting binaries contain DWARFv3
-debugging information that recent versions (>7.1) of the GDB debugger can
+on Linux, Mac OS X, FreeBSD or NetBSD, the resulting binaries contain DWARFv4
+debugging information that recent versions (≥7.5) of the GDB debugger can
use to inspect a live process or a core dump.
</p>
<p>
Pass the <code>'-w'</code> flag to the linker to omit the debug information
-(for example, <code>go build -ldflags "-w" prog.go</code>).
+(for example, <code>go</code> <code>build</code> <code>-ldflags=-w</code> <code>prog.go</code>).
</p>
<p>
The code generated by the <code>gc</code> compiler includes inlining of
function invocations and registerization of variables. These optimizations
-can sometimes make debugging with <code>gdb</code> harder. To disable them
-when debugging, pass the flags <code>-gcflags "-N -l"</code> to the
-<a href="/cmd/go"><code>go</code></a> command used to build the code being
-debugged.
+can sometimes make debugging with <code>gdb</code> harder.
+If you find that you need to disable these optimizations,
+build your program using <code>go</code> <code>build</code> <code>-gcflags=all="-N -l"</code>.
</p>
<p>
@@ -94,7 +119,7 @@
<p>
A recent extension mechanism to GDB allows it to load extension scripts for a
-given binary. The tool chain uses this to extend GDB with a handful of
+given binary. The toolchain uses this to extend GDB with a handful of
commands to inspect internals of the runtime code (such as goroutines) and to
pretty print the built-in map, slice and channel types.
</p>
@@ -139,7 +164,7 @@
<p>
If you're interested in what the debugging information looks like, run
-'<code>objdump -W a.out</code>' and browse through the <code>.debug_*</code>
+<code>objdump</code> <code>-W</code> <code>a.out</code> and browse through the <code>.debug_*</code>
sections.
</p>
@@ -162,7 +187,7 @@
<p>
In this tutorial we will inspect the binary of the
<a href="/pkg/regexp/">regexp</a> package's unit tests. To build the binary,
-change to <code>$GOROOT/src/regexp</code> and run <code>go test -c</code>.
+change to <code>$GOROOT/src/regexp</code> and run <code>go</code> <code>test</code> <code>-c</code>.
This should produce an executable file named <code>regexp.test</code>.
</p>
@@ -188,7 +213,7 @@
</pre>
<p>
-The message <code>"Loading Go Runtime support"</code> means that GDB loaded the
+The message "Loading Go Runtime support" means that GDB loaded the
extension from <code>$GOROOT/src/runtime/runtime-gdb.py</code>.
</p>
@@ -353,7 +378,7 @@
</pre>
<p>
-The command <code>info locals</code> lists all variables local to the function and their values, but is a bit
+The command <code>info</code> <code>locals</code> lists all variables local to the function and their values, but is a bit
dangerous to use, since it will also try to print uninitialized variables. Uninitialized slices may cause gdb to try
to print arbitrary large arrays.
</p>
@@ -386,7 +411,7 @@
</pre>
<p>
-That <code>struct hchan<*testing.T></code> is the
+That <code>struct</code> <code>hchan<*testing.T></code> is the
runtime-internal representation of a channel. It is currently empty,
or gdb would have pretty-printed its contents.
</p>
diff --git a/doc/devel/release.html b/doc/devel/release.html
index 8304522..d82fb0c 100644
--- a/doc/devel/release.html
+++ b/doc/devel/release.html
@@ -30,6 +30,39 @@
Read the <a href="/doc/go1.9">Go 1.9 Release Notes</a> for more information.
</p>
+<h3 id="go1.9.minor">Minor revisions</h3>
+
+<p>
+go1.9.1 (released 2017/10/04) includes two security fixes.
+See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.9.1">Go
+1.9.1 milestone</a> on our issue tracker for details.
+</p>
+
+<p>
+go1.9.2 (released 2017/10/25) includes fixes to the compiler, linker, runtime,
+documentation, <code>go</code> command,
+and the <code>crypto/x509</code>, <code>database/sql</code>, <code>log</code>,
+and <code>net/smtp</code> packages.
+It includes a fix to a bug introduced in Go 1.9.1 that broke <code>go</code> <code>get</code>
+of non-Git repositories under certain conditions.
+See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.9.2">Go
+1.9.2 milestone</a> on our issue tracker for details.
+</p>
+
+<p>
+go1.9.3 (released 2018/01/22) includes fixes to the compiler, runtime,
+and the <code>database/sql</code>, <code>math/big</code>, <code>net/http</code>,
+and <code>net/url</code> packages.
+See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.9.3">Go
+1.9.3 milestone</a> on our issue tracker for details.
+</p>
+
+<p>
+go1.9.4 (released 2018/02/07) includes a security fix to “go get”.
+See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.9.4">Go
+1.9.4</a> milestone on our issue tracker for details.
+</p>
+
<h2 id="go1.8">go1.8 (released 2017/02/16)</h2>
<p>
@@ -63,6 +96,37 @@
1.8.3 milestone</a> on our issue tracker for details.
</p>
+<p>
+go1.8.4 (released 2017/10/04) includes two security fixes.
+It contains the same fixes as Go 1.9.1 and was released at the same time.
+See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.8.4">Go
+1.8.4 milestone</a> on our issue tracker for details.
+</p>
+
+<p>
+go1.8.5 (released 2017/10/25) includes fixes to the compiler, linker, runtime,
+documentation, <code>go</code> command,
+and the <code>crypto/x509</code> and <code>net/smtp</code> packages.
+It includes a fix to a bug introduced in Go 1.8.4 that broke <code>go</code> <code>get</code>
+of non-Git repositories under certain conditions.
+See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.8.5">Go
+1.8.5 milestone</a> on our issue tracker for details.
+</p>
+
+<p>
+go1.8.6 (released 2018/01/22) includes the the same fix in <code>math/big</code>
+as Go 1.9.3 and was released at the same time.
+See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.8.6">Go
+1.8.6 milestone</a> on our issue tracker for details.
+</p>
+
+<p>
+go1.8.7 (released 2018/02/07) includes a security fix to “go get”.
+It contains the same fix as Go 1.9.4 and was released at the same time.
+See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.8.7">Go
+1.8.7</a> milestone on our issue tracker for details.
+</p>
+
<h2 id="go1.7">go1.7 (released 2016/08/15)</h2>
<p>
@@ -236,7 +300,7 @@
</p>
<p>
-go1.3.3 (released 2014/09/30) includes further bug fixes to cgo, the runtime package, and the nacl port.
+go1.3.3 (released 2014/09/30) includes further bug fixes to cgo, the runtime package, and the nacl port.
See the <a href="https://github.com/golang/go/commits/go1.3.3">change history</a> for details.
</p>
@@ -300,7 +364,7 @@
</p>
<p>
-The go1 release corresponds to
+The go1 release corresponds to
<code><a href="weekly.html#2012-03-27">weekly.2012-03-27</a></code>.
</p>
@@ -316,7 +380,7 @@
<p>
go1.0.2 (released 2012/06/13) was issued to fix two bugs in the implementation
-of maps using struct or array keys:
+of maps using struct or array keys:
<a href="//golang.org/issue/3695">issue 3695</a> and
<a href="//golang.org/issue/3573">issue 3573</a>.
It also includes many minor code and documentation fixes.
diff --git a/doc/diagnostics.html b/doc/diagnostics.html
new file mode 100644
index 0000000..35aae15
--- /dev/null
+++ b/doc/diagnostics.html
@@ -0,0 +1,458 @@
+<!--{
+ "Title": "Diagnostics",
+ "Template": true
+}-->
+
+<!--
+NOTE: In this document and others in this directory, the convention is to
+set fixed-width phrases with non-fixed-width spaces, as in
+<code>hello</code> <code>world</code>.
+Do not send CLs removing the interior tags from such phrases.
+-->
+
+<h2 id="introduction">Introduction</h2>
+
+<p>
+The Go ecosystem provides a large suite of APIs and tools to
+diagnose logic and performance problems in Go programs. This page
+summarizes the available tools and helps Go users pick the right one
+for their specific problem.
+</p>
+
+<p>
+Diagnostics solutions can be categorized into the following groups:
+</p>
+
+<ul>
+<li><strong>Profiling</strong>: Profiling tools analyze the complexity and costs of a
+Go program such as its memory usage and frequently called
+functions to identify the expensive sections of a Go program.</li>
+<li><strong>Tracing</strong>: Tracing is a way to instrument code to analyze latency
+throughout the lifecycle of a call or user request. Traces provide an
+overview of how much latency each component contributes to the overall
+latency in a system. Traces can span multiple Go processes.</li>
+<li><strong>Debugging</strong>: Debugging allows us to pause a Go program and examine
+its execution. Program state and flow can be verified with debugging.</li>
+<li><strong>Runtime statistics and events</strong>: Collection and analysis of runtime stats and events
+provides a high-level overview of the health of Go programs. Spikes/dips of metrics
+helps us to identify changes in throughput, utilization, and performance.</li>
+</ul>
+
+<p>
+Note: Some diagnostics tools may interfere with each other. For example, precise
+memory profiling skews CPU profiles and goroutine blocking profiling affects scheduler
+trace. Use tools in isolation to get more precise info.
+</p>
+
+<h2 id="profiling">Profiling</h2>
+
+<p>
+Profiling is useful for identifying expensive or frequently called sections
+of code. The Go runtime provides <a href="https://golang.org/pkg/runtime/pprof/">
+profiling data</a> in the format expected by the
+<a href="https://github.com/google/pprof/blob/master/doc/pprof.md">pprof visualization tool</a>.
+The profiling data can be collected during testing
+via <code>go</code> <code>test</code> or endpoints made available from the <a href="/pkg/net/http/pprof/">
+net/http/pprof</a> package. Users need to collect the profiling data and use pprof tools to filter
+and visualize the top code paths.
+</p>
+
+<p>Predefined profiles provided by the <a href="/pkg/runtime/pprof">runtime/pprof</a> package:</p>
+
+<ul>
+<li>
+<strong>cpu</strong>: CPU profile determines where a program spends
+its time while actively consuming CPU cycles (as opposed to while sleeping or waiting for I/O).
+</li>
+<li>
+<strong>heap</strong>: Heap profile reports memory allocation samples;
+used to monitor current and historical memory usage, and to check for memory leaks.
+</li>
+<li>
+<strong>threadcreate</strong>: Thread creation profile reports the sections
+of the program that lead the creation of new OS threads.
+</li>
+<li>
+<strong>goroutine</strong>: Goroutine profile reports the stack traces of all current goroutines.
+</li>
+<li>
+<strong>block</strong>: Block profile shows where goroutines block waiting on synchronization
+primitives (including timer channels). Block profile is not enabled by default;
+use <code>runtime.SetBlockProfileRate</code> to enable it.
+</li>
+<li>
+<strong>mutex</strong>: Mutex profile reports the lock contentions. When you think your
+CPU is not fully utilized due to a mutex contention, use this profile. Mutex profile
+is not enabled by default, see <code>runtime.SetMutexProfileFraction</code> to enable it.
+</li>
+</ul>
+
+
+<p><strong>What other profilers can I use to profile Go programs?</strong></p>
+
+<p>
+On Linux, <a href="https://perf.wiki.kernel.org/index.php/Tutorial">perf tools</a>
+can be used for profiling Go programs. Perf can profile
+and unwind cgo/SWIG code and kernel, so it can be useful to get insights into
+native/kernel performance bottlenecks. On macOS,
+<a href="https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/">Instruments</a>
+suite can be used profile Go programs.
+</p>
+
+<p><strong>Can I profile my production services?</strong></p>
+
+<p>Yes. It is safe to profile programs in production, but enabling
+some profiles (e.g. the CPU profile) adds cost. You should expect to
+see performance downgrade. The performance penalty can be estimated
+by measuring the overhead of the profiler before turning it on in
+production.
+</p>
+
+<p>
+You may want to periodically profile your production services.
+Especially in a system with many replicas of a single process, selecting
+a random replica periodically is a safe option.
+Select a production process, profile it for
+X seconds for every Y seconds and save the results for visualization and
+analysis; then repeat periodically. Results may be manually and/or automatically
+reviewed to find problems.
+Collection of profiles can interfere with each other,
+so it is recommended to collect only a single profile at a time.
+</p>
+
+<p>
+<strong>What are the best ways to visualize the profiling data?</strong>
+</p>
+
+<p>
+The Go tools provide text, graph, and <a href="http://valgrind.org/docs/manual/cl-manual.html">callgrind</a>
+visualization of the profile data using
+<code><a href="https://github.com/google/pprof/blob/master/doc/pprof.md">go tool pprof</a></code>.
+Read <a href="https://blog.golang.org/profiling-go-programs">Profiling Go programs</a>
+to see them in action.
+</p>
+
+<p>
+<img width="800" src="https://storage.googleapis.com/golangorg-assets/pprof-text.png">
+<br>
+<small>Listing of the most expensive calls as text.</small>
+</p>
+
+<p>
+<img width="800" src="https://storage.googleapis.com/golangorg-assets/pprof-dot.png">
+<br>
+<small>Visualization of the most expensive calls as a graph.</small>
+</p>
+
+<p>Weblist view displays the expensive parts of the source line by line in
+an HTML page. In the following example, 530ms is spent in the
+<code>runtime.concatstrings</code> and cost of each line is presented
+in the listing.</p>
+
+<p>
+<img width="800" src="https://storage.googleapis.com/golangorg-assets/pprof-weblist.png">
+<br>
+<small>Visualization of the most expensive calls as weblist.</small>
+</p>
+
+<p>
+Another way to visualize profile data is a <a href="http://www.brendangregg.com/flamegraphs.html">flame graph</a>.
+Flame graphs allow you to move in a specific ancestry path, so you can zoom
+in/out of specific sections of code.
+The <a href="https://github.com/google/pprof">upstream pprof</a>
+has support for flame graphs.
+</p>
+
+<p>
+<img width="800" src="https://storage.googleapis.com/golangorg-assets/flame.png">
+<br>
+<small>Flame graphs offers visualization to spot the most expensive code-paths.</small>
+</p>
+
+<p><strong>Am I restricted to the built-in profiles?</strong></p>
+
+<p>
+Additionally to what is provided by the runtime, Go users can create
+their custom profiles via <a href="/pkg/runtime/pprof/#Profile">pprof.Profile</a>
+and use the existing tools to examine them.
+</p>
+
+<p><strong>Can I serve the profiler handlers (/debug/pprof/...) on a different path and port?</strong></p>
+
+<p>
+Yes. The <code>net/http/pprof</code> package registers its handlers to the default
+mux by default, but you can also register them yourself by using the handlers
+exported from the package.
+</p>
+
+<p>
+For example, the following example will serve the pprof.Profile
+handler on :7777 at /custom_debug_path/profile:
+</p>
+
+<p>
+<pre>
+package main
+
+import (
+ "log"
+ "net/http"
+ "net/http/pprof"
+)
+
+func main() {
+ mux := http.NewServeMux()
+ mux.HandleFunc("/custom_debug_path/profile", pprof.Profile)
+ log.Fatal(http.ListenAndServe(":7777", mux))
+}
+</pre>
+</p>
+
+<h2 id="tracing">Tracing</h2>
+
+<p>
+Tracing is a way to instrument code to analyze latency throughout the
+lifecycle of a chain of calls. Go provides
+<a href="https://godoc.org/golang.org/x/net/trace">golang.org/x/net/trace</a>
+package as a minimal tracing backend per Go node and provides a minimal
+instrumentation library with a simple dashboard. Go also provides
+an execution tracer to trace the runtime events within an interval.
+</p>
+
+<p>Tracing enables us to:</p>
+
+<ul>
+<li>Instrument and analyze application latency in a Go process.</li>
+<li>Measure the cost of specific calls in a long chain of calls.</li>
+<li>Figure out the utilization and performance improvements.
+Bottlenecks are not always obvious without tracing data.</li>
+</ul>
+
+<p>
+In monolithic systems, it's relatively easy to collect diagnostic data
+from the building blocks of a program. All modules live within one
+process and share common resources to report logs, errors, and other
+diagnostic information. Once your system grows beyond a single process and
+starts to become distributed, it becomes harder to follow a call starting
+from the front-end web server to all of its back-ends until a response is
+returned back to the user. This is where distributed tracing plays a big
+role to instrument and analyze your production systems.
+</p>
+
+<p>
+Distributed tracing is a way to instrument code to analyze latency throughout
+the lifecycle of a user request. When a system is distributed and when
+conventional profiling and debugging tools don’t scale, you might want
+to use distributed tracing tools to analyze the performance of your user
+requests and RPCs.
+</p>
+
+<p>Distributed tracing enables us to:</p>
+
+<ul>
+<li>Instrument and profile application latency in a large system.</li>
+<li>Track all RPCs within the lifecycle of a user request and see integration issues
+that are only visible in production.</li>
+<li>Figure out performance improvements that can be applied to our systems.
+Many bottlenecks are not obvious before the collection of tracing data.</li>
+</ul>
+
+<p>The Go ecosystem provides various distributed tracing libraries per tracing system
+and backend-agnostic ones.</p>
+
+
+<p><strong>Is there a way to automatically intercept each function call and create traces?</strong></p>
+
+<p>
+Go doesn’t provide a way to automatically intercept every function call and create
+trace spans. You need to manually instrument your code to create, end, and annotate spans.
+</p>
+
+<p><strong>How should I propagate trace headers in Go libraries?</strong></p>
+
+<p>
+You can propagate trace identifiers and tags in the
+<a href="/pkg/context#Context"><code>context.Context</code></a>.
+There is no canonical trace key or common representation of trace headers
+in the industry yet. Each tracing provider is responsible for providing propagation
+utilities in their Go libraries.
+</p>
+
+<p>
+<strong>What other low-level events from the standard library or
+runtime can be included in a trace?</strong>
+</p>
+
+<p>
+The standard library and runtime are trying to expose several additional APIs
+to notify on low level internal events. For example,
+<a href="/pkg/net/http/httptrace#ClientTrace"><code>httptrace.ClientTrace</code></a>
+provides APIs to follow low-level events in the life cycle of an outgoing request.
+There is an ongoing effort to retrieve low-level runtime events from
+the runtime execution tracer and allow users to define and record their user events.
+</p>
+
+<h2 id="debugging">Debugging</h2>
+
+<p>
+Debugging is the process of identifying why a program misbehaves.
+Debuggers allow us to understand a program’s execution flow and current state.
+There are several styles of debugging; this section will only focus on attaching
+a debugger to a program and core dump debugging.
+</p>
+
+<p>Go users mostly use the following debuggers:</p>
+
+<ul>
+<li>
+<a href="https://github.com/derekparker/delve">Delve</a>:
+Delve is a debugger for the Go programming language. It has
+support for Go’s runtime concepts and built-in types. Delve is
+trying to be a fully featured reliable debugger for Go programs.
+</li>
+<li>
+<a href="https://golang.org/doc/gdb">GDB</a>:
+Go provides GDB support via the standard Go compiler and Gccgo.
+The stack management, threading, and runtime contain aspects that differ
+enough from the execution model GDB expects that they can confuse the
+debugger, even when the program is compiled with gccgo. Even though
+GDB can be used to debug Go programs, it is not ideal and may
+create confusion.
+</li>
+</ul>
+
+<p><strong>How well do debuggers work with Go programs?</strong></p>
+
+<p>
+The <code>gc</code> compiler performs optimizations such as
+function inlining and variable registerization. These optimizations
+sometimes make debugging with debuggers harder. There is an ongoing
+effort to improve the quality of the DWARF information generated for
+optimized binaries. Until those improvements are available, we recommend
+disabling optimizations when building the code being debugged. The following
+command builds a package with no compiler optimizations:
+
+<p>
+<pre>
+$ go build -gcflags=all="-N -l"
+</pre>
+</p>
+
+As part of the improvement effort, Go 1.10 introduced a new compiler
+flag <code>-dwarflocationlists</code>. The flag causes the compiler to
+add location lists that helps debuggers work with optimized binaries.
+The following command builds a package with optimizations but with
+the DWARF location lists:
+
+<p>
+<pre>
+$ go build -gcflags="-dwarflocationlists=true"
+</pre>
+</p>
+
+<p><strong>What’s the recommended debugger user interface?</strong></p>
+
+<p>
+Even though both delve and gdb provides CLIs, most editor integrations
+and IDEs provides debugging-specific user interfaces.
+</p>
+
+<p><strong>Is it possible to do postmortem debugging with Go programs?</strong></p>
+
+<p>
+A core dump file is a file that contains the memory dump of a running
+process and its process status. It is primarily used for post-mortem
+debugging of a program and to understand its state
+while it is still running. These two cases make debugging of core
+dumps a good diagnostic aid to postmortem and analyze production
+services. It is possible to obtain core files from Go programs and
+use delve or gdb to debug, see the
+<a href="https://golang.org/wiki/CoreDumpDebugging">core dump debugging</a>
+page for a step-by-step guide.
+</p>
+
+<h2 id="runtime">Runtime statistics and events</h2>
+
+<p>
+The runtime provides stats and reporting of internal events for
+users to diagnose performance and utilization problems at the
+runtime level.
+</p>
+
+<p>
+Users can monitor these stats to better understand the overall
+health and performance of Go programs.
+Some frequently monitored stats and states:
+</p>
+
+<ul>
+<li><code><a href="/pkg/runtime/#ReadMemStats">runtime.ReadMemStats</a></code>
+reports the metrics related to heap
+allocation and garbage collection. Memory stats are useful for
+monitoring how much memory resources a process is consuming,
+whether the process can utilize memory well, and to catch
+memory leaks.</li>
+<li><code><a href="/pkg/runtime/debug/#ReadGCStats">debug.ReadGCStats</a></code>
+reads statistics about garbage collection.
+It is useful to see how much of the resources are spent on GC pauses.
+It also reports a timeline of garbage collector pauses and pause time percentiles.</li>
+<li><code><a href="/pkg/runtime/debug/#Stack">debug.Stack</a></code>
+returns the current stack trace. Stack trace
+is useful to see how many goroutines are currently running,
+what they are doing, and whether they are blocked or not.</li>
+<li><code><a href="/pkg/runtime/debug/#WriteHeapDump">debug.WriteHeapDump</a></code>
+suspends the execution of all goroutines
+and allows you to dump the heap to a file. A heap dump is a
+snapshot of a Go process' memory at a given time. It contains all
+allocated objects as well as goroutines, finalizers, and more.</li>
+<li><code><a href="/pkg/runtime#NumGoroutine">runtime.NumGoroutine</a></code>
+returns the number of current goroutines.
+The value can be monitored to see whether enough goroutines are
+utilized, or to detect goroutine leaks.</li>
+</ul>
+
+<h3 id="execution-tracer">Execution tracer</h3>
+
+<p>Go comes with a runtime execution tracer to capture a wide range
+of runtime events. Scheduling, syscall, garbage collections,
+heap size, and other events are collected by runtime and available
+for visualization by the go tool trace. Execution tracer is a tool
+to detect latency and utilization problems. You can examine how well
+the CPU is utilized, and when networking or syscalls are a cause of
+preemption for the goroutines.</p>
+
+<p>Tracer is useful to:</p>
+<ul>
+<li>Understand how your goroutines execute.</li>
+<li>Understand some of the core runtime events such as GC runs.</li>
+<li>Identify poorly parallelized execution.</li>
+</ul>
+
+<p>However, it is not great for identifying hot spots such as
+analyzing the cause of excessive memory or CPU usage.
+Use profiling tools instead first to address them.</p>
+
+<p>
+<img width="800" src="https://storage.googleapis.com/golangorg-assets/tracer-lock.png">
+</p>
+
+<p>Above, the go tool trace visualization shows the execution started
+fine, and then it became serialized. It suggests that there might
+be lock contention for a shared resource that creates a bottleneck.</p>
+
+<p>See <a href="https://golang.org/cmd/trace/"><code>go</code> <code>tool</code> <code>trace</code></a>
+to collect and analyze runtime traces.
+</p>
+
+<h3 id="godebug">GODEBUG</h3>
+
+<p>Runtime also emits events and information if
+<a href="https://golang.org/pkg/runtime/#hdr-Environment_Variables">GODEBUG</a>
+environmental variable is set accordingly.</p>
+
+<ul>
+<li>GODEBUG=gctrace=1 prints garbage collector events at
+each collection, summarizing the amount of memory collected
+and the length of the pause.</li>
+<li>GODEBUG=schedtrace=X prints scheduling events every X milliseconds.</li>
+</ul>
diff --git a/doc/docs.html b/doc/docs.html
index 92392e2..21a9a63 100644
--- a/doc/docs.html
+++ b/doc/docs.html
@@ -1,6 +1,7 @@
<!--{
"Title": "Documentation",
- "Path": "/doc/"
+ "Path": "/doc/",
+ "Template": true
}-->
<p>
@@ -33,28 +34,37 @@
<img class="gopher" src="/doc/gopher/doc.png"/>
-<h3 id="go_tour"><a href="//tour.golang.org/">A Tour of Go</a></h3>
+<h3 id="go_tour">
+ {{if $.GoogleCN}}
+ A Tour of Go
+ {{else}}
+ <a href="//tour.golang.org/">A Tour of Go</a>
+ {{end}}
+</h3>
<p>
An interactive introduction to Go in three sections.
The first section covers basic syntax and data structures; the second discusses
methods and interfaces; and the third introduces Go's concurrency primitives.
Each section concludes with a few exercises so you can practice what you've
-learned. You can <a href="//tour.golang.org/">take the tour online</a> or
-install it locally with:
+learned. You can {{if not $.GoogleCN}}<a href="//tour.golang.org/">take the tour
+online</a> or{{end}} install it locally with:
</p>
-<p>
<pre>
$ go get golang.org/x/tour/gotour
</pre>
+<p>
This will place the <code>gotour</code> binary in your workspace's <code>bin</code> directory.
</p>
<h3 id="code"><a href="code.html">How to write Go code</a></h3>
<p>
-Also available as a
-<a href="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>, this doc
-explains how to use the <a href="/cmd/go/">go command</a> to fetch, build, and
-install packages, commands, and run tests.
+{{if not $.GoogleCN}}
+Also available as a <a href="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>, this
+{{else}}
+This
+{{end}}
+doc explains how to use the <a href="/cmd/go/">go command</a>
+to fetch, build, and install packages, commands, and run tests.
</p>
<h3 id="editors"><a href="editors.html">Editor plugins and IDEs</a></h3>
@@ -70,6 +80,11 @@
the language specification, both of which should be read first.
</p>
+<h3 id="diagnostics"><a href="/doc/diagnostics.html">Diagnostics</a></h3>
+<p>
+Summarizes tools and methodologies to diagnose problems in Go programs.
+</p>
+
<h3 id="faq"><a href="/doc/faq">Frequently Asked Questions (FAQ)</a></h3>
<p>
Answers to common questions about Go.
@@ -115,9 +130,11 @@
<h2 id="articles">Articles</h2>
+{{if not $.GoogleCN}}
<h3 id="blog"><a href="//blog.golang.org/">The Go Blog</a></h3>
<p>The official blog of the Go project, featuring news and in-depth articles by
the Go team and guests.</p>
+{{end}}
<h4>Codewalks</h4>
<p>
@@ -130,6 +147,7 @@
<li><a href="/doc/articles/wiki/">Writing Web Applications</a> - building a simple web application.</li>
</ul>
+{{if not $.GoogleCN}}
<h4>Language</h4>
<ul>
<li><a href="/blog/json-rpc-tale-of-interfaces">JSON-RPC: a tale of interfaces</a></li>
@@ -150,17 +168,20 @@
<li><a href="/blog/go-image-package">The Go image package</a> - the fundamentals of the <a href="/pkg/image/">image</a> package.</li>
<li><a href="/blog/go-imagedraw-package">The Go image/draw package</a> - the fundamentals of the <a href="/pkg/image/draw/">image/draw</a> package.</li>
</ul>
+{{end}}
<h4>Tools</h4>
<ul>
<li><a href="/doc/articles/go_command.html">About the Go command</a> - why we wrote it, what it is, what it's not, and how to use it.</li>
-<li><a href="/blog/c-go-cgo">C? Go? Cgo!</a> - linking against C code with <a href="/cmd/cgo/">cgo</a>.</li>
<li><a href="/doc/gdb">Debugging Go Code with GDB</a></li>
+<li><a href="/doc/articles/race_detector.html">Data Race Detector</a> - a manual for the data race detector.</li>
+<li><a href="/doc/asm">A Quick Guide to Go's Assembler</a> - an introduction to the assembler used by Go.</li>
+{{if not $.GoogleCN}}
+<li><a href="/blog/c-go-cgo">C? Go? Cgo!</a> - linking against C code with <a href="/cmd/cgo/">cgo</a>.</li>
<li><a href="/blog/godoc-documenting-go-code">Godoc: documenting Go code</a> - writing good documentation for <a href="/cmd/godoc/">godoc</a>.</li>
<li><a href="/blog/profiling-go-programs">Profiling Go Programs</a></li>
-<li><a href="/doc/articles/race_detector.html">Data Race Detector</a> - a manual for the data race detector.</li>
<li><a href="/blog/race-detector">Introducing the Go Race Detector</a> - an introduction to the race detector.</li>
-<li><a href="/doc/asm">A Quick Guide to Go's Assembler</a> - an introduction to the assembler used by Go.</li>
+{{end}}
</ul>
<h4 id="articles_more">More</h4>
@@ -169,7 +190,7 @@
<a href="/wiki">Wiki</a> for more Go articles.
</p>
-
+{{if not $.GoogleCN}}
<h2 id="talks">Talks</h2>
<img class="gopher" src="/doc/gopher/talks.png"/>
@@ -200,7 +221,7 @@
<p>
See the <a href="/talks">Go Talks site</a> and <a href="/wiki/GoTalks">wiki page</a> for more Go talks.
</p>
-
+{{end}}
<h2 id="nonenglish">Non-English Documentation</h2>
diff --git a/doc/editors.html b/doc/editors.html
index 264f5af..617a100 100644
--- a/doc/editors.html
+++ b/doc/editors.html
@@ -22,8 +22,8 @@
<li><a href="https://github.com/fatih/vim-go">vim</a>: vim-go plugin provides Go programming language support</li>
<li><a href="https://marketplace.visualstudio.com/items?itemName=lukehoban.Go">Visual Studio Code</a>:
Go extension provides support for the Go programming language</li>
-<li><a href="https://www.jetbrains.com/go">Gogland</a>: Gogland is distributed either as a standalone IDE
-or as a plugin for the commercial IntelliJ Platform IDEs</li>
+<li><a href="https://www.jetbrains.com/go">GoLand</a>: GoLand is distributed either as a standalone IDE
+or as a plugin for IntelliJ IDEA Ultimate</li>
<li><a href="https://atom.io/packages/go-plus">Atom</a>: Go-Plus is an Atom package that provides enhanced Go support</li>
</ul>
@@ -33,199 +33,3 @@
<a href="https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins">IDEs and text editor plugins</a>
is available at the Wiki.
</p>
-
-<p>
-Each development environment integrates a number of Go-specific tools.
-The following feature matrix lists and compares the most significant features.
-</p>
-
-<table class="features-matrix">
- <tr>
- <th></th>
- <th><img title="Vim Go" src="/doc/editors/vimgo.png"><br>vim</th>
- <th><img title="Visual Studio Code" src="/doc/editors/vscodego.png"><br>Visual Studio Code</th>
- <th><img title="Gogland" src="/doc/editors/gogland.png"><br>Gogland</th>
- <th><img title="Go-Plus" src="/doc/editors/go-plus.png"><br>Atom</th>
- </tr>
- <tr>
- <td class="feature-row" colspan="5">Editing features</td>
- </tr>
- <tr>
- <td>Build and run from the editor/IDE</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- </tr>
- <tr>
- <td>Autocompletion of identifers (variable, method, and function names)</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- </tr>
- <tr>
- <td>Type-aware autocompletion</td>
- <td class="no">No</td>
- <td class="no">No</td>
- <td class="yes">Yes</td>
- <td class="no">No</td>
- </tr>
- <tr>
- <td>Rename identifiers</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- </tr>
- <tr>
- <td>Auto format, build, vet, and lint on save</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes<sup>1</sup></td>
- <td class="yes">Yes</td>
- </tr>
- <tr>
- <td>Auto insert import paths and remove unused on save</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes<sup>2</sup></td>
- <td class="yes">Yes</td>
- </tr>
- <tr>
- <td>Auto generate JSON, XML tags for struct fields</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- </tr>
- <tr>
- <td class="feature-row" colspan="5">Navigation features</td>
- </tr>
- <tr>
- <td>Display documentation inline, or open godoc in browser</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- </tr>
- <tr>
- <td>Switch between <code>*.go</code> and <code>*_test.go</code> file</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">No</td>
- </tr>
- <tr>
- <td>Jump to definition and referees</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- </tr>
- <tr>
- <td>Look up for interface implementations</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- </tr>
- <tr>
- <td>Search for callers and callees</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- </tr>
- <tr>
- <td class="feature-row" colspan="5">Testing and debugging features</td>
- </tr>
- <tr>
- <td>Debugger support</td>
- <td class="no">No</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes<sup>3</sup></td>
-
- </tr>
- <tr>
- <td>Run a single test case, all tests from file, or all tests from a package</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="no">No</td>
- </tr>
- <tr>
- <td>Auto generate tests for packages, files and identifiers</td>
- <td class="no">No</td>
- <td class="yes">Yes</td>
- <td class="no">No</td>
- <td class="no">No</td>
- </tr>
- <tr>
- <td>Debug tests</td>
- <td class="no">No</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes<sup>3</sup></td>
- </tr>
- <tr>
- <td>Display test coverage</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- <td class="yes">Yes</td>
- </tr>
- <tr class="download">
- <td></td>
- <td><a href="https://github.com/fatih/vim-go">Install<a/></td>
- <td><a href="https://marketplace.visualstudio.com/items?itemName=lukehoban.Go">Install<a/></td>
- <td><a href="https://www.jetbrains.com/go">Install<a/></td>
- <td><a href="https://atom.io/packages/go-plus">Install</a></td>
- </tr>
-</table>
-
-<p>
-<sup>1</sup>Possible when enabled via Settings > Go > On Save, <code>go</code> <code>vet</code> and <code>golint</code> are available via plugins. Also runs tests on save if configured.
-<br>
-<sup>2</sup>Additionally, user input can disambiguate when two or more options are available.
-<br>
-<sup>3</sup>Available if the <a href="https://atom.io/packages/go-debug">go-debug</a> package is installed.
-</p>
-
-</div>
-
-<style>
-.features-matrix {
- min-width: 800px;
- border-collapse: collapse;
-}
-.features-matrix th {
- width: 60px;
- text-align: center;
- font-size: 14px;
- color: #666;
-}
-.features-matrix th img {
- width: 48px;
-}
-.features-matrix .yes {
- text-align: center;
-}
-.features-matrix .no {
- text-align: center;
- background-color: #ffe9e9;
-}
-.features-matrix .download {
- font-weight: bold;
- text-align: center;
-}
-.features-matrix td {
- padding: 11px 5px 11px 5px;
- border-bottom: solid 1px #ebebeb;
-}
-.features-matrix .feature-row {
- background-color: #ebebeb;
- font-weight: bold;
-}
-</style>
diff --git a/doc/editors/go-plus.png b/doc/editors/go-plus.png
deleted file mode 100644
index c09c7fe..0000000
--- a/doc/editors/go-plus.png
+++ /dev/null
Binary files differ
diff --git a/doc/editors/gogland.png b/doc/editors/gogland.png
deleted file mode 100644
index 842f089..0000000
--- a/doc/editors/gogland.png
+++ /dev/null
Binary files differ
diff --git a/doc/editors/vimgo.png b/doc/editors/vimgo.png
deleted file mode 100644
index cf317ef..0000000
--- a/doc/editors/vimgo.png
+++ /dev/null
Binary files differ
diff --git a/doc/editors/vscodego.png b/doc/editors/vscodego.png
deleted file mode 100644
index 4e6c7b8..0000000
--- a/doc/editors/vscodego.png
+++ /dev/null
Binary files differ
diff --git a/doc/effective_go.html b/doc/effective_go.html
index bc70b0c..61de824 100644
--- a/doc/effective_go.html
+++ b/doc/effective_go.html
@@ -1431,9 +1431,7 @@
slice = newSlice
}
slice = slice[0:l+len(data)]
- for i, c := range data {
- slice[l+i] = c
- }
+ copy(slice[l:], data)
return slice
}
</pre>
@@ -1521,7 +1519,7 @@
<p>
Maps are a convenient and powerful built-in data structure that associate
values of one type (the <em>key</em>) with values of another type
-(the <em>element</em> or <em>value</em>)
+(the <em>element</em> or <em>value</em>).
The key can be of any type for which the equality operator is defined,
such as integers,
floating point and complex numbers,
@@ -2792,7 +2790,7 @@
<p>
If we need to refer to an embedded field directly, the type name of the field,
ignoring the package qualifier, serves as a field name, as it did
-in the <code>Read</code> method of our <code>ReaderWriter</code> struct.
+in the <code>Read</code> method of our <code>ReadWriter</code> struct.
Here, if we needed to access the
<code>*log.Logger</code> of a <code>Job</code> variable <code>job</code>,
we would write <code>job.Logger</code>,
diff --git a/doc/gccgo_install.html b/doc/gccgo_install.html
index 4f6a911..d4eac12 100644
--- a/doc/gccgo_install.html
+++ b/doc/gccgo_install.html
@@ -59,10 +59,17 @@
</p>
<p>
-The GCC 7 releases are expected to include a complete implementation
-of the Go 1.8 user libraries. As with earlier releases, the Go 1.8
-runtime is not fully merged, but that should not be visible to Go
-programs.
+The GCC 7 releases include a complete implementation of the Go 1.8.1
+user libraries. As with earlier releases, the Go 1.8 runtime is not
+fully merged, but that should not be visible to Go programs.
+</p>
+
+<p>
+The GCC 8 releases are expected to include a complete implementation
+of the Go 1.10 release, depending on release timing. The Go 1.10
+runtime has now been fully merged into the GCC development sources,
+and concurrent garbage collection is expected to be fully supported in
+GCC 8.
</p>
<h2 id="Source_code">Source code</h2>
diff --git a/doc/go1.1.html b/doc/go1.1.html
index f059fd7..f615c97 100644
--- a/doc/go1.1.html
+++ b/doc/go1.1.html
@@ -166,7 +166,7 @@
<h3 id="gc_flag">Command-line flag parsing</h3>
<p>
-In the gc tool chain, the compilers and linkers now use the
+In the gc toolchain, the compilers and linkers now use the
same command-line flag parsing rules as the Go flag package, a departure
from the traditional Unix flag parsing. This may affect scripts that invoke
the tool directly.
@@ -305,7 +305,7 @@
<p>
Due to the change of the <a href="#int"><code>int</code></a> to 64 bits and
a new internal <a href="//golang.org/s/go11func">representation of functions</a>,
-the arrangement of function arguments on the stack has changed in the gc tool chain.
+the arrangement of function arguments on the stack has changed in the gc toolchain.
Functions written in assembly will need to be revised at least
to adjust frame pointer offsets.
</p>
@@ -395,7 +395,7 @@
The <a href="/cmd/fix/"><code>fix</code></a> command, usually run as
<code>go fix</code>, no longer applies fixes to update code from
before Go 1 to use Go 1 APIs.
-To update pre-Go 1 code to Go 1.1, use a Go 1.0 tool chain
+To update pre-Go 1 code to Go 1.1, use a Go 1.0 toolchain
to convert the code to Go 1.0 first.
</p>
@@ -427,7 +427,7 @@
<h3 id="platforms">Additional platforms</h3>
<p>
-The Go 1.1 tool chain adds experimental support for <code>freebsd/arm</code>,
+The Go 1.1 toolchain adds experimental support for <code>freebsd/arm</code>,
<code>netbsd/386</code>, <code>netbsd/amd64</code>, <code>netbsd/arm</code>,
<code>openbsd/386</code> and <code>openbsd/amd64</code> platforms.
</p>
diff --git a/doc/go1.10.html b/doc/go1.10.html
new file mode 100644
index 0000000..4c0e847
--- /dev/null
+++ b/doc/go1.10.html
@@ -0,0 +1,1448 @@
+<!--{
+ "Title": "Go 1.10 Release Notes",
+ "Path": "/doc/go1.10",
+ "Template": true
+}-->
+
+<!--
+NOTE: In this document and others in this directory, the convention is to
+set fixed-width phrases with non-fixed-width spaces, as in
+<code>hello</code> <code>world</code>.
+Do not send CLs removing the interior tags from such phrases.
+-->
+
+<style>
+ul li { margin: 0.5em 0; }
+</style>
+
+<h2 id="introduction">Introduction to Go 1.10</h2>
+
+<p>
+The latest Go release, version 1.10, arrives six months after <a href="go1.9">Go 1.9</a>.
+Most of its changes are in the implementation of the toolchain, runtime, and libraries.
+As always, the release maintains the Go 1 <a href="/doc/go1compat.html">promise of compatibility</a>.
+We expect almost all Go programs to continue to compile and run as before.
+</p>
+
+<p>
+This release improves <a href="#build">caching of built packages</a>,
+adds <a href="#test">caching of successful test results</a>,
+runs <a href="#test-vet">vet automatically during tests</a>,
+and
+permits <a href="#cgo">passing string values directly between Go and C using cgo</a>.
+A new <a href="#cgo">compiler option whitelist</a> may cause
+unexpected <a href="https://golang.org/s/invalidflag"><code>invalid
+flag</code></a> errors in code that built successfully with older
+releases.
+</p>
+
+<h2 id="language">Changes to the language</h2>
+
+<p>
+There are no significant changes to the language specification.
+</p>
+
+<p><!-- CL 60230 -->
+A corner case involving shifts by untyped constants has been clarified,
+and as a result the compilers have been updated to allow the index expression
+<code>x[1.0</code> <code><<</code> <code>s]</code> where <code>s</code> is an untyped constant;
+the <a href="/pkg/go/types/">go/types</a> package already did.
+</p>
+
+<p><!-- CL 73233 -->
+The grammar for method expressions has been updated to relax the
+syntax to allow any type expression as a receiver;
+this matches what the compilers were already implementing.
+For example, <code>struct{io.Reader}.Read</code> is a valid, if unusual,
+method expression that the compilers already accepted and is
+now permitted by the language grammar.
+</p>
+
+<h2 id="ports">Ports</h2>
+
+<p>
+There are no new supported operating systems or processor architectures in this release.
+Most of the work has focused on strengthening the support for existing ports,
+in particular <a href="#asm">new instructions in the assembler</a>
+and improvements to the code generated by the compilers.
+</p>
+
+<p id="freebsd">
+As <a href="go1.9#freebsd">announced in the Go 1.9 release notes</a>,
+Go 1.10 now requires FreeBSD 10.3 or later;
+support for FreeBSD 9.3 has been removed.
+</p>
+
+<p id="netbsd">
+Go now runs on NetBSD again but requires the unreleased NetBSD 8.
+Only <code>GOARCH</code> <code>amd64</code> and <code>386</code> have
+been fixed. The <code>arm</code> port is still broken.
+</p>
+
+<p id="mips">
+On 32-bit MIPS systems, the new environment variable settings
+<code>GOMIPS=hardfloat</code> (the default) and
+<code>GOMIPS=softfloat</code> select whether to use
+hardware instructions or software emulation for floating-point computations.
+</p>
+
+<p id="openbsd">
+Go 1.10 is the last release that will run on OpenBSD 6.0.
+Go 1.11 will require OpenBSD 6.2.
+</p>
+
+<p id="darwin">
+Go 1.10 is the last release that will run on OS X 10.8 Mountain Lion or OS X 10.9 Mavericks.
+Go 1.11 will require OS X 10.10 Yosemite or later.
+</p>
+
+<p id="windows">
+Go 1.10 is the last release that will run on Windows XP or Windows Vista.
+Go 1.11 will require Windows 7 or later.
+</p>
+
+<h2 id="tools">Tools</h2>
+
+<h3 id="goroot">Default GOROOT & GOTMPDIR</h3>
+
+<p>
+If the environment variable <code>$GOROOT</code> is unset,
+the go tool previously used the default <code>GOROOT</code>
+set during toolchain compilation.
+Now, before falling back to that default, the go tool attempts to
+deduce <code>GOROOT</code> from its own executable path.
+This allows binary distributions to be unpacked anywhere in the
+file system and then be used without setting <code>GOROOT</code>
+explicitly.
+</p>
+
+<p>
+By default, the go tool creates its temporary files and directories
+in the system temporary directory (for example, <code>$TMPDIR</code> on Unix).
+If the new environment variable <code>$GOTMPDIR</code> is set,
+the go tool will creates its temporary files and directories in that directory instead.
+</p>
+
+<h3 id="build">Build & Install</h3>
+
+<p>
+The <code>go</code> <code>build</code> command now detects out-of-date packages
+purely based on the content of source files, specified build flags, and metadata stored in the compiled packages.
+Modification times are no longer consulted or relevant.
+The old advice to add <code>-a</code> to force a rebuild in cases where
+the modification times were misleading for one reason or another
+(for example, changes in build flags) is no longer necessary:
+builds now always detect when packages must be rebuilt.
+(If you observe otherwise, please file a bug.)
+</p>
+
+<p>
+The <code>go</code> <code>build</code> <code>-asmflags</code>, <code>-gcflags</code>, <code>-gccgoflags</code>, and <code>-ldflags</code> options
+now apply by default only to the packages listed directly on the command line.
+For example, <code>go</code> <code>build</code> <code>-gcflags=-m</code> <code>mypkg</code>
+passes the compiler the <code>-m</code> flag when building <code>mypkg</code>
+but not its dependencies.
+The new, more general form <code>-asmflags=pattern=flags</code> (and similarly for the others)
+applies the <code>flags</code> only to the packages matching the pattern.
+For example: <code>go</code> <code>install</code> <code>-ldflags=cmd/gofmt=-X=main.version=1.2.3</code> <code>cmd/...</code>
+installs all the commands matching <code>cmd/...</code> but only applies the <code>-X</code> option
+to the linker flags for <code>cmd/gofmt</code>.
+For more details, see <a href="/cmd/go/#hdr-Compile_packages_and_dependencies"><code>go</code> <code>help</code> <code>build</code></a>.
+</p>
+
+<p>
+The <code>go</code> <code>build</code> command now maintains a cache of
+recently built packages, separate from the installed packages in <code>$GOROOT/pkg</code> or <code>$GOPATH/pkg</code>.
+The effect of the cache should be to speed builds that do not explicitly install packages
+or when switching between different copies of source code (for example, when changing
+back and forth between different branches in a version control system).
+The old advice to add the <code>-i</code> flag for speed, as in <code>go</code> <code>build</code> <code>-i</code>
+or <code>go</code> <code>test</code> <code>-i</code>,
+is no longer necessary: builds run just as fast without <code>-i</code>.
+For more details, see <a href="/cmd/go/#hdr-Build_and_test_caching"><code>go</code> <code>help</code> <code>cache</code></a>.
+</p>
+
+<p>
+The <code>go</code> <code>install</code> command now installs only the
+packages and commands listed directly on the command line.
+For example, <code>go</code> <code>install</code> <code>cmd/gofmt</code>
+installs the gofmt program but not any of the packages on which it depends.
+The new build cache makes future commands still run as quickly as if the
+dependencies had been installed.
+To force the installation of dependencies, use the new
+<code>go</code> <code>install</code> <code>-i</code> flag.
+Installing dependency packages should not be necessary in general,
+and the very concept of installed packages may disappear in a future release.
+</p>
+
+<p>
+Many details of the <code>go</code> <code>build</code> implementation have changed to support these improvements.
+One new requirement implied by these changes is that
+binary-only packages must now declare accurate import blocks in their
+stub source code, so that those imports can be made available when
+linking a program using the binary-only package.
+For more details, see <a href="/cmd/go/#hdr-File_types"><code>go</code> <code>help</code> <code>filetype</code></a>.
+</p>
+
+<h3 id="test">Test</h3>
+
+<p>
+The <code>go</code> <code>test</code> command now caches test results:
+if the test executable and command line match a previous run
+and the files and environment variables consulted by that run
+have not changed either, <code>go</code> <code>test</code> will print
+the previous test output, replacing the elapsed time with the string “(cached).”
+Test caching applies only to successful test results;
+only to <code>go</code> <code>test</code>
+commands with an explicit list of packages; and
+only to command lines using a subset of the
+<code>-cpu</code>, <code>-list</code>, <code>-parallel</code>,
+<code>-run</code>, <code>-short</code>, and <code>-v</code> test flags.
+The idiomatic way to bypass test caching is to use <code>-count=1</code>.
+</p>
+
+<p id="test-vet">
+The <code>go</code> <code>test</code> command now automatically runs
+<code>go</code> <code>vet</code> on the package being tested,
+to identify significant problems before running the test.
+Any such problems are treated like build errors and prevent execution of the test.
+Only a high-confidence subset of the available <code>go</code> <code>vet</code>
+checks are enabled for this automatic check.
+To disable the running of <code>go</code> <code>vet</code>, use
+<code>go</code> <code>test</code> <code>-vet=off</code>.
+</p>
+
+<p>
+The <code>go</code> <code>test</code> <code>-coverpkg</code> flag now
+interprets its argument as a comma-separated list of patterns to match against
+the dependencies of each test, not as a list of packages to load anew.
+For example, <code>go</code> <code>test</code> <code>-coverpkg=all</code>
+is now a meaningful way to run a test with coverage enabled for the test package
+and all its dependencies.
+Also, the <code>go</code> <code>test</code> <code>-coverprofile</code> option is now
+supported when running multiple tests.
+</p>
+
+<p>
+In case of failure due to timeout, tests are now more likely to write their profiles before exiting.
+</p>
+
+<p>
+The <code>go</code> <code>test</code> command now always
+merges the standard output and standard error from a given test binary execution
+and writes both to <code>go</code> <code>test</code>'s standard output.
+In past releases, <code>go</code> <code>test</code> only applied this
+merging most of the time.
+</p>
+
+<p>
+The <code>go</code> <code>test</code> <code>-v</code> output
+now includes <code>PAUSE</code> and <code>CONT</code> status update
+lines to mark when <a href="/pkg/testing/#T.Parallel">parallel tests</a> pause and continue.
+</p>
+
+<p>
+The new <code>go</code> <code>test</code> <code>-failfast</code> flag
+disables running additional tests after any test fails.
+Note that tests running in parallel with the failing test are allowed to complete.
+</p>
+
+<p>
+Finally, the new <code>go</code> <code>test</code> <code>-json</code> flag
+filters test output through the new command
+<code>go</code> <code>tool</code> <code>test2json</code>
+to produce a machine-readable JSON-formatted description of test execution.
+This allows the creation of rich presentations of test execution
+in IDEs and other tools.
+</p>
+
+
+<p>
+For more details about all these changes,
+see <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>help</code> <code>test</code></a>
+and the <a href="/cmd/test2json/">test2json documentation</a>.
+</p>
+
+<h3 id="cgo">Cgo</h3>
+
+<p>
+Options specified by cgo using <code>#cgo CFLAGS</code> and the like
+are now checked against a whitelist of permitted options.
+This closes a security hole in which a downloaded package uses
+compiler options like
+<span style="white-space: nowrap"><code>-fplugin</code></span>
+to run arbitrary code on the machine where it is being built.
+This can cause a build error such as <code>invalid flag in #cgo CFLAGS</code>.
+For more background, and how to handle this error, see
+<a href="https://golang.org/s/invalidflag">https://golang.org/s/invalidflag</a>.
+</p>
+
+<p>
+Cgo now implements a C typedef like “<code>typedef</code> <code>X</code> <code>Y</code>” using a Go type alias,
+so that Go code may use the types <code>C.X</code> and <code>C.Y</code> interchangeably.
+It also now supports the use of niladic function-like macros.
+Also, the documentation has been updated to clarify that
+Go structs and Go arrays are not supported in the type signatures of cgo-exported functions.
+</p>
+
+<p>
+Cgo now supports direct access to Go string values from C.
+Functions in the C preamble may use the type <code>_GoString_</code>
+to accept a Go string as an argument.
+C code may call <code>_GoStringLen</code> and <code>_GoStringPtr</code>
+for direct access to the contents of the string.
+A value of type <code>_GoString_</code>
+may be passed in a call to an exported Go function that takes an argument of Go type <code>string</code>.
+</p>
+
+<p>
+During toolchain bootstrap, the environment variables <code>CC</code> and <code>CC_FOR_TARGET</code> specify
+the default C compiler that the resulting toolchain will use for host and target builds, respectively.
+However, if the toolchain will be used with multiple targets, it may be necessary to specify a different C compiler for each
+(for example, a different compiler for <code>darwin/arm64</code> versus <code>linux/ppc64le</code>).
+The new set of environment variables <code>CC_FOR_<i>goos</i>_<i>goarch</i></code>
+allows specifying a different default C compiler for each target.
+Note that these variables only apply during toolchain bootstrap,
+to set the defaults used by the resulting toolchain.
+Later <code>go</code> <code>build</code> commands use the <code>CC</code> environment
+variable or else the built-in default.
+</p>
+
+<p>
+Cgo now translates some C types that would normally map to a pointer
+type in Go, to a <code>uintptr</code> instead. These types include
+the <code>CFTypeRef</code> hierarchy in Darwin's CoreFoundation
+framework and the <code>jobject</code> hierarchy in Java's JNI
+interface.
+</p>
+
+<p>
+These types must be <code>uintptr</code> on the Go side because they
+would otherwise confuse the Go garbage collector; they are sometimes
+not really pointers but data structures encoded in a pointer-sized integer.
+Pointers to Go memory must not be stored in these <code>uintptr</code> values.
+</p>
+
+<p>
+Because of this change, values of the affected types need to be
+zero-initialized with the constant <code>0</code> instead of the
+constant <code>nil</code>. Go 1.10 provides <code>gofix</code>
+modules to help with that rewrite:
+</p>
+
+<pre>
+go tool fix -r cftype <pkg>
+go tool fix -r jni <pkg>
+</pre>
+
+<p>
+For more details, see the <a href="/cmd/cgo/">cgo documentation</a>.
+</p>
+
+<h3 id="doc">Doc</h3>
+
+<p>
+The <code>go</code> <code>doc</code> tool now adds functions returning slices of <code>T</code> or <code>*T</code>
+to the display of type <code>T</code>, similar to the existing behavior for functions returning single <code>T</code> or <code>*T</code> results.
+For example:
+</p>
+
+<pre>
+$ go doc mail.Address
+package mail // import "net/mail"
+
+type Address struct {
+ Name string
+ Address string
+}
+ Address represents a single mail address.
+
+func ParseAddress(address string) (*Address, error)
+func ParseAddressList(list string) ([]*Address, error)
+func (a *Address) String() string
+$
+</pre>
+
+<p>
+Previously, <code>ParseAddressList</code> was only shown in the package overview (<code>go</code> <code>doc</code> <code>mail</code>).
+</p>
+
+<h3 id="fix">Fix</h3>
+
+<p>
+The <code>go</code> <code>fix</code> tool now replaces imports of <code>"golang.org/x/net/context"</code>
+with <code>"context"</code>.
+(Forwarding aliases in the former make it completely equivalent to the latter when using Go 1.9 or later.)
+</p>
+
+<h3 id="get">Get</h3>
+
+<p>
+The <code>go</code> <code>get</code> command now supports Fossil source code repositories.
+</p>
+
+<h3 id="pprof">Pprof</h3>
+
+<p>
+The blocking and mutex profiles produced by the <code>runtime/pprof</code> package
+now include symbol information, so they can be viewed
+in <code>go</code> <code>tool</code> <code>pprof</code>
+without the binary that produced the profile.
+(All other profile types were changed to include symbol information in Go 1.9.)
+</p>
+
+<p>
+The <a href="/cmd/pprof/"><code>go</code> <code>tool</code> <code>pprof</code></a>
+profile visualizer has been updated to git version 9e20b5b (2017-11-08)
+from <a href="https://github.com/google/pprof">github.com/google/pprof</a>,
+which includes an updated web interface.
+</p>
+
+<h3 id="vet">Vet</h3>
+
+<p>
+The <a href="/cmd/vet/"><code>go</code> <code>vet</code></a> command now always has access to
+complete, up-to-date type information when checking packages, even for packages using cgo or vendored imports.
+The reports should be more accurate as a result.
+Note that only <code>go</code> <code>vet</code> has access to this information;
+the more low-level <code>go</code> <code>tool</code> <code>vet</code> does not
+and should be avoided except when working on <code>vet</code> itself.
+(As of Go 1.9, <code>go</code> <code>vet</code> provides access to all the same flags as
+<code>go</code> <code>tool</code> <code>vet</code>.)
+</p>
+
+<h3 id="diag">Diagnostics</h3>
+
+<p>
+This release includes a new <a href="/doc/diagnostics.html">overview of available Go program diagnostic tools</a>.
+</p>
+
+<h3 id="gofmt">Gofmt</h3>
+
+<p>
+Two minor details of the default formatting of Go source code have changed.
+First, certain complex three-index slice expressions previously formatted like
+<code>x[i+1</code> <code>:</code> <code>j:k]</code> and now
+format with more consistent spacing: <code>x[i+1</code> <code>:</code> <code>j</code> <code>:</code> <code>k]</code>.
+Second, single-method interface literals written on a single line,
+which are sometimes used in type assertions,
+are no longer split onto multiple lines.
+</p>
+
+<p>
+Note that these kinds of minor updates to gofmt are expected from time to time.
+In general, we recommend against building systems that check that source code
+matches the output of a specific version of gofmt.
+For example, a continuous integration test that fails if any code already checked into
+a repository is not “properly formatted” is inherently fragile and not recommended.
+</p>
+
+<p>
+If multiple programs must agree about which version of gofmt is used to format a source file,
+we recommend that they do this by arranging to invoke the same gofmt binary.
+For example, in the Go open source repository, our Git pre-commit hook is written in Go
+and could import <code>go/format</code> directly, but instead it invokes the <code>gofmt</code>
+binary found in the current path, so that the pre-commit hook need not be recompiled
+each time <code>gofmt</code> changes.
+</p>
+
+<h3 id="compiler">Compiler Toolchain</h3>
+
+<p>
+The compiler includes many improvements to the performance of generated code,
+spread fairly evenly across the supported architectures.
+</p>
+
+<p>
+The DWARF debug information recorded in binaries has been improved in a few ways:
+constant values are now recorded;
+line number information is more accurate, making source-level stepping through a program work better;
+and each package is now presented as its own DWARF compilation unit.
+</p>
+
+<p>
+The various <a href="https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit">build modes</a>
+have been ported to more systems.
+Specifically, <code>c-shared</code> now works on <code>linux/ppc64le</code>, <code>windows/386</code>, and <code>windows/amd64</code>;
+<code>pie</code> now works on <code>darwin/amd64</code> and also forces the use of external linking on all systems;
+and <code>plugin</code> now works on <code>linux/ppc64le</code> and <code>darwin/amd64</code>.
+</p>
+
+<p>
+The <code>linux/ppc64le</code> port now requires the use of external linking
+with any programs that use cgo, even uses by the standard library.
+</p>
+
+<h3 id="asm">Assembler</h3>
+
+<p>
+For the ARM 32-bit port, the assembler now supports the instructions
+<code><small>BFC</small></code>,
+<code><small>BFI</small></code>,
+<code><small>BFX</small></code>,
+<code><small>BFXU</small></code>,
+<code><small>FMULAD</small></code>,
+<code><small>FMULAF</small></code>,
+<code><small>FMULSD</small></code>,
+<code><small>FMULSF</small></code>,
+<code><small>FNMULAD</small></code>,
+<code><small>FNMULAF</small></code>,
+<code><small>FNMULSD</small></code>,
+<code><small>FNMULSF</small></code>,
+<code><small>MULAD</small></code>,
+<code><small>MULAF</small></code>,
+<code><small>MULSD</small></code>,
+<code><small>MULSF</small></code>,
+<code><small>NMULAD</small></code>,
+<code><small>NMULAF</small></code>,
+<code><small>NMULD</small></code>,
+<code><small>NMULF</small></code>,
+<code><small>NMULSD</small></code>,
+<code><small>NMULSF</small></code>,
+<code><small>XTAB</small></code>,
+<code><small>XTABU</small></code>,
+<code><small>XTAH</small></code>,
+and
+<code><small>XTAHU</small></code>.
+</p>
+
+<p>
+For the ARM 64-bit port, the assembler now supports the
+<code><small>VADD</small></code>,
+<code><small>VADDP</small></code>,
+<code><small>VADDV</small></code>,
+<code><small>VAND</small></code>,
+<code><small>VCMEQ</small></code>,
+<code><small>VDUP</small></code>,
+<code><small>VEOR</small></code>,
+<code><small>VLD1</small></code>,
+<code><small>VMOV</small></code>,
+<code><small>VMOVI</small></code>,
+<code><small>VMOVS</small></code>,
+<code><small>VORR</small></code>,
+<code><small>VREV32</small></code>,
+and
+<code><small>VST1</small></code>
+instructions.
+</p>
+
+<p>
+For the PowerPC 64-bit port, the assembler now supports the POWER9 instructions
+<code><small>ADDEX</small></code>,
+<code><small>CMPEQB</small></code>,
+<code><small>COPY</small></code>,
+<code><small>DARN</small></code>,
+<code><small>LDMX</small></code>,
+<code><small>MADDHD</small></code>,
+<code><small>MADDHDU</small></code>,
+<code><small>MADDLD</small></code>,
+<code><small>MFVSRLD</small></code>,
+<code><small>MTVSRDD</small></code>,
+<code><small>MTVSRWS</small></code>,
+<code><small>PASTECC</small></code>,
+<code><small>VCMPNEZB</small></code>,
+<code><small>VCMPNEZBCC</small></code>,
+and
+<code><small>VMSUMUDM</small></code>.
+</p>
+
+<p>
+For the S390X port, the assembler now supports the
+<code><small>TMHH</small></code>,
+<code><small>TMHL</small></code>,
+<code><small>TMLH</small></code>,
+and
+<code><small>TMLL</small></code>
+instructions.
+</p>
+
+<p>
+For the X86 64-bit port, the assembler now supports 359 new instructions,
+including the full AVX, AVX2, BMI, BMI2, F16C, FMA3, SSE2, SSE3, SSSE3, SSE4.1, and SSE4.2 extension sets.
+The assembler also no longer implements <code><small>MOVL</small></code> <code><small>$0,</small></code> <code><small>AX</small></code>
+as an <code><small>XORL</small></code> instruction,
+to avoid clearing the condition flags unexpectedly.
+</p>
+
+<h3 id="gccgo">Gccgo</h3>
+
+<p>
+Due to the alignment of Go's semiannual release schedule with GCC's
+annual release schedule,
+GCC release 7 contains the Go 1.8.3 version of gccgo.
+We expect that the next release, GCC 8, will contain the Go 1.10
+version of gccgo.
+</p>
+
+<h2 id="runtime">Runtime</h2>
+
+<p>
+The behavior of nested calls to
+<a href="/pkg/runtime/#LockOSThread"><code>LockOSThread</code></a> and
+<a href="/pkg/runtime/#UnlockOSThread"><code>UnlockOSThread</code></a>
+has changed.
+These functions control whether a goroutine is locked to a specific operating system thread,
+so that the goroutine only runs on that thread, and the thread only runs that goroutine.
+Previously, calling <code>LockOSThread</code> more than once in a row
+was equivalent to calling it once, and a single <code>UnlockOSThread</code>
+always unlocked the thread.
+Now, the calls nest: if <code>LockOSThread</code> is called multiple times,
+<code>UnlockOSThread</code> must be called the same number of times
+in order to unlock the thread.
+Existing code that was careful not to nest these calls will remain correct.
+Existing code that incorrectly assumed the calls nested will become correct.
+Most uses of these functions in public Go source code falls into the second category.
+</p>
+
+<p>
+Because one common use of <code>LockOSThread</code> and <code>UnlockOSThread</code>
+is to allow Go code to reliably modify thread-local state (for example, Linux or Plan 9 name spaces),
+the runtime now treats locked threads as unsuitable for reuse or for creating new threads.
+</p>
+
+<p>
+Stack traces no longer include implicit wrapper functions (previously marked <code><autogenerated></code>),
+unless a fault or panic happens in the wrapper itself.
+As a result, skip counts passed to functions like <a href="/pkg/runtime/#Caller"><code>Caller</code></a>
+should now always match the structure of the code as written, rather than depending on
+optimization decisions and implementation details.
+</p>
+
+<p>
+The garbage collector has been modified to reduce its impact on allocation latency.
+It now uses a smaller fraction of the overall CPU when running, but it may run more of the time.
+The total CPU consumed by the garbage collector has not changed significantly.
+</p>
+
+<p>
+The <a href="/pkg/runtime/#GOROOT"><code>GOROOT</code></a> function
+now defaults (when the <code>$GOROOT</code> environment variable is not set)
+to the <code>GOROOT</code> or <code>GOROOT_FINAL</code> in effect
+at the time the calling program was compiled.
+Previously it used the <code>GOROOT</code> or <code>GOROOT_FINAL</code> in effect
+at the time the toolchain that compiled the calling program was compiled.
+</p>
+
+<p>
+There is no longer a limit on the <a href="/pkg/runtime/#GOMAXPROCS"><code>GOMAXPROCS</code></a> setting.
+(In Go 1.9 the limit was 1024.)
+</p>
+
+<h2 id="performance">Performance</h2>
+
+<p>
+As always, the changes are so general and varied that precise
+statements about performance are difficult to make. Most programs
+should run a bit faster, due to speedups in the garbage collector,
+better generated code, and optimizations in the core library.
+</p>
+
+<h2 id="gc">Garbage Collector</h2>
+
+<p>
+Many applications should experience significantly lower allocation latency and overall performance overhead when the garbage collector is active.
+</p>
+
+<h2 id="library">Core library</h2>
+
+<p>
+All of the changes to the standard library are minor.
+The changes in <a href="#bytes">bytes</a>
+and <a href="#net/url">net/url</a> are the most likely to require updating of existing programs.
+</p>
+
+<h3 id="minor_library_changes">Minor changes to the library</h3>
+
+<p>
+As always, there are various minor changes and updates to the library,
+made with the Go 1 <a href="/doc/go1compat">promise of compatibility</a>
+in mind.
+</p>
+
+<dl id="archive/tar"><dt><a href="/pkg/archive/tar/">archive/tar</a></dt>
+<dd>
+<p>
+In general, the handling of special header formats is significantly improved and expanded.
+</p>
+<p>
+<a href="/pkg/archive/tar/#FileInfoHeader"><code>FileInfoHeader</code></a> has always
+recorded the Unix UID and GID numbers from its <a href="/pkg/os/#FileInfo"><code>os.FileInfo</code></a> argument
+(specifically, from the system-dependent information returned by the <code>FileInfo</code>'s <code>Sys</code> method)
+in the returned <a href="/pkg/archive/tar/#Header"><code>Header</code></a>.
+Now it also records the user and group names corresponding to those IDs,
+as well as the major and minor device numbers for device files.
+</p>
+<p>
+The new <a href="/pkg/archive/tar/#Header"><code>Header.Format</code></a> field
+of type <a href="/pkg/archive/tar/#Format"><code>Format</code></a>
+controls which tar header format the <a href="/pkg/archive/tar/#Writer"><code>Writer</code></a> uses.
+The default, as before, is to select the most widely-supported header type
+that can encode the fields needed by the header (USTAR if possible, or else PAX if possible, or else GNU).
+The <a href="/pkg/archive/tar/#Reader"><code>Reader</code></a> sets <code>Header.Format</code> for each header it reads.
+</p>
+<p>
+<code>Reader</code> and the <code>Writer</code> now support arbitrary PAX records,
+using the new <a href="/pkg/archive/tar/#Header"><code>Header.PAXRecords</code></a> field,
+a generalization of the existing <code>Xattrs</code> field.
+</p>
+<p>
+The <code>Reader</code> no longer insists that the file name or link name in GNU headers
+be valid UTF-8.
+</p>
+<p>
+When writing PAX- or GNU-format headers, the <code>Writer</code> now includes
+the <code>Header.AccessTime</code> and <code>Header.ChangeTime</code> fields (if set).
+When writing PAX-format headers, the times include sub-second precision.
+</p>
+</dl>
+
+<dl id="archive/zip"><dt><a href="/pkg/archive/zip/">archive/zip</a></dt>
+<dd>
+<p>
+Go 1.10 adds more complete support for times and character set encodings in ZIP archives.
+</p>
+<p>
+The original ZIP format used the standard MS-DOS encoding of year, month, day, hour, minute, and second into fields in two 16-bit values.
+That encoding cannot represent time zones or odd seconds, so multiple extensions have been
+introduced to allow richer encodings.
+In Go 1.10, the <a href="/pkg/archive/zip/#Reader"><code>Reader</code></a> and <a href="/pkg/archive/zip/#Writer"><code>Writer</code></a>
+now support the widely-understood Info-Zip extension that encodes the time separately in the 32-bit Unix “seconds since epoch” form.
+The <a href="/pkg/archive/zip/#FileHeader"><code>FileHeader</code></a>'s new <code>Modified</code> field of type <a href="/pkg/time/#Time"><code>time.Time</code></a>
+obsoletes the <code>ModifiedTime</code> and <code>ModifiedDate</code> fields, which continue to hold the MS-DOS encoding.
+The <code>Reader</code> and <code>Writer</code> now adopt the common
+convention that a ZIP archive storing a time zone-independent Unix time
+also stores the local time in the MS-DOS field,
+so that the time zone offset can be inferred.
+For compatibility, the <a href="/pkg/archive/zip/#FileHeader.ModTime"><code>ModTime</code></a> and
+<a href="/pkg/archive/zip/#FileHeader.SetModTime"><code>SetModTime</code></a> methods
+behave the same as in earlier releases; new code should use <code>Modified</code> directly.
+</p>
+<p>
+The header for each file in a ZIP archive has a flag bit indicating whether
+the name and comment fields are encoded as UTF-8, as opposed to a system-specific default encoding.
+In Go 1.8 and earlier, the <code>Writer</code> never set the UTF-8 bit.
+In Go 1.9, the <code>Writer</code> changed to set the UTF-8 bit almost always.
+This broke the creation of ZIP archives containing Shift-JIS file names.
+In Go 1.10, the <code>Writer</code> now sets the UTF-8 bit only when
+both the name and the comment field are valid UTF-8 and at least one is non-ASCII.
+Because non-ASCII encodings very rarely look like valid UTF-8, the new
+heuristic should be correct nearly all the time.
+Setting a <code>FileHeader</code>'s new <code>NonUTF8</code> field to true
+disables the heuristic entirely for that file.
+</p>
+<p>
+The <code>Writer</code> also now supports setting the end-of-central-directory record's comment field,
+by calling the <code>Writer</code>'s new <a href="/pkg/archive/zip/#Writer.SetComment"><code>SetComment</code></a> method.
+</p>
+</dl>
+
+<dl id="bufio"><dt><a href="/pkg/bufio/">bufio</a></dt>
+<dd>
+<p>
+The new <a href="/pkg/bufio/#Reader.Size"><code>Reader.Size</code></a>
+and <a href="/pkg/bufio/#Writer.Size"><code>Writer.Size</code></a>
+methods report the <code>Reader</code> or <code>Writer</code>'s underlying buffer size.
+</p>
+</dl>
+
+<dl id="bytes"><dt><a href="/pkg/bytes/">bytes</a></dt>
+<dd>
+<p>
+The
+<a href="/pkg/bytes/#Fields"><code>Fields</code></a>,
+<a href="/pkg/bytes/#FieldsFunc"><code>FieldsFunc</code></a>,
+<a href="/pkg/bytes/#Split"><code>Split</code></a>,
+and
+<a href="/pkg/bytes/#SplitAfter"><code>SplitAfter</code></a>
+functions have always returned subslices of their inputs.
+Go 1.10 changes each returned subslice to have capacity equal to its length,
+so that appending to one cannot overwrite adjacent data in the original input.
+</p>
+</dl>
+
+<dl id="crypto/cipher"><dt><a href="/pkg/crypto/cipher/">crypto/cipher</a></dt>
+<dd>
+<p>
+<a href="/pkg/crypto/cipher/#NewOFB"><code>NewOFB</code></a> now panics if given
+an initialization vector of incorrect length, like the other constructors in the
+package always have.
+(Previously it returned a nil <code>Stream</code> implementation.)
+</p>
+</dl>
+
+<dl id="crypto/tls"><dt><a href="/pkg/crypto/tls/">crypto/tls</a></dt>
+<dd>
+<p>
+The TLS server now advertises support for SHA-512 signatures when using TLS 1.2.
+The server already supported the signatures, but some clients would not select
+them unless explicitly advertised.
+</p>
+</dl>
+
+<dl id="crypto/x509"><dt><a href="/pkg/crypto/x509/">crypto/x509</a></dt>
+<dd>
+<p>
+<a href="/pkg/crypto/x509/#Certificate.Verify"><code>Certificate.Verify</code></a>
+now enforces the name constraints for all
+names contained in the certificate, not just the one name that a client has asked about.
+Extended key usage restrictions are similarly now checked all at once.
+As a result, after a certificate has been validated, now it can be trusted in its entirety.
+It is no longer necessary to revalidate the certificate for each additional name
+or key usage.
+</p>
+
+<p>
+Parsed certificates also now report URI names and IP, email, and URI constraints, using the new
+<a href="/pkg/crypto/x509/#Certificate"><code>Certificate</code></a> fields
+<code>URIs</code>, <code>PermittedIPRanges</code>, <code>ExcludedIPRanges</code>,
+<code>PermittedEmailAddresses</code>, <code>ExcludedEmailAddresses</code>,
+<code>PermittedURIDomains</code>, and <code>ExcludedURIDomains</code>. Certificates with
+invalid values for those fields are now rejected.
+</p>
+
+<p>
+The new <a href="/pkg/crypto/x509/#MarshalPKCS1PublicKey"><code>MarshalPKCS1PublicKey</code></a>
+and <a href="/pkg/crypto/x509/#ParsePKCS1PublicKey"><code>ParsePKCS1PublicKey</code></a>
+functions convert an RSA public key to and from PKCS#1-encoded form.
+</p>
+
+<p>
+The new <a href="/pkg/crypto/x509/#MarshalPKCS8PrivateKey"><code>MarshalPKCS8PrivateKey</code></a>
+function converts a private key to PKCS#8-encoded form.
+(<a href="/pkg/crypto/x509/#ParsePKCS8PrivateKey"><code>ParsePKCS8PrivateKey</code></a>
+has existed since Go 1.)
+</p>
+</dl>
+
+<dl id="crypto/x509/pkix"><dt><a href="/pkg/crypto/x509/pkix/">crypto/x509/pkix</a></dt>
+<dd>
+<p>
+<a href="/pkg/crypto/x509/pkix/#Name"><code>Name</code></a> now implements a
+<a href="/pkg/crypto/x509/pkix/#Name.String"><code>String</code></a> method that
+formats the X.509 distinguished name in the standard RFC 2253 format.
+</p>
+</dl>
+
+<dl id="database/sql/driver"><dt><a href="/pkg/database/sql/driver/">database/sql/driver</a></dt>
+<dd>
+<p>
+Drivers that currently hold on to the destination buffer provided by
+<a href="/pkg/database/sql/driver/#Rows.Next"><code>driver.Rows.Next</code></a> should ensure they no longer
+write to a buffer assigned to the destination array outside of that call.
+Drivers must be careful that underlying buffers are not modified when closing
+<a href="/pkg/database/sql/driver/#Rows"><code>driver.Rows</code></a>.
+</p>
+<p>
+Drivers that want to construct a <a href="/pkg/database/sql/#DB"><code>sql.DB</code></a> for
+their clients can now implement the <a href="/pkg/database/sql/driver/#Connector"><code>Connector</code></a> interface
+and call the new <a href="/pkg/database/sql/#OpenDB"><code>sql.OpenDB</code></a> function,
+instead of needing to encode all configuration into a string
+passed to <a href="/pkg/database/sql/#Open"><code>sql.Open</code></a>.
+</p>
+<p>
+Drivers that want to parse the configuration string only once per <code>sql.DB</code>
+instead of once per <a href="/pkg/database/sql/#Conn"><code>sql.Conn</code></a>,
+or that want access to each <code>sql.Conn</code>'s underlying context,
+can make their <a href="/pkg/database/sql/driver/#Driver"><code>Driver</code></a>
+implementations also implement <a href="/pkg/database/sql/driver/#DriverContext"><code>DriverContext</code></a>'s
+new <code>OpenConnector</code> method.
+</p>
+<p>
+Drivers that implement <a href="/pkg/database/sql/driver/#ExecerContext"><code>ExecerContext</code></a>
+no longer need to implement <a href="/pkg/database/sql/driver/#Execer"><code>Execer</code></a>;
+similarly, drivers that implement <a href="/pkg/database/sql/driver/#QueryerContext"><code>QueryerContext</code></a>
+no longer need to implement <a href="/pkg/database/sql/driver/#Queryer"><code>Queryer</code></a>.
+Previously, even if the context-based interfaces were implemented they were ignored
+unless the non-context-based interfaces were also implemented.
+</p>
+<p>
+To allow drivers to better isolate different clients using a cached driver connection in succession,
+if a <a href="/pkg/database/sql/driver/#Conn"><code>Conn</code></a> implements the new
+<a href="/pkg/database/sql/driver/#SessionResetter"><code>SessionResetter</code></a> interface,
+<code>database/sql</code> will now call <code>ResetSession</code> before
+reusing the <code>Conn</code> for a new client.
+</p>
+</dl>
+
+<dl id="debug/elf"><dt><a href="/pkg/debug/elf/">debug/elf</a></dt>
+<dd>
+<p>
+This release adds 348 new relocation constants divided between the relocation types
+<a href="/pkg/debug/elf/#R_386"><code>R_386</code></a>,
+<a href="/pkg/debug/elf/#R_AARCH64"><code>R_AARCH64</code></a>,
+<a href="/pkg/debug/elf/#R_ARM"><code>R_ARM</code></a>,
+<a href="/pkg/debug/elf/#R_PPC64"><code>R_PPC64</code></a>,
+and
+<a href="/pkg/debug/elf/#R_X86_64"><code>R_X86_64</code></a>.
+</p>
+</dl>
+
+<dl id="debug/macho"><dt><a href="/pkg/debug/macho/">debug/macho</a></dt>
+<dd>
+<p>
+Go 1.10 adds support for reading relocations from Mach-O sections,
+using the <a href="/pkg/debug/macho#Section"><code>Section</code></a> struct's new <code>Relocs</code> field
+and the new <a href="/pkg/debug/macho/#Reloc"><code>Reloc</code></a>,
+<a href="/pkg/debug/macho/#RelocTypeARM"><code>RelocTypeARM</code></a>,
+<a href="/pkg/debug/macho/#RelocTypeARM64"><code>RelocTypeARM64</code></a>,
+<a href="/pkg/debug/macho/#RelocTypeGeneric"><code>RelocTypeGeneric</code></a>,
+and
+<a href="/pkg/debug/macho/#RelocTypeX86_64"><code>RelocTypeX86_64</code></a>
+types and associated constants.
+</p>
+<p>
+Go 1.10 also adds support for the <code>LC_RPATH</code> load command,
+represented by the types
+<a href="/pkg/debug/macho/#RpathCmd"><code>RpathCmd</code></a> and
+<a href="/pkg/debug/macho/#Rpath"><code>Rpath</code></a>,
+and new <a href="/pkg/debug/macho/#pkg-constants">named constants</a>
+for the various flag bits found in headers.
+</p>
+</dl>
+
+<dl id="encoding/asn1"><dt><a href="/pkg/encoding/asn1/">encoding/asn1</a></dt>
+<dd>
+<p>
+<a href="/pkg/encoding/asn1/#Marshal"><code>Marshal</code></a> now correctly encodes
+strings containing asterisks as type UTF8String instead of PrintableString,
+unless the string is in a struct field with a tag forcing the use of PrintableString.
+<code>Marshal</code> also now respects struct tags containing <code>application</code> directives.
+</p>
+<p>
+The new <a href="/pkg/encoding/asn1/#MarshalWithParams"><code>MarshalWithParams</code></a>
+function marshals its argument as if the additional params were its associated
+struct field tag.
+</p>
+<p>
+<a href="/pkg/encoding/asn1/#Unmarshal"><code>Unmarshal</code></a> now respects
+struct field tags using the <code>explicit</code> and <code>tag</code>
+directives.
+</p>
+<p>
+Both <code>Marshal</code> and <code>Unmarshal</code> now support a new struct field tag
+<code>numeric</code>, indicating an ASN.1 NumericString.
+</p>
+</dl>
+
+<dl id="encoding/csv"><dt><a href="/pkg/encoding/csv/">encoding/csv</a></dt>
+<dd>
+<p>
+<a href="/pkg/encoding/csv/#Reader"><code>Reader</code></a> now disallows the use of
+nonsensical <code>Comma</code> and <code>Comment</code> settings,
+such as NUL, carriage return, newline, invalid runes, and the Unicode replacement character,
+or setting <code>Comma</code> and <code>Comment</code> equal to each other.
+</p>
+<p>
+In the case of a syntax error in a CSV record that spans multiple input lines, <code>Reader</code>
+now reports the line on which the record started in the <a href="/pkg/encoding/csv/#ParseError"><code>ParseError</code></a>'s new <code>StartLine</code> field.
+</p>
+</dl>
+
+<dl id="encoding/hex"><dt><a href="/pkg/encoding/hex/">encoding/hex</a></dt>
+<dd>
+<p>
+The new functions
+<a href="/pkg/encoding/hex/#NewEncoder"><code>NewEncoder</code></a>
+and
+<a href="/pkg/encoding/hex/#NewDecoder"><code>NewDecoder</code></a>
+provide streaming conversions to and from hexadecimal,
+analogous to equivalent functions already in
+<a href="/pkg/encoding/base32/">encoding/base32</a>
+and
+<a href="/pkg/encoding/base64/">encoding/base64</a>.
+</p>
+
+<p>
+When the functions
+<a href="/pkg/encoding/hex/#Decode"><code>Decode</code></a>
+and
+<a href="/pkg/encoding/hex/#DecodeString"><code>DecodeString</code></a>
+encounter malformed input,
+they now return the number of bytes already converted
+along with the error.
+Previously they always returned a count of 0 with any error.
+</p>
+</dl>
+
+<dl id="encoding/json"><dt><a href="/pkg/encoding/json/">encoding/json</a></dt>
+<dd>
+<p>
+The <a href="/pkg/encoding/json/#Decoder"><code>Decoder</code></a>
+adds a new method
+<a href="/pkg/encoding/json/#Decoder.DisallowUnknownFields"><code>DisallowUnknownFields</code></a>
+that causes it to report inputs with unknown JSON fields as a decoding error.
+(The default behavior has always been to discard unknown fields.)
+</p>
+
+<p>
+As a result of <a href="#reflect">fixing a reflect bug</a>,
+<a href="/pkg/encoding/json/#Unmarshal"><code>Unmarshal</code></a>
+can no longer decode into fields inside
+embedded pointers to unexported struct types,
+because it cannot initialize the unexported embedded pointer
+to point at fresh storage.
+<code>Unmarshal</code> now returns an error in this case.
+</p>
+</dl>
+
+<dl id="encoding/pem"><dt><a href="/pkg/encoding/pem/">encoding/pem</a></dt>
+<dd>
+<p>
+<a href="/pkg/encoding/pem/#Encode"><code>Encode</code></a>
+and
+<a href="/pkg/encoding/pem/#EncodeToMemory"><code>EncodeToMemory</code></a>
+no longer generate partial output when presented with a
+block that is impossible to encode as PEM data.
+</p>
+</dl>
+
+<dl id="encoding/xml"><dt><a href="/pkg/encoding/xml/">encoding/xml</a></dt>
+<dd>
+<p>
+The new function
+<a href="/pkg/encoding/xml/#NewTokenDecoder"><code>NewTokenDecoder</code></a>
+is like
+<a href="/pkg/encoding/xml/#NewDecoder"><code>NewDecoder</code></a>
+but creates a decoder reading from a <a href="/pkg/encoding/xml/#TokenReader"><code>TokenReader</code></a>
+instead of an XML-formatted byte stream.
+This is meant to enable the construction of XML stream transformers in client libraries.
+</p>
+</dl>
+
+<dl id="flag"><dt><a href="/pkg/flag/">flag</a></dt>
+<dd>
+<p>
+The default
+<a href="/pkg/flag/#Usage"><code>Usage</code></a> function now prints
+its first line of output to
+<code>CommandLine.Output()</code>
+instead of assuming <code>os.Stderr</code>,
+so that the usage message is properly redirected for
+clients using <code>CommandLine.SetOutput</code>.
+</p>
+<p>
+<a href="/pkg/flag/#PrintDefaults"><code>PrintDefaults</code></a> now
+adds appropriate indentation after newlines in flag usage strings,
+so that multi-line usage strings display nicely.
+</p>
+<p>
+<a href="/pkg/flag/#FlagSet"><code>FlagSet</code></a> adds new methods
+<a href="/pkg/flag/#FlagSet.ErrorHandling"><code>ErrorHandling</code></a>,
+<a href="/pkg/flag/#FlagSet.Name"><code>Name</code></a>,
+and
+<a href="/pkg/flag/#FlagSet.Output"><code>Output</code></a>,
+to retrieve the settings passed to
+<a href="/pkg/flag/#NewFlagSet"><code>NewFlagSet</code></a>
+and
+<a href="/pkg/flag/#FlagSet.SetOutput"><code>FlagSet.SetOutput</code></a>.
+</p>
+</dl>
+
+<dl id="go/doc"><dt><a href="/pkg/go/doc/">go/doc</a></dt>
+<dd>
+<p>
+To support the <a href="#doc">doc change</a> described above,
+functions returning slices of <code>T</code>, <code>*T</code>, <code>**T</code>, and so on
+are now reported in <code>T</code>'s <a href="/pkg/go/doc/#Type"><code>Type</code></a>'s <code>Funcs</code> list,
+instead of in the <a href="/pkg/go/doc/#Package"><code>Package</code></a>'s <code>Funcs</code> list.
+</p>
+</dl>
+
+<dl id="go/importer"><dt><a href="/pkg/go/importer/">go/importer</a></dt>
+<dd>
+<p>
+The <a href="/pkg/go/importer/#For"><code>For</code></a> function now accepts a non-nil lookup argument.
+</p>
+</dl>
+
+<dl id="go/printer"><dt><a href="/pkg/go/printer/">go/printer</a></dt>
+<dd>
+<p>
+The changes to the default formatting of Go source code
+discussed in the <a href="#gofmt">gofmt section</a> above
+are implemented in the <a href="/pkg/go/printer/">go/printer</a> package
+and also affect the output of the higher-level <a href="/pkg/go/format/">go/format</a> package.
+</p>
+</dl>
+
+<dl id="hash"><dt><a href="/pkg/hash/">hash</a></dt>
+<dd>
+<p>
+Implementations of the <a href="/pkg/hash/#Hash"><code>Hash</code></a> interface are now
+encouraged to implement <a href="/pkg/encoding/#BinaryMarshaler"><code>encoding.BinaryMarshaler</code></a>
+and <a href="/pkg/encoding/#BinaryUnmarshaler"><code>encoding.BinaryUnmarshaler</code></a>
+to allow saving and recreating their internal state,
+and all implementations in the standard library
+(<a href="/pkg/hash/crc32/">hash/crc32</a>, <a href="/pkg/crypto/sha256/">crypto/sha256</a>, and so on)
+now implement those interfaces.
+</p>
+</dl>
+
+<dl id="html/template"><dt><a href="/pkg/html/template/">html/template</a></dt>
+<dd>
+<p>
+The new <a href="/pkg/html/template#Srcset"><code>Srcset</code></a> content
+type allows for proper handling of values within the
+<a href="https://w3c.github.io/html/semantics-embedded-content.html#element-attrdef-img-srcset"><code>srcset</code></a>
+attribute of <code>img</code> tags.
+</p>
+</dl>
+
+<dl id="math/big"><dt><a href="/pkg/math/big/">math/big</a></dt>
+<dd>
+<p>
+<a href="/pkg/math/big/#Int"><code>Int</code></a> now supports conversions to and from bases 2 through 62
+in its <a href="/pkg/math/big/#Int.SetString"><code>SetString</code></a> and <a href="/pkg/math/big/#Text"><code>Text</code></a> methods.
+(Previously it only allowed bases 2 through 36.)
+The value of the constant <code>MaxBase</code> has been updated.
+</p>
+<p>
+<a href="/pkg/math/big/#Int"><code>Int</code></a> adds a new
+<a href="/pkg/math/big/#CmpAbs"><code>CmpAbs</code></a> method
+that is like <a href="/pkg/math/big/#Cmp"><code>Cmp</code></a> but
+compares only the absolute values (not the signs) of its arguments.
+</p>
+<p>
+<a href="/pkg/math/big/#Float"><code>Float</code></a> adds a new
+<a href="/pkg/math/big/#Float.Sqrt"><code>Sqrt</code></a> method to
+compute square roots.
+</p>
+</dl>
+
+<dl id="math/cmplx"><dt><a href="/pkg/math/cmplx/">math/cmplx</a></dt>
+<dd>
+<p>
+Branch cuts and other boundary cases in
+<a href="/pkg/math/cmplx/#Asin"><code>Asin</code></a>,
+<a href="/pkg/math/cmplx/#Asinh"><code>Asinh</code></a>,
+<a href="/pkg/math/cmplx/#Atan"><code>Atan</code></a>,
+and
+<a href="/pkg/math/cmplx/#Sqrt"><code>Sqrt</code></a>
+have been corrected to match the definitions used in the C99 standard.
+</p>
+</dl>
+
+<dl id="math/rand"><dt><a href="/pkg/math/rand/">math/rand</a></dt>
+<dd>
+<p>
+The new <a href="/pkg/math/rand/#Shuffle"><code>Shuffle</code></a> function and corresponding
+<a href="/pkg/math/rand/#Rand.Shuffle"><code>Rand.Shuffle</code></a> method
+shuffle an input sequence.
+</p>
+</dl>
+
+<dl id="math"><dt><a href="/pkg/math/">math</a></dt>
+<dd>
+<p>
+The new functions
+<a href="/pkg/math/#Round"><code>Round</code></a>
+and
+<a href="/pkg/math/#RoundToEven"><code>RoundToEven</code></a>
+round their arguments to the nearest floating-point integer;
+<code>Round</code> rounds a half-integer to its larger integer neighbor (away from zero)
+while <code>RoundToEven</code> rounds a half-integer to its even integer neighbor.
+</p>
+
+<p>
+The new functions
+<a href="/pkg/math/#Erfinv"><code>Erfinv</code></a>
+and
+<a href="/pkg/math/#Erfcinv"><code>Erfcinv</code></a>
+compute the inverse error function and the
+inverse complementary error function.
+</p>
+</dl>
+
+<dl id="mime/multipart"><dt><a href="/pkg/mime/multipart/">mime/multipart</a></dt>
+<dd>
+<p>
+<a href="/pkg/mime/multipart/#Reader"><code>Reader</code></a>
+now accepts parts with empty filename attributes.
+</p>
+</dl>
+
+<dl id="mime"><dt><a href="/pkg/mime/">mime</a></dt>
+<dd>
+<p>
+<a href="/pkg/mime/#ParseMediaType"><code>ParseMediaType</code></a> now discards
+invalid attribute values; previously it returned those values as empty strings.
+</p>
+</dl>
+
+<dl id="net"><dt><a href="/pkg/net/">net</a></dt>
+<dd>
+<p>
+The <a href="/pkg/net/#Conn"><code>Conn</code></a> and
+<a href="/pkg/net/#Conn"><code>Listener</code></a> implementations
+in this package now guarantee that when <code>Close</code> returns,
+the underlying file descriptor has been closed.
+(In earlier releases, if the <code>Close</code> stopped pending I/O
+in other goroutines, the closing of the file descriptor could happen in one of those
+goroutines shortly after <code>Close</code> returned.)
+</p>
+
+<p>
+<a href="/pkg/net/#TCPListener"><code>TCPListener</code></a> and
+<a href="/pkg/net/#UnixListener"><code>UnixListener</code></a>
+now implement
+<a href="/pkg/syscall/#Conn"><code>syscall.Conn</code></a>,
+to allow setting options on the underlying file descriptor
+using <a href="/pkg/syscall/#RawConn"><code>syscall.RawConn.Control</code></a>.
+</p>
+
+<p>
+The <code>Conn</code> implementations returned by <a href="/pkg/net/#Pipe"><code>Pipe</code></a>
+now support setting read and write deadlines.
+</p>
+
+<p>
+The <a href="/pkg/net/#IPConn.ReadMsgIP"><code>IPConn.ReadMsgIP</code></a>,
+<a href="/pkg/net/#IPConn.WriteMsgIP"><code>IPConn.WriteMsgIP</code></a>,
+<a href="/pkg/net/#UDPConn.ReadMsgUDP"><code>UDPConn.ReadMsgUDP</code></a>,
+and
+<a href="/pkg/net/#UDPConn.WriteMsgUDP"><code>UDPConn.WriteMsgUDP</code></a>,
+methods are now implemented on Windows.
+</p>
+</dl>
+
+<dl id="net/http"><dt><a href="/pkg/net/http/">net/http</a></dt>
+<dd>
+<p>
+On the client side, an HTTP proxy (most commonly configured by
+<a href="/pkg/net/http/#ProxyFromEnvironment"><code>ProxyFromEnvironment</code></a>)
+can now be specified as an <code>https://</code> URL,
+meaning that the client connects to the proxy over HTTPS before issuing a standard, proxied HTTP request.
+(Previously, HTTP proxy URLs were required to begin with <code>http://</code> or <code>socks5://</code>.)
+</p>
+<p>
+On the server side, <a href="/pkg/net/http/#FileServer"><code>FileServer</code></a> and its single-file equivalent <a href="/pkg/net/http/#ServeFile"><code>ServeFile</code></a>
+now apply <code>If-Range</code> checks to <code>HEAD</code> requests.
+<code>FileServer</code> also now reports directory read failures to the <a href="/pkg/net/http/#Server"><code>Server</code></a>'s <code>ErrorLog</code>.
+The content-serving handlers also now omit the <code>Content-Type</code> header when serving zero-length content.
+</p>
+<p>
+<a href="/pkg/net/http/#ResponseWriter"><code>ResponseWriter</code></a>'s <code>WriteHeader</code> method now panics
+if passed an invalid (non-3-digit) status code.
+</p>
+<p>
+<!-- CL 46631 -->
+The <code>Server</code> will no longer add an implicit Content-Type when a <code>Handler</code> does not write any output.
+</p>
+<p>
+<a href="/pkg/net/http/#Redirect"><code>Redirect</code></a> now sets the <code>Content-Type</code> header before writing its HTTP response.
+</p>
+</dl>
+
+<dl id="net/mail"><dt><a href="/pkg/net/mail/">net/mail</a></dt>
+<dd>
+<p>
+<a href="/pkg/net/mail/#ParseAddress"><code>ParseAddress</code></a> and
+<a href="/pkg/net/mail/#ParseAddressList"><code>ParseAddressList</code></a>
+now support a variety of obsolete address formats.
+</p>
+</dl>
+
+<dl id="net/smtp"><dt><a href="/pkg/net/smtp/">net/smtp</a></dt>
+<dd>
+<p>
+The <a href="/pkg/net/smtp/#Client"><code>Client</code></a> adds a new
+<a href="/pkg/net/smtp/#Client.Noop"><code>Noop</code></a> method,
+to test whether the server is still responding.
+It also now defends against possible SMTP injection in the inputs
+to the <a href="/pkg/net/smtp/#Client.Hello"><code>Hello</code></a>
+and <a href="/pkg/net/smtp/#Client.Verify"><code>Verify</code></a> methods.
+</p>
+</dl>
+
+<dl id="net/textproto"><dt><a href="/pkg/net/textproto/">net/textproto</a></dt>
+<dd>
+<p>
+<a href="/pkg/net/textproto/#ReadMIMEHeader"><code>ReadMIMEHeader</code></a>
+now rejects any header that begins with a continuation (indented) header line.
+Previously a header with an indented first line was treated as if the first line
+were not indented.
+</p>
+</dl>
+
+<dl id="net/url"><dt><a href="/pkg/net/url/">net/url</a></dt>
+<dd>
+<p>
+<a href="/pkg/net/url/#ResolveReference"><code>ResolveReference</code></a>
+now preserves multiple leading slashes in the target URL.
+Previously it rewrote multiple leading slashes to a single slash,
+which resulted in the <a href="/pkg/net/http/#Client"><code>http.Client</code></a>
+following certain redirects incorrectly.
+</p>
+<p>
+For example, this code's output has changed:
+</p>
+<pre>
+base, _ := url.Parse("http://host//path//to/page1")
+target, _ := url.Parse("page2")
+fmt.Println(base.ResolveReference(target))
+</pre>
+<p>
+Note the doubled slashes around <code>path</code>.
+In Go 1.9 and earlier, the resolved URL was <code>http://host/path//to/page2</code>:
+the doubled slash before <code>path</code> was incorrectly rewritten
+to a single slash, while the doubled slash after <code>path</code> was
+correctly preserved.
+Go 1.10 preserves both doubled slashes, resolving to <code>http://host//path//to/page2</code>
+as required by <a href="https://tools.ietf.org/html/rfc3986#section-5.2">RFC 3986</a>.
+</p>
+
+<p>This change may break existing buggy programs that unintentionally
+construct a base URL with a leading doubled slash in the path and inadvertently
+depend on <code>ResolveReference</code> to correct that mistake.
+For example, this can happen if code adds a host prefix
+like <code>http://host/</code> to a path like <code>/my/api</code>,
+resulting in a URL with a doubled slash: <code>http://host//my/api</code>.
+</p>
+
+<p>
+<a href="/pkg/net/url/#UserInfo"><code>UserInfo</code></a>'s methods
+now treat a nil receiver as equivalent to a pointer to a zero <code>UserInfo</code>.
+Previously, they panicked.
+</p>
+</dl>
+
+<dl id="os"><dt><a href="/pkg/os/">os</a></dt>
+<dd>
+<p>
+<a href="/pkg/os/#File"><code>File</code></a> adds new methods
+<a href="/pkg/os/#File.SetDeadline"><code>SetDeadline</code></a>,
+<a href="/pkg/os/#File.SetReadDeadline"><code>SetReadDeadline</code></a>,
+and
+<a href="/pkg/os/#File.SetWriteDeadline"><code>SetWriteDeadline</code></a>
+that allow setting I/O deadlines when the
+underlying file descriptor supports non-blocking I/O operations.
+The definition of these methods matches those in <a href="/pkg/net/#Conn"><code>net.Conn</code></a>.
+If an I/O method fails due to missing a deadline, it will return a
+timeout error; the
+new <a href="/pkg/os/#IsTimeout"><code>IsTimeout</code></a> function
+reports whether an error represents a timeout.
+</p>
+
+<p>
+Also matching <code>net.Conn</code>,
+<code>File</code>'s
+<a href="/pkg/os/#File.Close"><code>Close</code></a> method
+now guarantee that when <code>Close</code> returns,
+the underlying file descriptor has been closed.
+(In earlier releases,
+if the <code>Close</code> stopped pending I/O
+in other goroutines, the closing of the file descriptor could happen in one of those
+goroutines shortly after <code>Close</code> returned.)
+</p>
+
+<p>
+On BSD, macOS, and Solaris systems,
+<a href="/pkg/os/#Chtimes"><code>Chtimes</code></a>
+now supports setting file times with nanosecond precision
+(assuming the underlying file system can represent them).
+</p>
+</dl>
+
+<dl id="reflect"><dt><a href="/pkg/reflect/">reflect</a></dt>
+<dd>
+<p>
+The <a href="/pkg/reflect/#Copy"><code>Copy</code></a> function now allows copying
+from a string into a byte array or byte slice, to match the
+<a href="/pkg/builtin/#copy">built-in copy function</a>.
+</p>
+
+<p>
+In structs, embedded pointers to unexported struct types were
+previously incorrectly reported with an empty <code>PkgPath</code>
+in the corresponding <a href="/pkg/reflect/#StructField">StructField</a>,
+with the result that for those fields,
+and <a href="/pkg/reflect/#Value.CanSet"><code>Value.CanSet</code></a>
+incorrectly returned true and
+<a href="/pkg/reflect/#Value.Set"><code>Value.Set</code></a>
+incorrectly succeeded.
+The underlying metadata has been corrected;
+for those fields,
+<code>CanSet</code> now correctly returns false
+and <code>Set</code> now correctly panics.
+This may affect reflection-based unmarshalers
+that could previously unmarshal into such fields
+but no longer can.
+For example, see the <a href="#encoding/json"><code>encoding/json</code> notes</a>.
+</p>
+</dl>
+
+<dl id="runtime/pprof"><dt><a href="/pkg/runtime/pprof/">runtime/pprof</a></dt>
+<dd>
+<p>
+As <a href="#pprof">noted above</a>, the blocking and mutex profiles
+now include symbol information so that they can be viewed without needing
+the binary that generated them.
+</p>
+</dl>
+
+<dl id="strconv"><dt><a href="/pkg/strconv/">strconv</a></dt>
+<dd>
+<p>
+<a href="/pkg/strconv/#ParseUint"><code>ParseUint</code></a> now returns
+the maximum magnitude integer of the appropriate size
+with any <code>ErrRange</code> error, as it was already documented to do.
+Previously it returned 0 with <code>ErrRange</code> errors.
+</p>
+</dl>
+
+<dl id="strings"><dt><a href="/pkg/strings/">strings</a></dt>
+<dd>
+<p>
+A new type
+<a href="/pkg/strings/#Builder"><code>Builder</code></a> is a replacement for
+<a href="/pkg/bytes/#Buffer"><code>bytes.Buffer</code></a> for the use case of
+accumulating text into a <code>string</code> result.
+The <code>Builder</code>'s API is a restricted subset of <code>bytes.Buffer</code>'s
+that allows it to safely avoid making a duplicate copy of the data
+during the <a href="/pkg/strings/#Builder.String"><code>String</code></a> method.
+</p>
+</dl>
+
+<dl id="syscall"><dt><a href="/pkg/syscall/">syscall</a></dt>
+<dd>
+<p>
+On Windows,
+the new <a href="/pkg/syscall/#SysProcAttr"><code>SysProcAttr</code></a> field <code>Token</code>,
+of type <a href="/pkg/syscall/#Token"><code>Token</code></a> allows the creation of a process that
+runs as another user during <a href="/pkg/syscall/#StartProcess"><code>StartProcess</code></a>
+(and therefore also during <a href="/pkg/os/#StartProcess"><code>os.StartProcess</code></a> and
+<a href="/pkg/os/exec/#Cmd.Start"><code>exec.Cmd.Start</code></a>).
+The new function <a href="/pkg/syscall/#CreateProcessAsUser"><code>CreateProcessAsUser</code></a>
+gives access to the underlying system call.
+</p>
+
+<p>
+On BSD, macOS, and Solaris systems, <a href="/pkg/syscall/#UtimesNano"><code>UtimesNano</code></a>
+is now implemented.
+</p>
+</dl>
+
+<dl id="time"><dt><a href="/pkg/time/">time</a></dt>
+<dd>
+<p>
+<a href="/pkg/time/#LoadLocation"><code>LoadLocation</code></a> now uses the directory
+or uncompressed zip file named by the <code>$ZONEINFO</code>
+environment variable before looking in the default system-specific list of
+known installation locations or in <code>$GOROOT/lib/time/zoneinfo.zip</code>.
+</p>
+<p>
+The new function <a href="/pkg/time/#LoadLocationFromTZData"><code>LoadLocationFromTZData</code></a>
+allows conversion of IANA time zone file data to a <a href="/pkg/time/#Location"><code>Location</code></a>.
+</p>
+</dl>
+
+<dl id="unicode"><dt><a href="/pkg/unicode/">unicode</a></dt>
+<dd>
+<p>
+The <a href="/pkg/unicode/"><code>unicode</code></a> package and associated
+support throughout the system has been upgraded from Unicode 9.0 to
+<a href="http://www.unicode.org/versions/Unicode10.0.0/">Unicode 10.0</a>,
+which adds 8,518 new characters, including four new scripts, one new property,
+a Bitcoin currency symbol, and 56 new emoji.
+</p>
+</dl>
diff --git a/doc/go1.2.html b/doc/go1.2.html
index b9d36f2..5370bbb 100644
--- a/doc/go1.2.html
+++ b/doc/go1.2.html
@@ -266,7 +266,7 @@
<p>
On the ARM, the toolchain supports "external linking", which
is a step towards being able to build shared libraries with the gc
-tool chain and to provide dynamic linking support for environments
+toolchain and to provide dynamic linking support for environments
in which that is necessary.
</p>
diff --git a/doc/go1.3.html b/doc/go1.3.html
index d51052b..18c638a 100644
--- a/doc/go1.3.html
+++ b/doc/go1.3.html
@@ -11,7 +11,7 @@
and contains no language changes.
It focuses primarily on implementation work, providing
precise garbage collection,
-a major refactoring of the compiler tool chain that results in
+a major refactoring of the compiler toolchain that results in
faster builds, especially for large projects,
significant performance improvements across the board,
and support for DragonFly BSD, Solaris, Plan 9 and Google's Native Client architecture (NaCl).
@@ -285,7 +285,7 @@
<h3 id="gc_flag">Command-line flag parsing</h3>
<p>
-In the gc tool chain, the assemblers now use the
+In the gc toolchain, the assemblers now use the
same command-line flag parsing rules as the Go flag package, a departure
from the traditional Unix flag parsing.
This may affect scripts that invoke the tool directly.
diff --git a/doc/go1.9.html b/doc/go1.9.html
index ce103cd..fa50ae7 100644
--- a/doc/go1.9.html
+++ b/doc/go1.9.html
@@ -719,6 +719,11 @@
header when matching handlers. The host is matched unmodified for <code>CONNECT</code> requests.
</li>
+ <li><!-- CL 44074 -->
+ The new <a href="/pkg/net/http/#Server.ServeTLS"><code>Server.ServeTLS</code></a> method wraps
+ <a href="/pkg/net/http/#Server.Serve"><code>Server.Serve</code></a> with added TLS support.
+ </li>
+
<li><!-- CL 34727 -->
<a href="/pkg/net/http/#Server.WriteTimeout"><code>Server.WriteTimeout</code></a>
now applies to HTTP/2 connections and is enforced per-stream.
@@ -740,6 +745,11 @@
and
<a href="/pkg/context/#WithValue"><code>context.WithValue</code></a> instead.
</li>
+
+ <li><!-- CL 35490 -->
+ <a href="/pkg/net/http/#LocalAddrContextKey"><code>LocalAddrContextKey</code></a> now contains
+ the connection's actual network address instead of the interface address used by the listener.
+ </li>
</ul>
<p>Client & Transport changes:</p>
diff --git a/doc/go1.html b/doc/go1.html
index 1665d74..34e305b 100644
--- a/doc/go1.html
+++ b/doc/go1.html
@@ -775,7 +775,7 @@
</p>
{{code "/doc/progs/go1.go" `/ErrSyntax/`}}
-
+
<p>
<em>Updating</em>:
Running <code>go</code> <code>fix</code> will update almost all code affected by the change.
@@ -1827,7 +1827,7 @@
<tr><td>Uitob(x, b)</td> <td>FormatUint(uint64(x), b)</td></tr>
<tr><td>Uitob64(x, b)</td> <td>FormatUint(x, b)</td></tr>
</table>
-
+
<p>
<em>Updating</em>:
Running <code>go</code> <code>fix</code> will update almost all code affected by the change.
@@ -1841,7 +1841,7 @@
<h3 id="templates">The template packages</h3>
<p>
-The <code>template</code> and <code>exp/template/html</code> packages have moved to
+The <code>template</code> and <code>exp/template/html</code> packages have moved to
<a href="/pkg/text/template/"><code>text/template</code></a> and
<a href="/pkg/html/template/"><code>html/template</code></a>.
More significant, the interface to these packages has been simplified.
@@ -2035,4 +2035,4 @@
Installation details are described on the
<a href="/doc/install">Getting Started</a> page, while
the distributions themselves are listed on the
-<a href="https://golang.org/dl/">downloads page</a>.
+<a href="/dl/">downloads page</a>.
diff --git a/doc/go1compat.html b/doc/go1compat.html
index 607d354..a5624ef 100644
--- a/doc/go1compat.html
+++ b/doc/go1compat.html
@@ -190,8 +190,8 @@
<h2 id="tools">Tools</h2>
<p>
-Finally, the Go tool chain (compilers, linkers, build tools, and so
-on) are under active development and may change behavior. This
+Finally, the Go toolchain (compilers, linkers, build tools, and so
+on) is under active development and may change behavior. This
means, for instance, that scripts that depend on the location and
properties of the tools may be broken by a point release.
</p>
diff --git a/doc/go_faq.html b/doc/go_faq.html
index f8322ef..f273688 100644
--- a/doc/go_faq.html
+++ b/doc/go_faq.html
@@ -479,6 +479,15 @@
map access.
</p>
+<p>
+Map access is unsafe only when updates are occurring.
+As long as all goroutines are only reading—looking up elements in the map,
+including iterating through it using a
+<code>for</code> <code>range</code> loop—and not changing the map
+by assigning to elements or doing deletions,
+it is safe for them to access the map concurrently without synchronization.
+</p>
+
<h3 id="language_changes">
Will you accept my language change?</h3>
@@ -1152,7 +1161,7 @@
Work is underway on an experimental package management tool,
<a href="https://github.com/golang/dep"><code>dep</code></a>, to learn
more about how tooling can help package management. More information can be found in
-<a href="https://github.com/golang/dep/blob/master/FAQ.md">the <code>dep</code> FAQ</a>.
+<a href="https://github.com/golang/dep/blob/master/docs/FAQ.md">the <code>dep</code> FAQ</a>.
</p>
<h2 id="Pointers">Pointers and Allocation</h2>
@@ -1476,6 +1485,53 @@
<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency
is not Parallelism</a>.
+<h3 id="no_goroutine_id">
+Why is there no goroutine ID?</h3>
+
+<p>
+Goroutines do not have names; they are just anonymous workers.
+They expose no unique identifier, name, or data structure to the programmer.
+Some people are surprised by this, expecting the <code>go</code>
+statement to return some item that can be used to access and control
+the goroutine later.
+</p>
+
+<p>
+The fundamental reason goroutines are anonymous is so that
+the full Go language is available when programming concurrent code.
+By contrast, the usage patterns that develop when threads and goroutines are
+named can restrict what a library using them can do.
+</p>
+
+<p>
+Here is an illustration of the difficulties.
+Once one names a goroutine and constructs a model around
+it, it becomes special, and one is tempted to associate all computation
+with that goroutine, ignoring the possibility
+of using multiple, possibly shared goroutines for the processing.
+If the <code>net/http</code> package associated per-request
+state with a goroutine,
+clients would be unable to use more goroutines
+when serving a request.
+</p>
+
+<p>
+Moreover, experience with libraries such as those for graphics systems
+that require all processing to occur on the "main thread"
+has shown how awkward and limiting the approach can be when
+deployed in a concurrent language.
+The very existence of a special thread or goroutine forces
+the programmer to distort the program to avoid crashes
+and other problems caused by inadvertently operating
+on the wrong thread.
+</p>
+
+<p>
+For those cases where a particular goroutine is truly special,
+the language provides features such as channels that can be
+used in flexible ways to interact with it.
+</p>
+
<h2 id="Functions_methods">Functions and Methods</h2>
<h3 id="different_method_sets">
@@ -1795,7 +1851,7 @@
Why is my trivial program such a large binary?</h3>
<p>
-The linker in the <code>gc</code> tool chain
+The linker in the <code>gc</code> toolchain
creates statically-linked binaries by default. All Go binaries therefore include the Go
run-time, along with the run-time type information necessary to support dynamic
type checks, reflection, and even panic-time stack traces.
diff --git a/doc/go_spec.html b/doc/go_spec.html
index 6642869..9a166cc 100644
--- a/doc/go_spec.html
+++ b/doc/go_spec.html
@@ -1,6 +1,6 @@
<!--{
"Title": "The Go Programming Language Specification",
- "Subtitle": "Version of June 28, 2017",
+ "Subtitle": "Version of February 1, 2018",
"Path": "/ref/spec"
}-->
@@ -16,8 +16,7 @@
in mind. It is strongly typed and garbage-collected and has explicit
support for concurrent programming. Programs are constructed from
<i>packages</i>, whose properties allow efficient management of
-dependencies. The existing implementations use a traditional
-compile/link model to generate executable binaries.
+dependencies.
</p>
<p>
@@ -577,11 +576,7 @@
<a href="#Assignments">assignment</a> or as an
operand in an <a href="#Expressions">expression</a>.
It is an error if the constant value
-cannot be represented as a value of the respective type.
-For instance, <code>3.0</code> can be given any integer or any
-floating-point type, while <code>2147483648.0</code> (equal to <code>1<<31</code>)
-can be given the types <code>float32</code>, <code>float64</code>, or <code>uint32</code> but
-not <code>int32</code> or <code>string</code>.
+cannot be <a href="#Representability">represented</a> as a value of the respective type.
</p>
<p>
@@ -699,9 +694,8 @@
</pre>
<p>
-Named instances of the boolean, numeric, and string types are
-<a href="#Predeclared_identifiers">predeclared</a>.
-Other named types are introduced with <a href="#Type_declarations">type declarations</a>.
+The language <a href="#Predeclared_identifiers">predeclares</a> certain type names.
+Others are introduced with <a href="#Type_declarations">type declarations</a>.
<i>Composite types</i>—array, struct, pointer, function,
interface, slice, map, and channel types—may be constructed using
type literals.
@@ -765,7 +759,8 @@
<p>
A <i>boolean type</i> represents the set of Boolean truth values
denoted by the predeclared constants <code>true</code>
-and <code>false</code>. The predeclared boolean type is <code>bool</code>.
+and <code>false</code>. The predeclared boolean type is <code>bool</code>;
+it is a <a href="#Type_definitions">defined type</a>.
</p>
<h3 id="Numeric_types">Numeric types</h3>
@@ -812,8 +807,9 @@
</pre>
<p>
-To avoid portability issues all numeric types are distinct except
-<code>byte</code>, which is an alias for <code>uint8</code>, and
+To avoid portability issues all numeric types are <a href="#Type_definitions">defined
+types</a> and thus distinct except
+<code>byte</code>, which is an <a href="#Alias_declarations">alias</a> for <code>uint8</code>, and
<code>rune</code>, which is an alias for <code>int32</code>.
Conversions
are required when different numeric types are mixed in an expression
@@ -829,7 +825,8 @@
A string value is a (possibly empty) sequence of bytes.
Strings are immutable: once created,
it is impossible to change the contents of a string.
-The predeclared string type is <code>string</code>.
+The predeclared string type is <code>string</code>;
+it is a <a href="#Type_definitions">defined type</a>.
</p>
<p>
@@ -861,7 +858,8 @@
<p>
The length is part of the array's type; it must evaluate to a
-non-negative <a href="#Constants">constant</a> representable by a value
+non-negative <a href="#Constants">constant</a>
+<a href="#Representability">representable</a> by a value
of type <code>int</code>.
The length of array <code>a</code> can be discovered
using the built-in function <a href="#Length_and_capacity"><code>len</code></a>.
@@ -1026,8 +1024,8 @@
</p>
<p>
-Given a struct type <code>S</code> and a type named <code>T</code>,
-promoted methods are included in the method set of the struct as follows:
+Given a struct type <code>S</code> and a <a href="#Type_definitions">defined type</a>
+<code>T</code>, promoted methods are included in the method set of the struct as follows:
</p>
<ul>
<li>
@@ -1454,9 +1452,9 @@
<a href="#Exported_identifiers">Non-exported</a> method names from different
packages are always different. The order of the methods is irrelevant.</li>
- <li>Two map types are identical if they have identical key and value types.</li>
+ <li>Two map types are identical if they have identical key and element types.</li>
- <li>Two channel types are identical if they have identical value types and
+ <li>Two channel types are identical if they have identical element types and
the same direction.</li>
</ul>
@@ -1496,7 +1494,7 @@
A3 and int
A4, func(int, float64) *[]string, and A5
-B0, B0, and C0
+B0 and C0
[]int and []int
struct{ a, b *T5 } and struct{ a, b *T5 }
func(x int, y float64) *[]string, func(int, float64) (result *[]string), and A5
@@ -1514,7 +1512,7 @@
<p>
A value <code>x</code> is <i>assignable</i> to a <a href="#Variables">variable</a> of type <code>T</code>
-("<code>x</code> is assignable to <code>T</code>") in any of these cases:
+("<code>x</code> is assignable to <code>T</code>") if one of the following conditions applies:
</p>
<ul>
@@ -1540,12 +1538,68 @@
is a pointer, function, slice, map, channel, or interface type.
</li>
<li>
-<code>x</code> is an untyped <a href="#Constants">constant</a> representable
+<code>x</code> is an untyped <a href="#Constants">constant</a>
+<a href="#Representability">representable</a>
by a value of type <code>T</code>.
</li>
</ul>
+<h3 id="Representability">Representability</h3>
+
+<p>
+A <a href="#Constants">constant</a> <code>x</code> is <i>representable</i>
+by a value of type <code>T</code> if one of the following conditions applies:
+</p>
+
+<ul>
+<li>
+<code>x</code> is in the set of values <a href="#Types">determined</a> by <code>T</code>.
+</li>
+
+<li>
+<code>T</code> is a floating-point type and <code>x</code> can be rounded to <code>T</code>'s
+precision without overflow. Rounding uses IEEE 754 round-to-even rules but with an IEEE
+negative zero further simplified to an unsigned zero. Note that constant values never result
+in an IEEE negative zero, NaN, or infinity.
+</li>
+
+<li>
+<code>T</code> is a complex type, and <code>x</code>'s
+<a href="#Complex_numbers">components</a> <code>real(x)</code> and <code>imag(x)</code>
+are representable by values of <code>T</code>'s component type (<code>float32</code> or
+<code>float64</code>).
+</li>
+</ul>
+
+<pre>
+x T x is representable by a value of T because
+
+'a' byte 97 is in the set of byte values
+97 rune rune is an alias for int32, and 97 is in the set of 32-bit integers
+"foo" string "foo" is in the set of string values
+1024 int16 1024 is in the set of 16-bit integers
+42.0 byte 42 is in the set of unsigned 8-bit integers
+1e10 uint64 10000000000 is in the set of unsigned 64-bit integers
+2.718281828459045 float32 2.718281828459045 rounds to 2.7182817 which is in the set of float32 values
+-1e-1000 float64 -1e-1000 rounds to IEEE -0.0 which is further simplified to 0.0
+0i int 0 is an integer value
+(42 + 0i) float32 42.0 (with zero imaginary part) is in the set of float32 values
+</pre>
+
+<pre>
+x T x is not representable by a value of T because
+
+0 bool 0 is not in the set of boolean values
+'a' string 'a' is a rune, it is not in the set of string values
+1024 byte 1024 is not in the set of unsigned 8-bit integers
+-1 uint16 -1 is not in the set of unsigned 16-bit integers
+1.1 int 1.1 is not an integer value
+42i float32 (0 + 42i) is not in the set of float32 values
+1e1000 float64 1e1000 overflows to IEEE +Inf after rounding
+</pre>
+
+
<h2 id="Blocks">Blocks</h2>
<p>
@@ -1781,7 +1835,7 @@
<p>
Within a parenthesized <code>const</code> declaration list the
-expression list may be omitted from any but the first declaration.
+expression list may be omitted from any but the first ConstSpec.
Such an empty list is equivalent to the textual substitution of the
first preceding non-empty expression list and its type if any.
Omitting the list of expressions is therefore equivalent to
@@ -1810,52 +1864,51 @@
<p>
Within a <a href="#Constant_declarations">constant declaration</a>, the predeclared identifier
<code>iota</code> represents successive untyped integer <a href="#Constants">
-constants</a>. It is reset to 0 whenever the reserved word <code>const</code>
-appears in the source and increments after each <a href="#ConstSpec">ConstSpec</a>.
+constants</a>. Its value is the index of the respective <a href="#ConstSpec">ConstSpec</a>
+in that constant declaration, starting at zero.
It can be used to construct a set of related constants:
</p>
<pre>
-const ( // iota is reset to 0
+const (
c0 = iota // c0 == 0
c1 = iota // c1 == 1
c2 = iota // c2 == 2
)
-const ( // iota is reset to 0
- a = 1 << iota // a == 1
- b = 1 << iota // b == 2
- c = 3 // c == 3 (iota is not used but still incremented)
- d = 1 << iota // d == 8
+const (
+ a = 1 << iota // a == 1 (iota == 0)
+ b = 1 << iota // b == 2 (iota == 1)
+ c = 3 // c == 3 (iota == 2, unused)
+ d = 1 << iota // d == 8 (iota == 3)
)
-const ( // iota is reset to 0
+const (
u = iota * 42 // u == 0 (untyped integer constant)
v float64 = iota * 42 // v == 42.0 (float64 constant)
w = iota * 42 // w == 84 (untyped integer constant)
)
-const x = iota // x == 0 (iota has been reset)
-const y = iota // y == 0 (iota has been reset)
+const x = iota // x == 0
+const y = iota // y == 0
</pre>
<p>
-Within an ExpressionList, the value of each <code>iota</code> is the same because
-it is only incremented after each ConstSpec:
+By definition, multiple uses of <code>iota</code> in the same ConstSpec all have the same value:
</p>
<pre>
const (
- bit0, mask0 = 1 << iota, 1<<iota - 1 // bit0 == 1, mask0 == 0
- bit1, mask1 // bit1 == 2, mask1 == 1
- _, _ // skips iota == 2
- bit3, mask3 // bit3 == 8, mask3 == 7
+ bit0, mask0 = 1 << iota, 1<<iota - 1 // bit0 == 1, mask0 == 0 (iota == 0)
+ bit1, mask1 // bit1 == 2, mask1 == 1 (iota == 1)
+ _, _ // (iota == 2, unused)
+ bit3, mask3 // bit3 == 8, mask3 == 7 (iota == 3)
)
</pre>
<p>
-This last example exploits the implicit repetition of the
-last non-empty expression list.
+This last example exploits the <a href="#Constant_declarations">implicit repetition</a>
+of the last non-empty expression list.
</p>
@@ -1946,7 +1999,7 @@
// NewMutex has the same composition as Mutex but its method set is empty.
type NewMutex Mutex
-// The method set of the <a href="#Pointer_types">base type</a> of PtrMutex remains unchanged,
+// The method set of PtrMutex's underlying type *Mutex remains unchanged,
// but the method set of PtrMutex is empty.
type PtrMutex *Mutex
@@ -2095,9 +2148,8 @@
</p>
<pre class="ebnf">
-FunctionDecl = "func" FunctionName ( Function | Signature ) .
+FunctionDecl = "func" FunctionName Signature [ FunctionBody ] .
FunctionName = identifier .
-Function = Signature FunctionBody .
FunctionBody = Block .
</pre>
@@ -2143,7 +2195,7 @@
</p>
<pre class="ebnf">
-MethodDecl = "func" Receiver MethodName ( Function | Signature ) .
+MethodDecl = "func" Receiver MethodName Signature [ FunctionBody ] .
Receiver = Parameters .
</pre>
@@ -2224,7 +2276,6 @@
<a href="#Constant_declarations">constant</a>,
<a href="#Variable_declarations">variable</a>, or
<a href="#Function_declarations">function</a>,
-a <a href="#Method_expressions">method expression</a> yielding a function,
or a parenthesized expression.
</p>
@@ -2234,7 +2285,7 @@
</p>
<pre class="ebnf">
-Operand = Literal | OperandName | MethodExpr | "(" Expression ")" .
+Operand = Literal | OperandName | "(" Expression ")" .
Literal = BasicLit | CompositeLit | FunctionLit .
BasicLit = int_lit | float_lit | imaginary_lit | rune_lit | string_lit .
OperandName = identifier | QualifiedIdent.
@@ -2348,7 +2399,8 @@
its position in the array.
</li>
<li>An element with a key uses the key as its index. The
- key must be a non-negative constant representable by
+ key must be a non-negative constant
+ <a href="#Representability">representable</a> by
a value of type <code>int</code>; and if it is typed
it must be of integer type.
</li>
@@ -2465,7 +2517,7 @@
</p>
<pre class="ebnf">
-FunctionLit = "func" Function .
+FunctionLit = "func" Signature FunctionBody .
</pre>
<pre>
@@ -2499,6 +2551,7 @@
PrimaryExpr =
Operand |
Conversion |
+ MethodExpr |
PrimaryExpr Selector |
PrimaryExpr Index |
PrimaryExpr Slice |
@@ -2588,8 +2641,8 @@
</li>
<li>
-As an exception, if the type of <code>x</code> is a named pointer type
-and <code>(*x).f</code> is a valid selector expression denoting a field
+As an exception, if the type of <code>x</code> is a <a href="#Type_definitions">defined</a>
+pointer type and <code>(*x).f</code> is a valid selector expression denoting a field
(but not a method), <code>x.f</code> is shorthand for <code>(*x).f</code>.
</li>
@@ -2685,7 +2738,7 @@
<pre class="ebnf">
MethodExpr = ReceiverType "." MethodName .
-ReceiverType = TypeName | "(" "*" TypeName ")" | "(" ReceiverType ")" .
+ReceiverType = Type .
</pre>
<p>
@@ -2921,11 +2974,12 @@
If <code>a</code> is not a map:
</p>
<ul>
- <li>the index <code>x</code> must be of integer type or untyped;
- it is <i>in range</i> if <code>0 <= x < len(a)</code>,
+ <li>the index <code>x</code> must be of integer type or an untyped constant</li>
+ <li>a constant index must be non-negative and
+ <a href="#Representability">representable</a> by a value of type <code>int</code></li>
+ <li>a constant index that is untyped is given type <code>int</code></li>
+ <li>the index <code>x</code> is <i>in range</i> if <code>0 <= x < len(a)</code>,
otherwise it is <i>out of range</i></li>
- <li>a <a href="#Constants">constant</a> index must be non-negative
- and representable by a value of type <code>int</code>
</ul>
<p>
@@ -2977,11 +3031,11 @@
<a href="#Assignability">assignable</a>
to the key type of <code>M</code></li>
<li>if the map contains an entry with key <code>x</code>,
- <code>a[x]</code> is the map value with key <code>x</code>
- and the type of <code>a[x]</code> is the value type of <code>M</code></li>
+ <code>a[x]</code> is the map element with key <code>x</code>
+ and the type of <code>a[x]</code> is the element type of <code>M</code></li>
<li>if the map is <code>nil</code> or does not contain such an entry,
<code>a[x]</code> is the <a href="#The_zero_value">zero value</a>
- for the value type of <code>M</code></li>
+ for the element type of <code>M</code></li>
</ul>
<p>
@@ -3075,7 +3129,8 @@
<code>0</code> <= <code>low</code> <= <code>high</code> <= <code>len(a)</code>,
otherwise they are <i>out of range</i>.
For slices, the upper index bound is the slice capacity <code>cap(a)</code> rather than the length.
-A <a href="#Constants">constant</a> index must be non-negative and representable by a value of type
+A <a href="#Constants">constant</a> index must be non-negative and
+<a href="#Representability">representable</a> by a value of type
<code>int</code>; for arrays or constant strings, constant indices must also be in range.
If both indices are constant, they must satisfy <code>low <= high</code>.
If the indices are out of range at run time, a <a href="#Run_time_panics">run-time panic</a> occurs.
@@ -3091,8 +3146,8 @@
<p>
If the sliced operand of a valid slice expression is a <code>nil</code> slice, the result
-is a <code>nil</code> slice. Otherwise, the result shares its underlying array with the
-operand.
+is a <code>nil</code> slice. Otherwise, if the result is a slice, it shares its underlying
+array with the operand.
</p>
<h4>Full slice expressions</h4>
@@ -3135,7 +3190,8 @@
<p>
The indices are <i>in range</i> if <code>0 <= low <= high <= max <= cap(a)</code>,
otherwise they are <i>out of range</i>.
-A <a href="#Constants">constant</a> index must be non-negative and representable by a value of type
+A <a href="#Constants">constant</a> index must be non-negative and
+<a href="#Representability">representable</a> by a value of type
<code>int</code>; for arrays, constant indices must also be in range.
If multiple indices are constant, the constants that are present must be in range relative to each
other.
@@ -3384,7 +3440,8 @@
<p>
The right operand in a shift expression must have unsigned integer type
-or be an untyped constant representable by a value of type <code>uint</code>.
+or be an untyped constant <a href="#Representability">representable</a> by a
+value of type <code>uint</code>.
If the left operand of a non-constant shift expression is an untyped constant,
it is first converted to the type it would assume if the shift expression were
replaced by its left operand alone.
@@ -3392,18 +3449,20 @@
<pre>
var s uint = 33
-var i = 1<<s // 1 has type int
-var j int32 = 1<<s // 1 has type int32; j == 0
-var k = uint64(1<<s) // 1 has type uint64; k == 1<<33
-var m int = 1.0<<s // 1.0 has type int; m == 0 if ints are 32bits in size
-var n = 1.0<<s == j // 1.0 has type int32; n == true
-var o = 1<<s == 2<<s // 1 and 2 have type int; o == true if ints are 32bits in size
-var p = 1<<s == 1<<33 // illegal if ints are 32bits in size: 1 has type int, but 1<<33 overflows int
-var u = 1.0<<s // illegal: 1.0 has type float64, cannot shift
-var u1 = 1.0<<s != 0 // illegal: 1.0 has type float64, cannot shift
-var u2 = 1<<s != 1.0 // illegal: 1 has type float64, cannot shift
-var v float32 = 1<<s // illegal: 1 has type float32, cannot shift
-var w int64 = 1.0<<33 // 1.0<<33 is a constant shift expression
+var i = 1<<s // 1 has type int
+var j int32 = 1<<s // 1 has type int32; j == 0
+var k = uint64(1<<s) // 1 has type uint64; k == 1<<33
+var m int = 1.0<<s // 1.0 has type int; m == 0 if ints are 32bits in size
+var n = 1.0<<s == j // 1.0 has type int32; n == true
+var o = 1<<s == 2<<s // 1 and 2 have type int; o == true if ints are 32bits in size
+var p = 1<<s == 1<<33 // illegal if ints are 32bits in size: 1 has type int, but 1<<33 overflows int
+var u = 1.0<<s // illegal: 1.0 has type float64, cannot shift
+var u1 = 1.0<<s != 0 // illegal: 1.0 has type float64, cannot shift
+var u2 = 1<<s != 1.0 // illegal: 1 has type float64, cannot shift
+var v float32 = 1<<s // illegal: 1 has type float32, cannot shift
+var w int64 = 1.0<<33 // 1.0<<33 is a constant shift expression
+var x = a[1.0<<s] // 1.0 has type int; x == a[0] if ints are 32bits in size
+var a = make([]byte, 1.0<<s) // 1.0 has type int; len(a) == 0 if ints are 32bits in size
</pre>
@@ -3497,9 +3556,10 @@
</pre>
<p>
-As an exception to this rule, if the dividend <code>x</code> is the most
-negative value for the int type of <code>x</code>, the quotient
-<code>q = x / -1</code> is equal to <code>x</code> (and <code>r = 0</code>).
+The one exception to this rule is that if the dividend <code>x</code> is
+the most negative value for the int type of <code>x</code>, the quotient
+<code>q = x / -1</code> is equal to <code>x</code> (and <code>r = 0</code>)
+due to two's-complement <a href="#Integer_overflow">integer overflow</a>:
</p>
<pre>
@@ -3558,15 +3618,15 @@
computed modulo 2<sup><i>n</i></sup>, where <i>n</i> is the bit width of
the <a href="#Numeric_types">unsigned integer</a>'s type.
Loosely speaking, these unsigned integer operations
-discard high bits upon overflow, and programs may rely on ``wrap around''.
+discard high bits upon overflow, and programs may rely on "wrap around".
</p>
<p>
For signed integers, the operations <code>+</code>,
-<code>-</code>, <code>*</code>, and <code><<</code> may legally
+<code>-</code>, <code>*</code>, <code>/</code>, and <code><<</code> may legally
overflow and the resulting value exists and is deterministically defined
by the signed integer representation, the operation, and its operands.
-No exception is raised as a result of overflow. A
-compiler may not optimize code under the assumption that overflow does
+No exception is raised as a result of overflow.
+A compiler may not optimize code under the assumption that overflow does
not occur. For instance, it may not assume that <code>x < x + 1</code> is always true.
</p>
@@ -3877,30 +3937,14 @@
<p>
A <a href="#Constants">constant</a> value <code>x</code> can be converted to
-type <code>T</code> in any of these cases:
+type <code>T</code> if <code>x</code> is <a href="#Representability">representable</a>
+by a value of <code>T</code>.
+As a special case, an integer constant <code>x</code> can be converted to a
+<a href="#String_types">string type</a> using the
+<a href="#Conversions_to_and_from_a_string_type">same rule</a>
+as for non-constant <code>x</code>.
</p>
-<ul>
- <li>
- <code>x</code> is representable by a value of type <code>T</code>.
- </li>
- <li>
- <code>x</code> is a floating-point constant,
- <code>T</code> is a floating-point type,
- and <code>x</code> is representable by a value
- of type <code>T</code> after rounding using
- IEEE 754 round-to-even rules, but with an IEEE <code>-0.0</code>
- further rounded to an unsigned <code>0.0</code>.
- The constant <code>T(x)</code> is the rounded value.
- </li>
- <li>
- <code>x</code> is an integer constant and <code>T</code> is a
- <a href="#String_types">string type</a>.
- The <a href="#Conversions_to_and_from_a_string_type">same rule</a>
- as for non-constant <code>x</code> applies in this case.
- </li>
-</ul>
-
<p>
Converting a constant yields a typed constant as result.
</p>
@@ -4187,7 +4231,8 @@
</pre>
<p>
-The values of <i>typed</i> constants must always be accurately representable as values
+The values of <i>typed</i> constants must always be accurately
+<a href="#Representability">representable</a> by values
of the constant type. The following constant expressions are illegal:
</p>
@@ -4310,7 +4355,9 @@
<h3 id="Terminating_statements">Terminating statements</h3>
<p>
-A terminating statement is one of the following:
+A <i>terminating statement</i> prevents execution of all statements that lexically
+appear after it in the same <a href="#Blocks">block</a>. The following statements
+are terminating:
</p>
<ol>
@@ -4820,8 +4867,9 @@
</p>
<p>
-The type in a case may be <a href="#Predeclared_identifiers"><code>nil</code></a>;
-that case is used when the expression in the TypeSwitchGuard
+Instead of a type, a case may use the predeclared identifier
+<a href="#Predeclared_identifiers"><code>nil</code></a>;
+that case is selected when the expression in the TypeSwitchGuard
is a <code>nil</code> interface value.
There may be at most one <code>nil</code> case.
</p>
@@ -4979,12 +5027,10 @@
</p>
<p>
-The range expression is evaluated once before beginning the loop,
-with one exception: if the range expression is an array or a pointer to an array
-and at most one iteration variable is present, only the range expression's
-length is evaluated; if that length is constant,
-<a href="#Length_and_capacity">by definition</a>
-the range expression itself will not be evaluated.
+The range expression <code>x</code> is evaluated once before beginning the loop,
+with one exception: if at most one iteration variable is present and
+<code>len(x)</code> is <a href="#Length_and_capacity">constant</a>,
+the range expression is not evaluated.
</p>
<p>
@@ -5075,7 +5121,7 @@
}
var key string
-var val interface {} // value type of m is assignable to val
+var val interface {} // element type of m is assignable to val
m := map[string]int{"mon":0, "tue":1, "wed":2, "thu":3, "fri":4, "sat":5, "sun":6}
for key, val = range m {
h(key, val)
@@ -5680,9 +5726,10 @@
<p>
-The size arguments <code>n</code> and <code>m</code> must be of integer type or untyped.
-A <a href="#Constants">constant</a> size argument must be non-negative and
-representable by a value of type <code>int</code>.
+Each of the size arguments <code>n</code> and <code>m</code> must be of integer type
+or an untyped <a href="#Constants">constant</a>.
+A constant size argument must be non-negative and <a href="#Representability">representable</a>
+by a value of type <code>int</code>; if it is an untyped constant it is given type <code>int</code>.
If both <code>n</code> and <code>m</code> are provided and are constant, then
<code>n</code> must be no larger than <code>m</code>.
If <code>n</code> is negative or larger than <code>m</code> at run time,
@@ -6157,7 +6204,7 @@
and no explicit initialization is provided, the variable or value is
given a default value. Each element of such a variable or value is
set to the <i>zero value</i> for its type: <code>false</code> for booleans,
-<code>0</code> for integers, <code>0.0</code> for floats, <code>""</code>
+<code>0</code> for numeric types, <code>""</code>
for strings, and <code>nil</code> for pointers, functions, interfaces, slices, channels, and maps.
This initialization is done recursively, so for instance each element of an
array of structs will have its fields zeroed if no value is specified.
@@ -6409,7 +6456,8 @@
<h3 id="Package_unsafe">Package <code>unsafe</code></h3>
<p>
-The built-in package <code>unsafe</code>, known to the compiler,
+The built-in package <code>unsafe</code>, known to the compiler
+and accessible through the <a href="#Import_declarations">import path</a> <code>"unsafe"</code>,
provides facilities for low-level programming including operations
that violate the type system. A package using <code>unsafe</code>
must be vetted manually for type safety and may not be portable.
diff --git a/doc/help.html b/doc/help.html
index 057d752..f668196 100644
--- a/doc/help.html
+++ b/doc/help.html
@@ -1,6 +1,7 @@
<!--{
"Title": "Help",
- "Path": "/help/"
+ "Path": "/help/",
+ "Template": true
}-->
<div id="manual-nav"></div>
@@ -9,6 +10,7 @@
<img class="gopher" src="/doc/gopher/help.png"/>
+{{if not $.GoogleCN}}
<h3 id="mailinglist"><a href="https://groups.google.com/group/golang-nuts">Go Nuts Mailing List</a></h3>
<p>
Get help from Go users, and share your work on the official mailing list.
@@ -31,10 +33,12 @@
<h3 id="irc"><a href="irc:irc.freenode.net/go-nuts">Go IRC Channel</a></h3>
<p>Get live support at <b>#go-nuts</b> on <b>irc.freenode.net</b>, the official
Go IRC channel.</p>
+{{end}}
<h3 id="faq"><a href="/doc/faq">Frequently Asked Questions (FAQ)</a></h3>
<p>Answers to common questions about Go.</p>
+{{if not $.GoogleCN}}
<h2 id="inform">Stay informed</h2>
<h3 id="announce"><a href="https://groups.google.com/group/golang-announce">Go Announcements Mailing List</a></h3>
@@ -64,6 +68,7 @@
The <a href="https://changelog.com/gotime">Go Time podcast</a> is a panel of Go experts and special guests
discussing the Go programming language, the community, and everything in between.
</p>
+{{end}}
<h2 id="community">Community resources</h2>
@@ -73,11 +78,13 @@
meet to talk about Go. Find a chapter near you.
</p>
+{{if not $.GoogleCN}}
<h3 id="playground"><a href="/play">Go Playground</a></h3>
<p>A place to write, run, and share Go code.</p>
<h3 id="wiki"><a href="/wiki">Go Wiki</a></h3>
<p>A wiki maintained by the Go community.</p>
+{{end}}
<h3 id="conduct"><a href="/conduct">Code of Conduct</a></h3>
<p>
diff --git a/doc/install-source.html b/doc/install-source.html
index d120f7d..4ed9487 100644
--- a/doc/install-source.html
+++ b/doc/install-source.html
@@ -24,7 +24,7 @@
<div class="detail">
<p>
-There are two official Go compiler tool chains.
+There are two official Go compiler toolchains.
This document focuses on the <code>gc</code> Go
compiler and tools.
For information on how to work on <code>gccgo</code>, a more traditional
@@ -119,7 +119,7 @@
<h2 id="go14">Install Go compiler binaries</h2>
<p>
-The Go tool chain is written in Go. To build it, you need a Go compiler installed.
+The Go toolchain is written in Go. To build it, you need a Go compiler installed.
The scripts that do the initial build of the tools look for an existing Go tool
chain in <code>$GOROOT_BOOTSTRAP</code>.
If unset, the default value of <code>GOROOT_BOOTSTRAP</code>
@@ -127,33 +127,34 @@
</p>
<p>
-There are many options for the bootstrap tool chain.
+There are many options for the bootstrap toolchain.
After obtaining one, set <code>GOROOT_BOOTSTRAP</code> to the
directory containing the unpacked tree.
For example, <code>$GOROOT_BOOTSTRAP/bin/go</code> should be
-the <code>go</code> command binary for the bootstrap tool chain.
+the <code>go</code> command binary for the bootstrap toolchain.
</p>
<p>
-To use a binary release as a bootstrap tool chain, see
+To use a binary release as a bootstrap toolchain, see
<a href="/dl/">the downloads page</a> or use any other
packaged Go distribution.
</p>
<p>
-To build a bootstrap tool chain from source, use
+To build a bootstrap toolchain from source, use
either the git branch <code>release-branch.go1.4</code> or
-<a href="https://storage.googleapis.com/golang/go1.4-bootstrap-20170531.tar.gz">go1.4-bootstrap-20170531.tar.gz</a>,
+<a href="https://dl.google.com/go/go1.4-bootstrap-20171003.tar.gz">go1.4-bootstrap-20171003.tar.gz</a>,
which contains the Go 1.4 source code plus accumulated fixes
to keep the tools running on newer operating systems.
-(Go 1.4 was the last distribution in which the tool chain was written in C.)
+(Go 1.4 was the last distribution in which the toolchain was written in C.)
After unpacking the Go 1.4 source, <code>cd</code> to
-the <code>src</code> subdirectory and run <code>make.bash</code> (or,
+the <code>src</code> subdirectory, set <code>CGO_ENABLED=0</code> in
+the environment, and run <code>make.bash</code> (or,
on Windows, <code>make.bat</code>).
</p>
<p>
-To cross-compile a bootstrap tool chain from source, which is
+To cross-compile a bootstrap toolchain from source, which is
necessary on systems Go 1.4 did not target (for
example, <code>linux/ppc64le</code>), install Go on a different system
and run <a href="/src/bootstrap.bash">bootstrap.bash</a>.
@@ -445,6 +446,7 @@
There is no need to set this unless you want to switch between multiple
local copies of the repository.
</p>
+</li>
<li><code>$GOROOT_FINAL</code>
<p>
@@ -455,12 +457,14 @@
but move it elsewhere after the build, set
<code>$GOROOT_FINAL</code> to the eventual location.
</p>
+</li>
<li><code>$GOOS</code> and <code>$GOARCH</code>
<p>
The name of the target operating system and compilation architecture.
These default to the values of <code>$GOHOSTOS</code> and
<code>$GOHOSTARCH</code> respectively (described below).
+</li>
<p>
Choices for <code>$GOOS</code> are
@@ -471,8 +475,9 @@
<code>amd64</code> (64-bit x86, the most mature port),
<code>386</code> (32-bit x86), <code>arm</code> (32-bit ARM), <code>arm64</code> (64-bit ARM),
<code>ppc64le</code> (PowerPC 64-bit, little-endian), <code>ppc64</code> (PowerPC 64-bit, big-endian),
-<code>mips64le</code> (MIPS 64-bit, little-endian), and <code>mips64</code> (MIPS 64-bit, big-endian).
-<code>mipsle</code> (MIPS 32-bit, little-endian), and <code>mips</code> (MIPS 32-bit, big-endian).
+<code>mips64le</code> (MIPS 64-bit, little-endian), <code>mips64</code> (MIPS 64-bit, big-endian),
+<code>mipsle</code> (MIPS 32-bit, little-endian), <code>mips</code> (MIPS 32-bit, big-endian), and
+<code>s390x</code> (IBM System z 64-bit, big-endian).
The valid combinations of <code>$GOOS</code> and <code>$GOARCH</code> are:
<table cellpadding="0">
<tr>
@@ -536,6 +541,9 @@
<td></td><td><code>linux</code></td> <td><code>mips64le</code></td>
</tr>
<tr>
+<td></td><td><code>linux</code></td> <td><code>s390x</code></td>
+</tr>
+<tr>
<td></td><td><code>netbsd</code></td> <td><code>386</code></td>
</tr>
<tr>
@@ -577,6 +585,7 @@
These default to the local system's operating system and
architecture.
</p>
+</li>
<p>
Valid choices are the same as for <code>$GOOS</code> and
@@ -595,6 +604,7 @@
If <code>$GOBIN</code> is set, the <a href="/cmd/go">go command</a>
installs all commands there.
</p>
+</li>
<li><code>$GO386</code> (for <code>386</code> only, default is auto-detected
if built on either <code>386</code> or <code>amd64</code>, <code>387</code> otherwise)
@@ -604,9 +614,10 @@
floating point computations.
</p>
<ul>
- <li><code>GO386=387</code>: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later).
- <li><code>GO386=sse2</code>: use SSE2 for floating point operations; has better performance than 387, but only available on Pentium 4/Opteron/Athlon 64 or later.
+ <li><code>GO386=387</code>: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later).</li>
+ <li><code>GO386=sse2</code>: use SSE2 for floating point operations; has better performance than 387, but only available on Pentium 4/Opteron/Athlon 64 or later.</li>
</ul>
+</li>
<li><code>$GOARM</code> (for <code>arm</code> only; default is auto-detected if building
on the target processor, 6 if not)
@@ -615,9 +626,9 @@
should target. If you are compiling on the target system, its value will be auto-detected.
</p>
<ul>
- <li><code>GOARM=5</code>: use software floating point; when CPU doesn't have VFP co-processor
- <li><code>GOARM=6</code>: use VFPv1 only; default if cross compiling; usually ARM11 or better cores (VFPv2 or better is also supported)
- <li><code>GOARM=7</code>: use VFPv3; usually Cortex-A cores
+ <li><code>GOARM=5</code>: use software floating point; when CPU doesn't have VFP co-processor</li>
+ <li><code>GOARM=6</code>: use VFPv1 only; default if cross compiling; usually ARM11 or better cores (VFPv2 or better is also supported)</li>
+ <li><code>GOARM=7</code>: use VFPv3; usually Cortex-A cores</li>
</ul>
<p>
If in doubt, leave this variable unset, and adjust it if required
@@ -626,6 +637,17 @@
on the <a href="//golang.org/wiki">Go community wiki</a>
contains further details regarding Go's ARM support.
</p>
+</li>
+
+<li><code>$GOMIPS</code> (for <code>mips</code> and <code>mipsle</code> only)
+<p>
+This sets whether to use floating point instructions.
+</p>
+<ul>
+ <li><code>GOMIPS=hardfloat</code>: use floating point instructions (the default)</li>
+ <li><code>GOMIPS=softfloat</code>: use soft floating point</li>
+</ul>
+</li>
</ul>
diff --git a/doc/install.html b/doc/install.html
index 7f32f68..f17dce5 100644
--- a/doc/install.html
+++ b/doc/install.html
@@ -8,15 +8,15 @@
<h2 id="download">Download the Go distribution</h2>
<p>
-<a href="https://golang.org/dl/" id="start" class="download">
+<a href="/dl/" id="start" class="download">
<span class="big">Download Go</span>
<span class="desc">Click here to visit the downloads page</span>
</a>
</p>
<p>
-<a href="https://golang.org/dl/" target="_blank">Official binary
-distributions</a> are available for the FreeBSD (release 8-STABLE and above),
+<a href="/dl/" target="_blank">Official binary
+distributions</a> are available for the FreeBSD (release 10-STABLE and above),
Linux, Mac OS X (10.8 and above), and Windows operating systems and
the 32-bit (<code>386</code>) and 64-bit (<code>amd64</code>) x86 processor
architectures.
@@ -33,7 +33,7 @@
<h2 id="requirements">System requirements</h2>
<p>
-Go <a href="https://golang.org/dl/">binary distributions</a> are available for these supported operating systems and architectures.
+Go <a href="/dl/">binary distributions</a> are available for these supported operating systems and architectures.
Please ensure your system meets these requirements before proceeding.
If your OS or architecture is not on the list, you may be able to
<a href="/doc/install/source">install from source</a> or
@@ -47,7 +47,7 @@
<th align="center">Notes</th>
</tr>
<tr><td colspan="3"><hr></td></tr>
-<tr><td>FreeBSD 9.3 or later</td> <td>amd64, 386</td> <td>Debian GNU/kFreeBSD not supported</td></tr>
+<tr><td>FreeBSD 10.3 or later</td> <td>amd64, 386</td> <td>Debian GNU/kFreeBSD not supported</td></tr>
<tr valign='top'><td>Linux 2.6.23 or later with glibc</td> <td>amd64, 386, arm, arm64,<br>s390x, ppc64le</td> <td>CentOS/RHEL 5.x not supported.<br>Install from source for other libc.</td></tr>
<tr><td>macOS 10.8 or later</td> <td>amd64</td> <td>use the clang or gcc<sup>†</sup> that comes with Xcode<sup>‡</sup> for <code>cgo</code> support</td></tr>
<tr><td>Windows XP SP2 or later</td> <td>amd64, 386</td> <td>use MinGW gcc<sup>†</sup>. No need for cygwin or msys.</td></tr>
@@ -77,7 +77,7 @@
<h3 id="tarball">Linux, Mac OS X, and FreeBSD tarballs</h3>
<p>
-<a href="https://golang.org/dl/">Download the archive</a>
+<a href="/dl/">Download the archive</a>
and extract it into <code>/usr/local</code>, creating a Go tree in
<code>/usr/local/go</code>. For example:
</p>
@@ -138,7 +138,7 @@
<h3 id="osx">Mac OS X package installer</h3>
<p>
-<a href="https://golang.org/dl/">Download the package file</a>,
+<a href="/dl/">Download the package file</a>,
open it, and follow the prompts to install the Go tools.
The package installs the Go distribution to <code>/usr/local/go</code>.
</p>
@@ -167,7 +167,7 @@
<h4 id="windows_msi">MSI installer</h4>
<p>
-Open the <a href="https://golang.org/dl/">MSI file</a>
+Open the <a href="/dl/">MSI file</a>
and follow the prompts to install the Go tools.
By default, the installer puts the Go distribution in <code>c:\Go</code>.
</p>
@@ -185,7 +185,7 @@
<h4 id="windows_zip">Zip archive</h4>
<p>
-<a href="https://golang.org/dl/">Download the zip file</a> and extract it into the directory of your choice (we suggest <code>c:\Go</code>).
+<a href="/dl/">Download the zip file</a> and extract it into the directory of your choice (we suggest <code>c:\Go</code>).
</p>
<p>
diff --git a/doc/progs/run.go b/doc/progs/run.go
index 8479a66..06ea130 100644
--- a/doc/progs/run.go
+++ b/doc/progs/run.go
@@ -219,12 +219,5 @@
// cgo1 and cgo2 don't run on netbsd, srandom has a different signature
skipTest("cgo1")
skipTest("cgo2")
- // cgo3 and cgo4 don't run on netbsd, since cgo cannot handle stdout correctly, see issue #10715.
- skipTest("cgo3")
- skipTest("cgo4")
- case "openbsd", "solaris":
- // cgo3 and cgo4 don't run on openbsd and solaris, since cgo cannot handle stdout correctly, see issue #10715.
- skipTest("cgo3")
- skipTest("cgo4")
}
}
diff --git a/doc/root.html b/doc/root.html
index 9bdf927..a5119a9 100644
--- a/doc/root.html
+++ b/doc/root.html
@@ -58,7 +58,7 @@
<div id="gopher"></div>
-<a href="https://golang.org/dl/" id="start">
+<a href="/dl/" id="start">
<span class="big">Download Go</span>
<span class="desc">
Binary distributions available for<br>