doc: drop scheme from links that are known to support HTTPS
golang.org now serves HTTPS with a valid cert, so it's reasonable
that users should click through to the HTTPS versions of *.golang.org
and other known sites.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/112650043
diff --git a/doc/go1.3.html b/doc/go1.3.html
index ae5c025..0d2bda1 100644
--- a/doc/go1.3.html
+++ b/doc/go1.3.html
@@ -66,7 +66,7 @@
There is not yet support for Native Client on ARM.
Note that this is Native Client (NaCl), not Portable Native Client (PNaCl).
Details about Native Client are <a href="https://developers.google.com/native-client/dev/">here</a>;
-how to set up the Go version is described <a href="http://golang.org/wiki/NativeClient">here</a>.
+how to set up the Go version is described <a href="//golang.org/wiki/NativeClient">here</a>.
</p>
<h3 id="netbsd">Support for NetBSD</h3>
@@ -118,7 +118,7 @@
The overhead of this transfer operation amortizes well and eliminates the old "hot spot"
problem when a calculation repeatedly steps across a segment boundary.
Details including performance numbers are in this
-<a href="http://golang.org/s/contigstacks">design document</a>.
+<a href="//golang.org/s/contigstacks">design document</a>.
</p>
<h3 id="garbage_collector">Changes to the garbage collector</h3>
@@ -141,7 +141,7 @@
in integer-typed values are also illegal but more difficult to diagnose during execution.
Because the pointers are hidden from the runtime, a stack expansion or garbage collection
may reclaim the memory they point at, creating
-<a href="http://en.wikipedia.org/wiki/Dangling_pointer">dangling pointers</a>.
+<a href="//en.wikipedia.org/wiki/Dangling_pointer">dangling pointers</a>.
</p>
<p>
@@ -154,7 +154,7 @@
<p>
Iterations over small maps no longer happen in a consistent order.
-Go 1 defines that “<a href="http://golang.org/ref/spec#For_statements">The iteration order over maps
+Go 1 defines that “<a href="//golang.org/ref/spec#For_statements">The iteration order over maps
is not specified and is not guaranteed to be the same from one iteration to the next.</a>”
To keep code from depending on map iteration order,
Go 1.0 started each map iteration at a random index in the map.
@@ -175,7 +175,7 @@
<h3 id="liblink">The linker</h3>
<p>
-As part of the general <a href="http://golang.org/s/go13linker">overhaul</a> to
+As part of the general <a href="//golang.org/s/go13linker">overhaul</a> to
the Go linker, the compilers and linkers have been refactored.
The linker is still a C program, but now the instruction selection phase that
was part of the linker has been moved to the compiler through the creation of a new
@@ -298,7 +298,7 @@
<h3 id="godoc">Changes to godoc</h3>
<p>
When invoked with the <code>-analysis</code> flag,
-<a href="http://godoc.org/code.google.com/p/go.tools/cmd/godoc">godoc</a>
+<a href="//godoc.org/code.google.com/p/go.tools/cmd/godoc">godoc</a>
now performs sophisticated <a href="/lib/godoc/analysis/help.html">static
analysis</a> of the code it indexes.
The results of analysis are presented in both the source view and the
@@ -318,7 +318,7 @@
The program <code>misc/benchcmp</code> that compares
performance across benchmarking runs has been rewritten.
Once a shell and awk script in the main repository, it is now a Go program in the <code>go.tools</code> repo.
-Documentation is <a href="http://godoc.org/code.google.com/p/go.tools/cmd/benchcmp">here</a>.
+Documentation is <a href="//godoc.org/code.google.com/p/go.tools/cmd/benchcmp">here</a>.
</p>
<p>
