doc: s/tool chain/toolchain/

We were not being consistent.
Standardize on toolchain.

Change-Id: Id0e756b5214ce4a1341f733634ed95263f03a61c
Reviewed-on: https://go-review.googlesource.com/87017
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

doc/articles/go_command.html

@@ -134,7 +134,7 @@ be able to adapt to changing build environments and conditions. For
 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>
 

doc/asm.html

@@ -29,7 +29,7 @@ Instead, the compiler operates on a kind of semi-abstract instruction set,
 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 @@ The exact set depends on the architecture.
 <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>
 

doc/debugging_with_gdb.html

@@ -13,7 +13,7 @@ Gccgo has native gdb support.
 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
-tool chain. It understands the Go runtime, data structures, and
+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
@@ -113,7 +113,7 @@ Show the name, type and location of global variables:
 
 <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>

doc/go1.1.html

@@ -166,7 +166,7 @@ providing a complete Go 1.1 implementation.
 <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 @@ The race detector is documented in <a href="/doc/articles/race_detector.html">a
 <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 @@ Run <code>go help test</code> for more information.
 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 @@ To build a file only with Go 1.0.x, use the converse constraint:
 <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>

doc/go1.2.html

@@ -266,7 +266,7 @@ is now an error.
 <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>
 

doc/go1.3.html

@@ -11,7 +11,7 @@ The latest Go release, version 1.3, arrives six months after 1.2,
 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 @@ building and linking with a shared library.
 <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.

doc/go1compat.html

@@ -190,8 +190,8 @@ For details and background, see
 <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>

doc/go_faq.html

@@ -1842,7 +1842,7 @@ supported by recent modifications to the gold linker.
 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.

doc/install-source.html

@@ -24,7 +24,7 @@ packages, though, read on.
 <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 @@ Go does not support CentOS 6 on these systems.
 <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,26 +127,26 @@ is <code>$HOME/go1.4</code>.
 </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://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, set <code>CGO_ENABLED=0</code> in
 the environment, and run <code>make.bash</code> (or,
@@ -154,7 +154,7 @@ 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>.