content: fix links to code.google.com

Some minor fixes and clean up to articles that referred to
code.google.com (now defunct).

This cleans up all of the top 30 articles (not much point in cleaning
up the articles that are less viewed).

Fixes golang/go#18907.

Change-Id: I38a22f57e1effa8a545b429dface088042df0f91
Reviewed-on: https://go-review.googlesource.com/36311
Reviewed-by: Russ Cox <[email protected]>

Author: broady

content/c-go-cgo.article

@@ -104,6 +104,4 @@ To build cgo packages, just use [[http://golang.org/cmd/go/#Compile_packages_and
 
 The [[http://golang.org/cmd/cgo/][cgo command]] documentation has more detail about the C pseudo-package and the build process. The [[http://golang.org/misc/cgo/][cgo examples]] in the Go tree demonstrate more advanced concepts.
 
-For a simple, idiomatic example of a cgo-based package, see Russ Cox's [[http://code.google.com/p/gosqlite/source/browse/sqlite/sqlite.go][gosqlite]]. Also, the Go Project Dashboard lists [[https://godashboard.appspot.com/project?tag=cgo][several other cgo packages]].
-
 Finally, if you're curious as to how all this works internally, take a look at the introductory comment of the runtime package's [[https://golang.org/src/runtime/cgocall.go][cgocall.go]].

content/error-handling-and-go.article

@@ -131,7 +131,7 @@ Client code can test for a `net.Error` with a type assertion and then distinguis
 
 In Go, error handling is important. The language's design and conventions encourage you to explicitly check for errors where they occur (as distinct from the convention in other languages of throwing exceptions and sometimes catching them). In some cases this makes Go code verbose, but fortunately there are some techniques you can use to minimize repetitive error handling.
 
-Consider an [[http://code.google.com/appengine/docs/go/][App Engine]] application with an HTTP handler that retrieves a record from the datastore and formats it with a template.
+Consider an [[https://cloud.google.com/appengine/docs/go/][App Engine]] application with an HTTP handler that retrieves a record from the datastore and formats it with a template.
 
 	func init() {
 	    http.HandleFunc("/view", viewRecord)

content/go-fmt-your-code.article

@@ -52,7 +52,7 @@ The easiest way to mechanically manipulate Go code is with gofmt's -r flag. The
 
 where both pattern and replacement are valid Go expressions. In the pattern, single-character lowercase identifiers serve as wildcards matching arbitrary sub-expressions, and those expressions are substituted for the same identifiers in the replacement.
 
-For example, this[[https://code.google.com/p/go/source/detail?r=ae4e014e0b77][ recent change]] to the Go core rewrote some uses of [[http://golang.org/pkg/bytes/#Compare][bytes.Compare]] to use the more efficient [[http://golang.org/pkg/bytes/#Equal][bytes.Equal]]. The contributor made the change using just two gofmt invocations:
+For example, this[[https://golang.org/cl/7038051][ recent change]] to the Go core rewrote some uses of [[http://golang.org/pkg/bytes/#Compare][bytes.Compare]] to use the more efficient [[http://golang.org/pkg/bytes/#Equal][bytes.Equal]]. The contributor made the change using just two gofmt invocations:
 
 	 gofmt -r 'bytes.Compare(a, b) == 0 -> bytes.Equal(a, b)'
 	 gofmt -r 'bytes.Compare(a, b) != 0 -> !bytes.Equal(a, b)'

content/organizing-go-code.article

@@ -22,7 +22,7 @@ A good name is the most important part of a software interface: the name is the
 
 An import path is the string with which users import a package. It specifies the directory (relative to `$GOROOT/src/pkg` or `$GOPATH/src`) in which the package's source code resides.
 
-Import paths should be globally unique, so use the path of your source repository as its base. For instance, the `websocket` package from the `go.net` sub-repository has an import path of `"golang.org/x/net/websocket"`. The Go project owns the path `"code.google.com/p/go"`, so that path cannot be used by another author for a different package. Because the repository URL and import path are one and the same, the `go`get` command can fetch and install the package automatically.
+Import paths should be globally unique, so use the path of your source repository as its base. For instance, the `websocket` package from the `go.net` sub-repository has an import path of `"golang.org/x/net/websocket"`. The Go project owns the path `"github.com/golang"`, so that path cannot be used by another author for a different package. Because the repository URL and import path are one and the same, the `go`get` command can fetch and install the package automatically.
 
 If you don't use a hosted source repository, choose some unique prefix such as a domain, company, or project name. As an example, the import path of all Google's internal Go code starts with the string `"google"`.
 

content/package-names.article

@@ -150,7 +150,7 @@ Just as types in different packages can have the same name without ambiguity,
 packages in different directories can have the same name.
 For example,
 [[https://golang.org/pkg/runtime/pprof][runtime/pprof]] provides profiling data
-in the format expected by the [[https://code.google.com/p/gperftools][pprof]]
+in the format expected by the [[https://github.com/google/pprof][pprof]]
 profiling tool, while [[https://golang.org/pkg/net/http/pprof][net/http/pprof]]
 provides HTTP endpoints to present profiling data in this format.
 Client code uses the package path to import the package, so there is no

content/race-detector.article

@@ -22,11 +22,11 @@ It is currently available for Linux, OS X, and Windows systems
 with 64-bit x86 processors.
 
 The race detector is based on the C/C++
-[[https://code.google.com/p/thread-sanitizer/][ThreadSanitizer runtime library]],
+[[https://github.com/google/sanitizers][ThreadSanitizer runtime library]],
 which has been used to detect many errors in Google's internal code base and in
 [[http://www.chromium.org/][Chromium]].
 The technology was integrated with Go in September 2012; since then it has detected
-[[https://code.google.com/p/go/issues/list?can=1&q=ThreadSanitizer][42 races]]
+[[https://github.com/golang/go/issues?utf8=%E2%9C%93&q=ThreadSanitizer][42 races]]
 in the standard library. It is now part of our continuous build process,
 where it continues to catch race conditions as they arise.
 
@@ -37,7 +37,7 @@ The race detector is integrated with the go tool chain. When the
 with code that records when and how the memory was accessed, while the runtime
 library watches for unsynchronized accesses to shared variables.
 When such "racy" behavior is detected, a warning is printed.
-(See [[https://code.google.com/p/thread-sanitizer/wiki/Algorithm][this article]]
+(See [[https://github.com/google/sanitizers/wiki/ThreadSanitizerAlgorithm][this article]]
 for the details of the algorithm.)
 
 Because of its design, the race detector can detect race conditions only when
@@ -165,22 +165,22 @@ is delegated to this potentially more efficient call:
 	writer.ReadFrom(reader)
 
 We
-[[https://code.google.com/p/go/source/detail?r=13faa632ba3a#][added a ReadFrom method]]
+[[https://golang.org/cl/4817041][added a ReadFrom method]]
 to Discard's underlying type, which has an internal buffer that is shared
 between all its users.
 We knew this was theoretically a race condition, but since all writes to the
 buffer should be thrown away we didn't think it was important.
 
 When the race detector was implemented it immediately
-[[https://code.google.com/p/go/issues/detail?id=3970][flagged this code]] as racy.
+[[https://golang.org/issue/3970][flagged this code]] as racy.
 Again, we considered that the code might be problematic, but decided that the
 race condition wasn't "real".
 To avoid the "false positive" in our build we implemented
-[[https://code.google.com/p/go/source/detail?r=1e55cf10aa4f][a non-racy version]]
+[[https://golang.org/cl/6624059][a non-racy version]]
 that is enabled only when the race detector is running.
 
-But a few months later [[http://bradfitz.com/][Brad]] encountered a
-[[https://code.google.com/p/go/issues/detail?id=4589][frustrating and strange bug]].
+But a few months later [[https://bradfitz.com/][Brad]] encountered a
+[[https://golang.org/issue/4589][frustrating and strange bug]].
 After a few days of debugging, he narrowed it down to a real race condition
 caused by `ioutil.Discard`.
 
@@ -232,7 +232,7 @@ No errors or panics occurred, but the hashes were wrong. Nasty!
 	}
 
 The bug was finally
-[[https://code.google.com/p/go/source/detail?r=4b61f121966b][fixed]]
+[[https://golang.org/cl/7011047][fixed]]
 by giving a unique buffer to each use of `ioutil.Discard`, eliminating the race
 condition on the shared buffer.