As an optimization, function literals capture variables by value when
they're not assigned and their address has not been taken. Because
result parameters are implicitly assigned through return statements
(which do not otherwise set the "assigned" flag), result parameters
are explicitly handled to always capture by reference.

However, the logic was slightly mistaken because it was only checking
if the variable in the immediately enclosing context was a return
parameter, whereas in a multiply-nested function literal it would
itself be another closure variable (PAUTOHEAP) rather than a return
parameter (PPARAMOUT).

The fix is to simply test the outermost variable, like the rest of the
if statement's tests were already doing.

Fixes #32175.

Change-Id: Ibadde033ff89a1b47584b3f56c0014d8e5a74512
Reviewed-on: https://go-review.googlesource.com/c/go/+/178541
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #29662

Change-Id: I38b52b96712e44a323333da17dbbc883516773b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/177900Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

To a fifth reading of the relevant docs, it looks like

1) a constraint dictionary with no policy applies to all of them;
2) multiple applying constraint dictionaries should have their results OR'd;
3) untrusted certificates in the keychain should be used for chain building.

This fixes 1), approximates 2) and punts on 3).

Fixes #30672
Fixes #30471

Change-Id: Ibbaabf0b77d267377c0b5de07abca3445c2c2302
Reviewed-on: https://go-review.googlesource.com/c/go/+/178539Reviewed-by: Adam Langley <agl@golang.org>

Note how untrustedData is never NULL, so loadSystemRoots was checking
the wrong thing.

Also, renamed the C function to CopyPEMRoots to follow the
CoreFoundation naming convention on ownership.

Finally, redirect all debug output to standard error.

Change-Id: Ie80abefadf8974a75c0646aa02fcfcebcbe3bde8
Reviewed-on: https://go-review.googlesource.com/c/go/+/178538Reviewed-by: Adam Langley <agl@golang.org>

CFDictionaryGetValueIfPresent does not take ownership of the value, so
releasing the properties dictionary before passing the value to CFEqual
can crash. Not really clear why this works most of the time.

See https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html

Fixes #28092
Hopefully fixes #30763

Change-Id: I5ee7ca276b753a48abc3aedfb78b8af68b448dd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/178537Reviewed-by: Adam Langley <agl@golang.org>

Shorten some of the longest tests that run during all.bash.
Removes 7r 50u 21s from all.bash.

After this change, all.bash is under 5 minutes again on my laptop.

For #26473.

Change-Id: Ie0460aa935808d65460408feaed210fbaa1d5d79
Reviewed-on: https://go-review.googlesource.com/c/go/+/177559
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Each different file that does import "C" must be compiled
and analyzed separately by cgo. Having fewer files import "C"
reduces the cost of building the test. This is especially important
because this test is built and run four different times (with different
settings) during all.bash.

go test -c in this directory used to take over 20 seconds on my laptop.
Now it takes under 5 seconds.

Removes 23.4r 29.0u 21.5s from all.bash.

For #26473.

Change-Id: Ie7cb7b0d9d6138ebd2eb548d0d8ea6e409ae10b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/177558
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

First, remove the randomization of initialization order.

Then, revert to source code order instead of sorted package path order.

This restores the behavior that was in 1.12.

A larger change which will implement the suggestion in #31636 will
wait for 1.14. It's too complicated for 1.13 at this point (it has
tricky interactions with plugins).

Fixes #31636

Change-Id: I35b48e8cc21cf9f93c0973edd9193d2eac197628
Reviewed-on: https://go-review.googlesource.com/c/go/+/178297
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

If the char class is 0x0-0x10ffff we mistakenly would String that to `[^]`,
which is not a valid regex.

Fixes #31807

Change-Id: I9ceeaddc28b67b8e1de12b6703bcb124cc784556
Reviewed-on: https://go-review.googlesource.com/c/go/+/175679Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The Wrapper type no longer exists.

Change-Id: I21051f26c6722a957295819f2f385f2bbd0db355
Reviewed-on: https://go-review.googlesource.com/c/go/+/177618Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #31267

Change-Id: I91e4aa8cf9d797689cb9612d0fe3bf1bb3ad15a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/178177Reviewed-by: Keith Randall <khr@golang.org>

Gerrit is complaining about pushes that affect these files
and forcing people to use -o nokeycheck, which defeats
the point of the check. Hide the keys from this kind of scan
by marking them explicitly as testing keys.

This is a little annoying but better than training everyone
who ever edits one of these test files to reflexively override
the Gerrit check.

The only remaining keys explicitly marked as private instead
of testing are in examples, and there's not much to do
about those. Hopefully they are not edited as much.

Change-Id: I4431592b5266cb39fe6a80b40e742d97da803a0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/178178
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Build a single binary containing all the TestPointerChecks
instead of building many small binaries,
each with its own cgo+compile+link invocation.
This cuts 'go test -run=TestPointerChecks'
from 6.7r 35.5u 26.1s to 2.1r 2.1u 1.4s.

Move as many cgo checks as possible into fewer test files
for TestReportsTypeErrors too.
This cuts 'go test -run=TestReportsTypeErrors'
from 2.1r 6.7u 6.7s to 1.5r 2.5u 2.5s.

After this change, all.bash runs in ~4:30 on my laptop.

For #26473.

Change-Id: I3787448b03689a1f62dd810957ab6013bb75582f
Reviewed-on: https://go-review.googlesource.com/c/go/+/177599
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Cuts api test time from 12.7r 26.2u 14.2s to 7.5r 12.1u 2.2s.

After this change, all.bash runs in ~4:36 on my laptop.

For #26473.

Change-Id: I4211e6afcd7ab61a4ed2c9a2aa5ac1ea04982695
Reviewed-on: https://go-review.googlesource.com/c/go/+/177597
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

typecheck type alias always replaces the original definition of the symbol.
This is wrong behavior because if the symbol's definition is replaced by a
local type alias, it ends up being written to compiled file as an alias,
instead of the original type.

To fix, only replace the definition of symbol with global type alias.

Fixes #31959

Change-Id: Id85a15e8a9d6a4b06727e655a95dc81e63df633a
Reviewed-on: https://go-review.googlesource.com/c/go/+/177378
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Fixes #31896

Change-Id: I228a809568cd37c599987f9f1e99df5c229e6c9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/176112
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Change-Id: Ie299a5eca6f6a7c5a37c00ff0de7ce322450375b
Reviewed-on: https://go-review.googlesource.com/c/go/+/178123Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This change modifies Go to include image/webp as a built-in mime type for the .webp file extension.

Change-Id: Id46d34fac8cc859ddd69aa8669294815654214f8
GitHub-Last-Rev: f191e1c325126e2caeb3123c912131ce5236542b
GitHub-Pull-Request: golang/go#32157
Reviewed-on: https://go-review.googlesource.com/c/go/+/178317Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

The test/codegen tests check all architectures
mentioned in the test file, but this requires
building at least the runtime for that architecture.
This CL changes the test to only check the local
architecture, leaving checking of other architectures
to the relevant builders, as usual.

This cuts 'go run run.go codegen' by 12r 78u 21s.

After this change, all.bash runs in ~4:40 on my laptop.

For #26473.

Change-Id: Ia0354d1aff2df2949f838528c8171410bc42dc8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/177577
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Both types.Sym and obj.LSym have the field Name, and that field is
widely used in compiler source. It can lead to confusion that when to
use which one.

So, adding documentation for clarifying the difference between them,
eliminate the confusion, or at least, make the code which use them
clearer for the reader.

See https://github.com/golang/go/issues/31252#issuecomment-481929174

Change-Id: I31f7fc6e4de4cf68f67ab2e3a385a7f451c796f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/175019Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Fixes #32037

Change-Id: I696fe2029e383746252f37fe8d30df71b5ac8a6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/177677
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Change-Id: Id87db9bed5e8715d554c1bf95c063d7d0a03c3e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/178117
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

That way we will never have to look up the file/line for the frame
that's next to be returned when the user stops calling Next.

For the benchmark from #32093:

name      old time/op  new time/op  delta
Helper-4   948ns ± 1%   836ns ± 3%  -11.89%  (p=0.000 n=9+9)

(#32093 was fixed with a more specific, and better, fix, but this
fix is much more general.)

Change-Id: I89e796f80c9706706d8d8b30eb14be3a8a442846
Reviewed-on: https://go-review.googlesource.com/c/go/+/178077
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently, this test allocates many objects and relies on heap-growth
scavenging to happen unconditionally on heap-growth. However with the
new pacing system for the scavenging, this is no longer true and the
test is flaky.

So, this change overhauls TestPhysicalMemoryUtilization to check the
same aspect of the runtime, but in a much more robust way.

Firstly, it sets up a much more constrained scenario: only 5 objects are
allocated total with a maximum worst-case (i.e. the test fails) memory
footprint of about 16 MiB. The test is now aware that scavenging will
only happen if the heap growth causes us to push way past our scavenge
goal, which is based on the heap goal. So, it makes the holes in the
test much bigger and the actual retained allocations much smaller to
keep the heap goal at the heap's minimum size. It does this twice to
create exactly two unscavenged holes. Because the ratio between the size
of the "saved" objects and the "condemned" object is so small, two holes
are sufficient to create a consistent test.

Then, the test allocates one enormous object (the size of the 4 other
objects allocated, combined) with the intent that heap-growth scavenging
should kick in and scavenge the holes. The heap goal will rise after
this object is allocated, so it's very important we do all the
scavenging in a single allocation that exceeds the heap goal because
otherwise the rising heap goal could foil our test.

Finally, we check memory use relative to HeapAlloc as before. Since the
runtime should scavenge the entirety of the remaining holes,
theoretically there should be no more free and unscavenged memory.
However due to other allocations that may happen during the test we may
still see unscavenged memory, so we need to have some threshold. We keep
the current 10% threshold which, while arbitrary, is very conservative
and should easily account for any other allocations the test makes.

Before, we also had to ensure the allocations we were making looked
large relative to the size of a heap arena since newly-mapped memory was
considered unscavenged, and so that could significantly skew the test.
However, thanks to the fix for #32012 we were able to reduce memory use
to 16 MiB in the worst case.

Fixes #32010.

Change-Id: Ia38130481e292f581da7fa3289c98c99dc5394ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/177237Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #32145

Change-Id: If4c9dd3a2af748974141ad6e571f80efcbaad772
Reviewed-on: https://go-review.googlesource.com/c/go/+/177899Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

If we look at the issues in the past releases that are related
to go command that involved modules, its usually mention or ask about
the value of GO111MODULE, either in separate line or in separate
comment.

There are quite long time range before GO111MODULE will be removed
(unused).  The next release is still default to auto [1], and until Go
1.13 unsupported (two releases after that) there is about one and half
years after that.

Since the change is not that big (one line) [2], maybe temporary adding
it to "go env" give more clarity and benefit in issue reporting rather
than not.

[1] https://github.com/golang/go/issues/31857

Fixes #29656

Change-Id: I609ad6664774018e4f4147ec6158485172968e16
Reviewed-on: https://go-review.googlesource.com/c/go/+/176837
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

CL 14870 added internal/race to factor out duplicated race thunks,
we should use it.

No signification changes in compile time and compile binary size.

Change-Id: I786af44dd5bb0f4ab6709432eeb603f27a5b6c63
Reviewed-on: https://go-review.googlesource.com/c/go/+/178118
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The "After it is called, changing rw.Header will not affect
rw.HeaderMap" claim predates the Result method which changed how the
Recorder should be used.

Fixes #32144
Fixes #32136

Change-Id: I95bdfa5ac489ce7b0202824bb5663f4da188e8a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/178058Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

Change-Id: I357669d8c9bc004031b17f057803c9b152edefee
Reviewed-on: https://go-review.googlesource.com/c/go/+/178057Reviewed-by: Ian Lance Taylor <iant@golang.org>

The chunks that were referenced by fd.iovecs would not be GC.

Change-Id: I7bfcb91a3fef57a4a1861168e9cd3ab55ce1334e
GitHub-Last-Rev: e0b7f68447441fd89ed1a6e8aa37e2084fd863b2
GitHub-Pull-Request: golang/go#32138
Reviewed-on: https://go-review.googlesource.com/c/go/+/178037
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Make the extended precision add-with-carry and sub-with-carry operations
take a constant amount of time to execute, regardless of input.

name             old time/op  new time/op  delta
Add-4            1.16ns ±11%  1.51ns ± 5%  +30.52%  (p=0.008 n=5+5)
Add32-4          1.08ns ± 0%  1.03ns ± 1%   -4.86%  (p=0.029 n=4+4)
Add64-4          1.09ns ± 1%  1.95ns ± 3%  +79.23%  (p=0.008 n=5+5)
Add64multiple-4  4.03ns ± 1%  4.55ns ±11%  +13.07%  (p=0.008 n=5+5)
Sub-4            1.08ns ± 1%  1.50ns ± 0%  +38.17%  (p=0.016 n=5+4)
Sub32-4          1.09ns ± 2%  1.53ns ±10%  +40.26%  (p=0.008 n=5+5)
Sub64-4          1.10ns ± 1%  1.47ns ± 1%  +33.39%  (p=0.008 n=5+5)
Sub64multiple-4  4.30ns ± 2%  4.08ns ± 4%   -5.07%  (p=0.032 n=5+5)

Fixes #31267

Change-Id: I1824b1b3ab8f09902ce8b5fef84ce2fdb8847ed9
Reviewed-on: https://go-review.googlesource.com/c/go/+/170758Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

callerName requested 2 PCs from Callers, and that causes
both to be looked up in the file/line mapping.
We really only need to do the work for one PC.
(And in fact the caller doesn't need file/line at all, but
the Callers API can't express that.)

We used to request 2 PCs because in 1.11 and earlier we
stored an inline skip count in the second entry.
That's not necessary any more (as of 1.12).

Fixes #32093

Change-Id: I7b272626ef6496e848ee8af388cdaafd2556857b
Reviewed-on: https://go-review.googlesource.com/c/go/+/177858
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Caleb Spare <cespare@gmail.com>

name        old alloc/op      new alloc/op      delta
Template         37.1MB ± 0%       36.8MB ± 0%  -0.57%  (p=0.008 n=5+5)
Unicode          28.1MB ± 0%       28.1MB ± 0%  -0.07%  (p=0.008 n=5+5)
GoTypes           125MB ± 0%        124MB ± 0%  -0.61%  (p=0.008 n=5+5)
Compiler          571MB ± 0%        568MB ± 0%  -0.60%  (p=0.008 n=5+5)
SSA              1.88GB ± 0%       1.86GB ± 0%  -0.82%  (p=0.008 n=5+5)
Flate            22.9MB ± 0%       22.8MB ± 0%  -0.59%  (p=0.008 n=5+5)
GoParser         27.5MB ± 0%       27.3MB ± 0%  -0.53%  (p=0.008 n=5+5)
Reflect          79.8MB ± 0%       79.5MB ± 0%  -0.40%  (p=0.008 n=5+5)
Tar              34.9MB ± 0%       34.7MB ± 0%  -0.44%  (p=0.008 n=5+5)
XML              45.7MB ± 0%       45.4MB ± 0%  -0.58%  (p=0.008 n=5+5)
[Geo mean]       80.3MB            79.9MB       -0.52%

name        old allocs/op     new allocs/op     delta
Template           380k ± 0%         378k ± 0%  -0.57%  (p=0.008 n=5+5)
Unicode            340k ± 0%         340k ± 0%  -0.08%  (p=0.008 n=5+5)
GoTypes           1.36M ± 0%        1.36M ± 0%  -0.44%  (p=0.008 n=5+5)
Compiler          5.52M ± 0%        5.49M ± 0%  -0.45%  (p=0.008 n=5+5)
SSA               17.6M ± 0%        17.5M ± 0%  -0.42%  (p=0.008 n=5+5)
Flate              235k ± 0%         234k ± 0%  -0.65%  (p=0.008 n=5+5)
GoParser           302k ± 0%         300k ± 0%  -0.70%  (p=0.008 n=5+5)
Reflect            982k ± 0%         978k ± 0%  -0.40%  (p=0.008 n=5+5)
Tar                353k ± 0%         351k ± 0%  -0.53%  (p=0.008 n=5+5)
XML                437k ± 0%         435k ± 0%  -0.48%  (p=0.008 n=5+5)
[Geo mean]         844k              840k       -0.47%

Updates #27739

Change-Id: I5d533013270cbbd7c0bad1b43da96c8499be76f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/177917
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

In TLS 1.3 session tickets are delivered after the handshake, and it
looks like now the Google servers wait until the first flight of data to
send them (or our timeout is too low). Cause some data to be sent so we
can avoid the guessing game.

Fixes #32090

Change-Id: I54af4acb3a89cc70c9e14a5dfe18a44c29a841a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/177877Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The motivation for doing so is to avoid making inaccurate claims.
Logging may not go to os.Stderr if anyone overrides the log package's
default output via https://godoc.org/log#SetOutput. Saying that
the standard logger is used should be sufficient to explain the
behavior, and users can infer that os.Stderr is used by default,
unless it's changed.

This change is the same as what was applied to http.Server.ErrorLog
documentation in CL 53950.

Change-Id: I32873fc548ceee573f8616b4d49b8a8b98881803
Reviewed-on: https://go-review.googlesource.com/c/go/+/176817Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When we downgrade a module (using 'go get m@none' or similar), we
exclude versions of other modules that depend on it. We'll try
previous versions (in the "versions" list returned by the proxy or in
codeRepo.Versions for vcs) until we find a version that doesn't
require an excluded module version.

If older versions of a module are broken for some reason,
mvs.Downgrade currently panics. With this change, we ignore versions
with errors during downgrade.

A frequent cause of this is incompatible v2+ versions. These are
common if a repository tagged v2.0.0 before migrating to modules, then
tagged v2.0.1 with a go.mod file later. v2.0.0 is incorrectly
considered part of the v2 module.

Fixes #31942

Change-Id: Icaa75c5c93f73f18a400c22f18a8cc603aa4011a
Reviewed-on: https://go-review.googlesource.com/c/go/+/177337
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

The current example illustrates using As when the error is able to be
interpreted as an os.PathError, but elides the "else" case. This CL adds the
small extra else case to make it clear that it's not safe to assume As will
return true.

This CL also squash the err instantiation and the err nil check into one line
for brevity.

Change-Id: I3d3ab483ffb38fb2788d0498b3f03229a87dd7c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/177717Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Support for Ed25519 certificates was added in CL 175478, this wires them
up into the TLS stack according to RFC 8422 (TLS 1.2) and RFC 8446 (TLS 1.3).

RFC 8422 also specifies support for TLS 1.0 and 1.1, and I initially
implemented that, but even OpenSSL doesn't take the complexity, so I
just dropped it. It would have required keeping a buffer of the
handshake transcript in order to do the direct Ed25519 signatures. We
effectively need to support TLS 1.2 because it shares ClientHello
signature algorithms with TLS 1.3.

While at it, reordered the advertised signature algorithms in the rough
order we would want to use them, also based on what curves have fast
constant-time implementations.

Client and client auth tests changed because of the change in advertised
signature algorithms in ClientHello and CertificateRequest.

Fixes #25355

Change-Id: I9fdd839afde4fd6b13fcbc5cc7017fd8c35085ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/177698
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

A timespec on netbsd/amd64 is int64/int64, not int64/int32.
This bug appears to have been introduced in 7777bac6.

Spotted by Cherry Zhang while reviewing https://go-review.googlesource.com/c/go/+/177120.

Change-Id: I163c55d926965defd981bdbfd2511de7d9d4c542
Reviewed-on: https://go-review.googlesource.com/c/go/+/177637Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>

Fix various bugs in the netbsd/arm64 runtime assembly.

Updates #30824.

Change-Id: I5ca10926ab663a8ff4df9973530e645e2469c1aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/177120Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>