_content: rewrite links to https://go.dev/foo to /foo

We use /foo consistently so that people browsing on golang.google.cn are not redirected to go.dev. This CL is completely mechanical, replacing href="https://go.dev/ -> href="/ in HTML and replacing ](https://go.dev/ -> ](/ in Markdown. Change-Id: I8ac732d672075600c8e53c46787205454b196850 Reviewed-on: https://go-review.googlesource.com/c/website/+/548058 Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Russ Cox <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
golang · Dec 8, 2023 · 2d2fc5b · 2d2fc5b
1 parent 90162a8
commit 2d2fc5b
Show file tree

Hide file tree

Showing 38 changed files with 169 additions and 169 deletions.
diff --git a/_content/blog/14years.md b/_content/blog/14years.md
@@ -26,7 +26,7 @@ of your program that run most often.
 In Go 1.21, workloads typically get between
 2% and 7% CPU usage improvements from enabling PGO.
 See “[Profile-guided optimization in Go 1.21](/blog/pgo)” for an overview
-and the [profile-guided optimization user guide](https://go.dev/doc/pgo)
+and the [profile-guided optimization user guide](/doc/pgo)
 for complete documentation.
 
 Go has provided support for gathering coverage profiles during `go test`
@@ -108,7 +108,7 @@ dependencies and vulnerabilities,
 with [Govulncheck 1.0 launching in July](/blog/govulncheck).
 If you use VS Code, you can run govulncheck directly in your
 editor using the Go extension:
-see [this tutorial](https://go.dev/doc/tutorial/govulncheck-ide) to get started.
+see [this tutorial](/doc/tutorial/govulncheck-ide) to get started.
 And if you use GitHub, you can run govulncheck as part of
 your CI/CD, with the
 [GitHub Action for govulncheck](https://github.com/marketplace/actions/golang-govulncheck-action).

diff --git a/_content/blog/deconstructing-type-parameters.md b/_content/blog/deconstructing-type-parameters.md
@@ -81,7 +81,7 @@ replacing the type parameter with the type argument.
 func InstantiatedClone1(s []string) []string
 ```
 
-The [Go assignment rules](https://go.dev/ref/spec#Assignability) allow
+The [Go assignment rules](/ref/spec#Assignability) allow
 us to pass a value of type `MySlice` to a parameter of type
 `[]string`, so calling `Clone1` is fine.
 But `Clone1` will return a value of type `[]string`, not a value of
@@ -166,7 +166,7 @@ underlying type of `T2`.
 The underlying type of a predeclared type like `int` or a type literal
 like `[]string` is just the type itself.
 For the exact details, [see the language
-spec](https://go.dev/ref/spec#Underlying_types).
+spec](/ref/spec#Underlying_types).
 In our example, the underlying type of `MySlice` is `[]string`.
 
 Since the underlying type of `MySlice` is a slice, we can pass an

diff --git a/_content/blog/get-familiar-with-workspaces.md b/_content/blog/get-familiar-with-workspaces.md
@@ -13,20 +13,20 @@ summary: Learn about Go workspaces and some of the workflows they enable.
 Go 1.18 adds workspace mode to Go, which lets you work on multiple modules
 simultaneously.
 
-You can get Go 1.18 by visiting the [download](https://go.dev/dl/) page. The
-[release notes](https://go.dev/doc/go1.18) have more details about all the
+You can get Go 1.18 by visiting the [download](/dl/) page. The
+[release notes](/doc/go1.18) have more details about all the
 changes.
 
 ## Workspaces
 
-[Workspaces](https://go.dev/ref/mod#workspaces) in Go 1.18 let you work on
+[Workspaces](/ref/mod#workspaces) in Go 1.18 let you work on
 multiple modules simultaneously without having to edit `go.mod` files for each
 module. Each module within a workspace is treated as a main module when
 resolving dependencies.
 
 Previously, to add a feature to one module and use it in another module, you
 needed to either publish the changes to the first module, or [edit the
-go.mod](https://go.dev/doc/tutorial/call-module-code) file of the dependent
+go.mod](/doc/tutorial/call-module-code) file of the dependent
 module with a `replace` directive for your local, unpublished module changes. In
 order to publish without errors, you had to remove the `replace` directive from
 the dependent module's `go.mod` file after you published the local changes to
@@ -237,13 +237,13 @@ documentation](https://pkg.go.dev/golang.org/x/tools/gopls#readme-editors).
 
 ## What's next?
 
--  Download and install [Go 1.18](https://go.dev/dl/).
--  Try using [workspaces](https://go.dev/ref/mod#workspaces) with the [Go
-    workspaces Tutorial](https://go.dev/doc/tutorial/workspaces).
+-  Download and install [Go 1.18](/dl/).
+-  Try using [workspaces](/ref/mod#workspaces) with the [Go
+    workspaces Tutorial](/doc/tutorial/workspaces).
 -  If you encounter any problems with workspaces, or want to suggest
     something, file an [issue](https://github.com/golang/go/issues/new/choose).
 -  Read the
     [workspace maintenance documentation](https://pkg.go.dev/cmd/go#hdr-Workspace_maintenance).
 -  Explore module commands for [working outside of a single
-    module](https://go.dev/ref/mod#commands-outside) including `go work init`,
+    module](/ref/mod#commands-outside) including `go work init`,
     `go work sync` and more.
diff --git a/_content/blog/go1.18beta2.md b/_content/blog/go1.18beta2.md
@@ -8,9 +8,9 @@ summary: Go 1.18 Beta 2 is our second preview of Go 1.18. Please try it and let
 
 We are encouraged by all the excitement around Go’s upcoming 1.18 release,
 which adds support for
-[generics](https://go.dev/blog/why-generics),
-[fuzzing](https://go.dev/blog/fuzz-beta), and the new
-[Go workspace mode](https://go.dev/design/45713-workspace).
+[generics](/blog/why-generics),
+[fuzzing](/blog/fuzz-beta), and the new
+[Go workspace mode](/design/45713-workspace).
 
 We released Go 1.18 beta 1 two months ago,
 and it is now the most downloaded Go beta ever,
@@ -42,5 +42,5 @@ and to configure the VS Code Go extension, follow [this instruction](https://git
 
 
 As always, especially for beta releases,
-if you notice any problems, please [file an issue](https://go.dev/issue/new).
+if you notice any problems, please [file an issue](/issue/new).
 
diff --git a/_content/blog/go1.21rc.md b/_content/blog/go1.21rc.md
@@ -36,10 +36,10 @@ because a bug was found and fixed after tagging `go1.21rc1`)*
   has been expanded and clarified.
 - In a future version of Go we’re planning to address one of the most common
   gotchas of Go programming:
-  [loop variable capture](https://go.dev/wiki/CommonMistakes).
+  [loop variable capture](/wiki/CommonMistakes).
   Go 1.21 comes with a preview of this feature that you can enable in your code
   using an environment variable. See [this LoopvarExperiment wiki
-  page](https://go.dev/wiki/LoopvarExperiment) for more details.
+  page](/wiki/LoopvarExperiment) for more details.
 
 ## Standard library additions
 

diff --git a/_content/blog/go119runtime.md b/_content/blog/go119runtime.md
@@ -15,12 +15,12 @@ Let's catch you up on the highlights!
 ### What's new?
 
 - `sync.Pool`, a GC-aware tool for reusing memory, has a [lower latency
-  impact](https://go.dev/cl/166960) and [recycles memory much more
-  effectively](https://go.dev/cl/166961) than before.
+  impact](/cl/166960) and [recycles memory much more
+  effectively](/cl/166961) than before.
   (Go 1.13)
 
 - The Go runtime returns unneeded memory back to the operating system [much
-  more proactively](https://go.dev/issue/30333), reducing excess memory
+  more proactively](/issue/30333), reducing excess memory
   consumption and the chance of out-of-memory errors.
   This reduces idle memory consumption by up to 20%.
   (Go 1.13 and 1.14)
@@ -32,7 +32,7 @@ Let's catch you up on the highlights!
   (Go 1.14)
 
 - The Go runtime [manages timers more efficiently than
-  before](https://go.dev/cl/171883), especially on machines with many CPU cores.
+  before](/cl/171883), especially on machines with many CPU cores.
   (Go 1.14)
 
 - Function calls that have been deferred with the `defer` statement now cost as
@@ -41,8 +41,8 @@ Let's catch you up on the highlights!
   here.](https://www.youtube.com/watch?v=DHVeUsrKcbM)
   (Go 1.14)
 
-- The memory allocator's slow path [scales](https://go.dev/issue/35112)
-  [better](https://go.dev/issue/37487) with CPU cores, increasing throughput up
+- The memory allocator's slow path [scales](/issue/35112)
+  [better](/issue/37487) with CPU cores, increasing throughput up
   to 10% and decreasing tail latencies up to 30%, especially in highly-parallel
   programs.
   (Go 1.14 and 1.15)
@@ -55,24 +55,24 @@ Let's catch you up on the highlights!
   (Go 1.16)
 
 - The Go scheduler spends up to [30% less CPU time spinning to find new
-  work](https://go.dev/issue/43997).
+  work](/issue/43997).
   (Go 1.17)
 
 - Go code now follows a [register-based calling
-  convention](https://go.dev/issues/40724) on amd64, arm64, and ppc64, improving
+  convention](/issues/40724) on amd64, arm64, and ppc64, improving
   CPU efficiency by up to 15%.
   (Go 1.17 and Go 1.18)
 
 - The Go GC's internal accounting and scheduling has been
-  [redesigned](https://go.dev/issue/44167), resolving a variety of long-standing
+  [redesigned](/issue/44167), resolving a variety of long-standing
   issues related to efficiency and robustness.
   This results in a significant decrease in application tail latency (up to 66%)
   for applications where goroutines stacks are a substantial portion of memory
   use.
   (Go 1.18)
 
 - The Go GC now limits [its own CPU use when the application is
-  idle](https://go.dev/issue/44163).
+  idle](/issue/44163).
   This results in 75% lower CPU utilization during a GC cycle in very idle
   applications, reducing CPU spikes that can confuse job shapers.
   (Go 1.19)

diff --git a/_content/blog/gonew.md b/_content/blog/gonew.md
@@ -25,7 +25,7 @@ leveraging the Go module proxy and checksum database for better security and ava
 The prototype `gonew` is intentionally minimal:
 what we have released today is an extremely limited prototype meant to provide
 a base from which we can gather feedback and community direction.
-Try it out, [tell us what you think](https://go.dev/s/gonew-feedback),
+Try it out, [tell us what you think](/s/gonew-feedback),
 and help us build a more useful tool for everyone.
 
 ## Getting started
@@ -67,5 +67,5 @@ and [Service Weaver](https://github.com/ServiceWeaver/template) teams.
 
 Please try out `gonew` and let us know how we can make it better and more useful.
 Remember, `gonew` is just an experiment for now;
-we need your [feedback to get it right](https://go.dev/s/gonew-feedback).
+we need your [feedback to get it right](/s/gonew-feedback).
 
diff --git a/_content/blog/gopls-scalability.md b/_content/blog/gopls-scalability.md
@@ -18,7 +18,7 @@ summary: As the Go ecosystem gets bigger, gopls must get smaller
   }
 </style>
 
-Earlier this summer, the Go team released version [v0.12](https://go.dev/s/gopls-v0.12)
+Earlier this summer, the Go team released version [v0.12](/s/gopls-v0.12)
 of [gopls](https://pkg.go.dev/golang.org/x/tools/gopls),
 the [language server](https://microsoft.github.io/language-server-protocol/) for Go, featuring a rewrite of its core that allows
 it to scale to larger codebases.
@@ -66,7 +66,7 @@ Since its beginnings in 2018, gopls has consolidated many disparate command-line
 tools such as [guru](https://pkg.go.dev/golang.org/x/tools/cmd/guru),
 [gorename](https://pkg.go.dev/golang.org/x/tools/cmd/gorename),
 and [goimports](https://pkg.go.dev/golang.org/x/tools/cmd/goimports) and
-has become the [default backend for the VS Code Go extension](https://go.dev/blog/gopls-vscode-go)
+has become the [default backend for the VS Code Go extension](/blog/gopls-vscode-go)
 as well as many other editors and LSP plugins.
 Perhaps you’ve been using gopls through your editor without even knowing
 it---that’s the goal!
@@ -79,7 +79,7 @@ that gopls's high memory usage was barely tolerable.
 
 Meanwhile, the Go ecosystem was growing, with more code being written in
 larger repositories.
-[Go workspaces](https://go.dev/blog/get-familiar-with-workspaces) allowed
+[Go workspaces](/blog/get-familiar-with-workspaces) allowed
 developers to work on multiple modules simultaneously,
 and [containerized development](https://code.visualstudio.com/docs/devcontainers/containers)
 put language servers in increasingly resource-constrained environments.
@@ -183,7 +183,7 @@ require recompiling _all_ the packages that indirectly depend on that package.
 Pruned incremental rebuilds make the amount of work proportional to the
 scope of each change.
 This is not a new idea: it was introduced by [Vesta](https://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-177.pdf)
-and also used in [`go build`](https://go.dev/doc/go1.10#build).
+and also used in [`go build`](/doc/go1.10#build).
 
 The v0.12 release introduces a similar pruning technique to gopls,
 going one step further to implement a faster pruning heuristic based on syntactic analysis.
@@ -216,8 +216,8 @@ even in your user-defined wrappers around `fmt.Printf`.
 Notably, `go vet` has provided this level of precision for years,
 but gopls was unable to do this in real time after each edit. Now it can.
 
-The second is [simpler workspace configuration](https://go.dev/issue/57979)
-and [improved handling for build tags](https://go.dev/issue/29202).
+The second is [simpler workspace configuration](/issue/57979)
+and [improved handling for build tags](/issue/29202).
 These two features both amount to gopls "doing the right thing" when you
 open any Go file on your machine,
 but both were infeasible without the optimization work because (for example)

diff --git a/_content/blog/govulncheck.md b/_content/blog/govulncheck.md
@@ -9,12 +9,12 @@ summary: Version v1.0.0 of golang.org/x/vuln has been released, introducing a ne
 We are excited to announce that govulncheck v1.0.0 has been released,
 along with v1.0.0 of the API for integrating scanning into other tools!
 
-Go's support for vulnerability management was [first announced](https://go.dev/blog/vuln) last September.
+Go's support for vulnerability management was [first announced](/blog/vuln) last September.
 We have made several changes since then, culminating in today's release.
 
 This post describes Go's updated vulnerability tooling, and how to get started
 using it. We also recently published a
-[security best practices guide](https://go.dev/security/best-practices)
+[security best practices guide](/security/best-practices)
 to help you prioritize security in your Go projects.
 
 ## Govulncheck
@@ -38,7 +38,7 @@ Then, run govulncheck inside your module:
 govulncheck ./...
 ```
 
-See the [govulncheck tutorial](https://go.dev/doc/tutorial/govulncheck)
+See the [govulncheck tutorial](/doc/tutorial/govulncheck)
 for additional information on how to get started with using the tool.
 
 As of this release, there is now a stable API available,
@@ -55,17 +55,17 @@ which provides a comprehensive source of information about known vulnerabilities
 in public Go modules.
 You can browse the entries in the database at [pkg.go.dev/vuln](https://pkg.go.dev/vuln).
 
-Since the initial release, we have updated the [database API](https://go.dev/security/vuln/database#api)
+Since the initial release, we have updated the [database API](/security/vuln/database#api)
 to improve performance and ensure long-term extensibility.
 An experimental tool to generate your own vulnerability database index is
 provided at [golang.org/x/vulndb/cmd/indexdb](https://golang.org/x/vulndb/cmd/indexdb).
 
 If you are a Go package maintainer, we encourage you to
-[contribute information](https://go.dev/s/vulndb-report-new)
+[contribute information](/s/vulndb-report-new)
 about public vulnerabilities in your projects.
 
 For more information about the Go vulnerability database,
-see [go.dev/security/vuln/database](https://go.dev/security/vuln/database).
+see [go.dev/security/vuln/database](/security/vuln/database).
 
 ## Integrations
 
@@ -81,7 +81,7 @@ shows vulnerabilities in older versions of the module.
 
 You can also run govulncheck directly in your editor using the Go extension
 for Visual Studio Code.
-See [the tutorial](https://go.dev/doc/tutorial/govulncheck-ide) to get started.
+See [the tutorial](/doc/tutorial/govulncheck-ide) to get started.
 
 Lastly, we know that many developers will want to run govulncheck as part
 of their CI/CD systems.
@@ -98,7 +98,7 @@ we presented a walkthrough of these tools at Google I/O this year, in our talk,
 ## Feedback
 
 As always, we welcome your feedback! See details on
-[how to contribute and help us make improvements](https://go.dev/security/vuln/#feedback).
+[how to contribute and help us make improvements](/security/vuln/#feedback).
 
 We hope you’ll find the latest release of Go’s support for vulnerability
 management useful and work with us to build a more secure and reliable Go

diff --git a/_content/blog/integration-test-coverage.md b/_content/blog/integration-test-coverage.md
@@ -8,7 +8,7 @@ summary:  Code coverage for integration tests, available in Go 1.20.
 
 Code coverage tools help developers determine what fraction of a source code base is executed (covered) when a given test suite is executed.
 
-Go has for some time provided support ([introduced](https://go.dev/blog/cover) in the Go 1.2 release) to measure code coverage at the package level, using the **"-cover"** flag of the "go test" command.
+Go has for some time provided support ([introduced](/blog/cover) in the Go 1.2 release) to measure code coverage at the package level, using the **"-cover"** flag of the "go test" command.
 
 This tooling works well in most cases, but has some weaknesses for larger Go applications.
 For such applications, developers often write "integration" tests that verify the behavior of an entire program (in addition to package-level unit tests).

diff --git a/_content/blog/loopvar-preview.md b/_content/blog/loopvar-preview.md
@@ -40,7 +40,7 @@ For example, consider this program:
 The three created goroutines are all printing the same variable `v`,
 so they usually print “c”, “c”, “c”, instead of printing “a”, “b”, and “c” in some order.
 
-The [Go FAQ entry “What happens with closures running as goroutines?”](https://go.dev/doc/faq#closures_and_goroutines),
+The [Go FAQ entry “What happens with closures running as goroutines?”](/doc/faq#closures_and_goroutines),
 gives this example and remarks
 “Some confusion may arise when using closures with concurrency.”
 
@@ -168,7 +168,7 @@ we have had zero reports of any problems in production code.
 
 You can also try test programs to better understand the semantics
 on the Go playground by including a `// GOEXPERIMENT=loopvar` comment
-at the top of the program, like in [this program](https://go.dev/play/p/YchKkkA1ETH).
+at the top of the program, like in [this program](/play/p/YchKkkA1ETH).
 (This comment only applies in the Go playground.)
 
 ## Fixing Buggy Tests
@@ -200,7 +200,7 @@ Fixing for loops exposes this kind of buggy test.
 To help prepare for this kind of discovery, we improved the precision
 of the `loopclosure` analyzer in Go 1.21 so that it can identify and
 report this problem.
-You can see the report [in this program](https://go.dev/play/p/WkJkgXRXg0m) on the Go playground.
+You can see the report [in this program](/play/p/WkJkgXRXg0m) on the Go playground.
 If `go vet` is reporting this kind of problem in your own tests,
 fixing them will prepare you better for Go 1.22.
 
@@ -214,5 +214,5 @@ which specific loop is causing a test failure when the new semantics are applied
 For more information about the change, see the
 [design document](https://go.googlesource.com/proposal/+/master/design/60078-loopvar.md)
 and the
-[FAQ](https://go.dev/wiki/LoopvarExperiment).
+[FAQ](/wiki/LoopvarExperiment).