Most of the issues that led to the decision on #30055 were related to
incompatibility with or faulty support for RSA-PSS (#29831, #29779,
v1.5 signatures). RSA-PSS is required by TLS 1.3, but is also available
to be negotiated in TLS 1.2.

Altering TLS 1.2 behavior based on GODEBUG=tls13=1 feels surprising, so
just disable RSA-PSS entirely in TLS 1.2 until TLS 1.3 is on by default,
so breakage happens all at once.

Updates #30055

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

Updates #30055

Change-Id: If68615c8e9daa4226125dcc6a6866f29f3cfeef1
Reviewed-on: https://go-review.googlesource.com/c/160997
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

If a certificate somehow has an AKID, it should still chain successfully
to a parent without a SKID, even if the latter is invalid according to
RFC 5280, because only the Subject is authoritative.

This reverts to the behavior before #29233 was fixed in 77013065. Roots
with the right subject will still be shadowed by roots with the right
SKID and the wrong subject, but that's been the case for a long time, and
is left for a more complete fix in Go 1.13.

Updates #30079

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

Change-Id: Idee94a1d93555d53442098dd7479982e3f5afbba
Reviewed-on: https://go-review.googlesource.com/c/161339Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

Change-Id: Ia830f59d6f6ca1bc506ec298ccfc154d9f94f01d
GitHub-Last-Rev: 3ab18d4fd1a8d4295713cbb7ff74f30b3838b6d3
GitHub-Pull-Request: golang/go#30067
Reviewed-on: https://go-review.googlesource.com/c/160829
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #22447
Fixes #22448

Change-Id: Ia24f42c31e014c79040ff927f1247dfb2318de4f
Reviewed-on: https://go-review.googlesource.com/c/160778Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>

Expand modules documentation to clarify why @none is useful. The
wording is the one suggested by rsc on the issue.

Fixes #26684

Change-Id: I76dc4ff87e50f1dd8536fd9ac1fd938adb29bee3
Reviewed-on: https://go-review.googlesource.com/c/161037Reviewed-by: Bryan C. Mills <bcmills@google.com>

Change-Id: Ib0a0d04aaaaa3c213fdb8646bd9b7dfdadae40d4
Reviewed-on: https://go-review.googlesource.com/c/160831Reviewed-by: Filippo Valsorda <filippo@golang.org>

Fixes #30065

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

Make sure the argument to memmove is of pointer type before we try to
get the element type.

This has been noticed for code that uses unsafe+linkname so it can
call runtime.memmove. Probably not the best thing to allow, but the
code is out there and we'd rather not break it unnecessarily.

Fixes #30061

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

We are copying the results to uninitialized stack space. Write
barrier is not needed.

Fixes #30041.

Change-Id: Ia91d74dbafd96dc2bd92de0cb479808991dda03e
Reviewed-on: https://go-review.googlesource.com/c/160737
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>

Fixes #30043

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

CL 159859 causes build failure with old clang versions (3.4.1) on FreeBSD 10.3/10.4.

Update #29962
Update #27619

Change-Id: I78264ac5d8d17eeae89a982e89aac988eb22b286
Reviewed-on: https://go-review.googlesource.com/c/160777
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

When scavenging small amounts it's possible we over-scavenge by a
significant margin since we choose to scavenge the largest spans first.
This over-scavenging is never accounted for.

With this change, we add a scavenge credit pool, similar to the reclaim
credit pool. Any time scavenging triggered by RSS growth starts up, it
checks if it can cash in some credit first. If after using all the
credit it still needs to scavenge, then any extra it does it adds back
into the credit pool.

This change mitigates the performance impact of golang.org/cl/159500 on
the Garbage benchmark. On Go1 it suggests some improvements, but most of
that is within the realm of noise (Revcomp seems very sensitive to
GC-related changes, both postively and negatively).

Garbage: https://perf.golang.org/search?q=upload:20190131.5
Go1:     https://perf.golang.org/search?q=upload:20190131.4

Performance change with both changes:

Garbage: https://perf.golang.org/search?q=upload:20190131.7
Go1:     https://perf.golang.org/search?q=upload:20190131.6

Change-Id: I87bd3c183e71656fdafef94714194b9fdbb77aa2
Reviewed-on: https://go-review.googlesource.com/c/160297Reviewed-by: Austin Clements <austin@google.com>

Because scavenged and unscavenged spans no longer coalesce, memory that
is freed no longer has a high likelihood of being re-scavenged. As a
result, if an application is allocating at a fast rate, it may work fast
enough to undo all the scavenging work performed by the runtime's
current scavenging mechanisms. This behavior is exacerbated by the
global best-fit allocation policy the runtime uses, since scavenged
spans are just as likely to be chosen as unscavenged spans on average.

To remedy that, we treat each allocation of scavenged space as a heap
growth, and scavenge other memory to make up for the allocation.

This change makes performance of the runtime slightly worse, as now
we're scavenging more often during allocation. The regression is
particularly obvious with the garbage benchmark (3%) but most of the Go1
benchmarks are within the margin of noise. A follow-up change should
help.

Garbage: https://perf.golang.org/search?q=upload:20190131.3
Go1:     https://perf.golang.org/search?q=upload:20190131.2

Updates #14045.

Change-Id: I44a7e6586eca33b5f97b6d40418db53a8a7ae715
Reviewed-on: https://go-review.googlesource.com/c/159500Reviewed-by: Austin Clements <austin@google.com>

GCC 9 has started emitting warnings when taking the address of a field
in a packed struct may cause a misaligned pointer. We use packed
structs in cgo to ensure that our field layout matches the C
compiler's layout. Our pointers are always aligned, so disable the warning

Fixes #29962

Change-Id: I7e290a7cf694a2c2958529e340ebed9fcd62089c
Reviewed-on: https://go-review.googlesource.com/c/159859
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

This update has been automatically generated using the updatecontrib
command at CL 160277:

	cd gotip
	go run golang.org/x/build/cmd/updatecontrib

Actions taken (relative to CONTRIBUTORS at origin/master):

	Added Aaron Cannon <cannona@fireantproductions.com>
	Added Andzej Maciusovic <andzej.maciusovic@gmail.com>
	Added Douglas Danger Manley <doug.manley@gmail.com>
	Added Federico Bond <federicobond@gmail.com>
	Added Frew Schmidt <github@frew.co>
	Added GitHub User @saitarunreddy (21041941) <saitarunreddypalla@gmail.com>
	Added GitHub User @tell-k (26263) <ffk2005@gmail.com>
	Added Guilherme Caruso <gui.martinscaruso@gmail.com>
	Added Jay Taylor <outtatime@gmail.com>
	Added Juan Pablo Civile <elementohb@gmail.com>
	Added Julien Kauffmann <julien.kauffmann@freelan.org>
	Added Maya Rashish <maya@NetBSD.org>
	Added Parminder Singh <parmsingh101@gmail.com>
	Added Peter Dotchev <dotchev@gmail.com>
	Added Quinten Yearsley <qyearsley@chromium.org>
	Added Ross Smith II <ross@smithii.com>
	Added Sean Chen <oohcode@gmail.com>
	Added Sebastiaan van Stijn <github@gone.nl>
	Added Sebastian Schmidt <yath@google.com>
	Added Sebastien Williams-Wynn <sebastien@cytora.com>
	Added Viacheslav Poturaev <vearutop@gmail.com>
	Added Yohei Takeda <yo.tak0812@gmail.com>
	Used GitHub User @saitarunreddy (21041941) form for saitarunreddy <saitarunreddypalla@gmail.com> https://github.com/golang/build/commit/269e03a [build]
	Used GitHub User @tell-k (26263) form for tell-k <ffk2005@gmail.com> https://github.com/golang/tools/commit/85a87a81 [tools]
	Used GitHub name "Akhil Indurti" for smasher164 <aindurti@gmail.com> https://github.com/golang/go/commit/a7af474359 [build go]
	Used GitHub name "Guilherme Caruso" for GuilhermeCaruso <gui.martinscaruso@gmail.com> https://github.com/golang/go/commit/5fae09b738 [go]
	Used GitHub name "Ivan Markin" for nogoegst <nogoegst@users.noreply.github.com> https://github.com/golang/go/commit/a1addf15df [go]
	Used GitHub name "Keiji Yoshida" for yosssi <yoshida.keiji.84@gmail.com> https://github.com/golang/lint/commit/ac6833c [lint]
	Used GitHub name "Marwan Sulaiman" for marwan-at-work <marwan.sameer@gmail.com> https://github.com/golang/go/commit/92caeef892 [go]
	Used GitHub name "Michalis Kargakis" for kargakis <mkargaki@redhat.com> https://github.com/golang/go/commit/e243d242d7 [go]
	Used GitHub name "Robin Eklind" for mewmew <rnd0x00@gmail.com> https://github.com/golang/go/commit/b8620afb8d [go proposal.git]
	Used GitHub name "Sean Chen" for two <oohcode@gmail.com> https://github.com/golang/sys/commit/302c3dd [sys]
	Used GitHub name "Sebastien Williams-Wynn" for GiantsLoveDeathMetal <sebastien@cytora.com> https://github.com/golang/go/commit/4e056ade24 [go]
	Used GitHub name "Yohei Takeda" for yo-tak <yo.tak0812@gmail.com> https://github.com/golang/go/commit/8b7cf898af [go]

Given that the scope of updatecontrib is only to add contributors to
CONTRIBUTORS file, without having to check CLAs or deal with legal
matters, we can relax the requirement of having a space in the name
before it gets added to the CONTRIBUTORS file. That will be done
in a later change.

Updates #12042

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

Note the removal of the go tool tour command in the Go 1.12 release
notes.

Updates #24819

Change-Id: I258ab9401ea2cc06a83328c67299376fcf23c980
Reviewed-on: https://go-review.googlesource.com/c/158618Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

Fixes #29983

Change-Id: I24077bde991e621c23d00973b2a77bb3a18e4ae7
Reviewed-on: https://go-review.googlesource.com/c/160180
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #29983

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

Change-Id: I744940e2bbde19ccec53af6c5469d46ba9161f01
Reviewed-on: https://go-review.googlesource.com/c/160179Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

- add EINTR loop on Darwin
- return PathError on error
- call newFile rather than NewFile

This tries to minimize the possibility of any future changes.
It would be nice to put openFdAt in the same file as openFileNolog,
but build tags forbid.

Updates #29983

Change-Id: I866002416d6473fbfd80ff6ef09b2bc4607f2934
Reviewed-on: https://go-review.googlesource.com/c/160181
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>

CL 159157 was doing UTF-8 decoding of URLs. URLs aren't really UTF-8,
even if sometimes they are in some contexts.

Instead, only reject ASCII CTLs.

Updates #27302
Updates #22907

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

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

Updates #28242

Change-Id: Ib717b64f1f368cc889895a2437ff2943ed4eab0d
Reviewed-on: https://go-review.googlesource.com/c/159998
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

Currently, if an assembly file includes a static reference to an
undefined symbol, and another package also has an undefined reference
to that symbol, the linker can report an error like:

  x: relocation target zero not defined for ABI0 (but is defined for ABI0)

Since the symbol is referenced in another package, the code in
ErrorUnresolved that looks for alternative ABI symbols finds that
symbol in the symbol table, but doesn't check that it's actually
defined, which is where the "but is defined for ABI0" comes from. The
"not defined for ABI0" is because ErrorUnresolved failed to turn the
static symbol's version back into an ABI, and it happened to print the
zero value for an ABI.

This CL fixes both of these problems. It explicitly maps the
relocation version back to an ABI and detects if it can't be mapped
back (e.g., because it's a static reference). Then, if it finds a
symbol with a different ABI in the symbol table, it checks to make
sure it's a definition, and not simply an unresolved reference.

Fixes #29852.

Change-Id: Ice45cc41c1907919ce5750f74588e8047eaa888c
Reviewed-on: https://go-review.googlesource.com/c/159518
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Updates #29919

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

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

TestIssue29372 is broken on windows when temporary directory has
symlink in its path.

Adjust the test to use filepath.EvalSymlinks of temporary directory,
instead of temporary directory on windows. This change is not a
proper fix, but at least it makes TestIssue29372 pass on windows-arm.

See issue for details.

Updates #29746

Change-Id: I2af8ebb89da7cb9daf027a5e49e32ee22dbd0e3d
Reviewed-on: https://go-review.googlesource.com/c/159578
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Treat compiler-generated init functions as wrappers, so they will not
be shown in tracebacks.

The exception to this rule is that we'd like to show the line number
of initializers for global variables in tracebacks. In order to
preserve line numbers for those cases, separate out the code for those
initializers into a separate function (which is not marked as
autogenerated).

This CL makes the go binary 0.2% bigger.

Fixes #29919

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

Whether a truncation should become a MOVWreg or a MOVWZreg doesn't
depend on the type of the operand, it depends on the type of the final
result.  If the final result is unsigned, we can use MOVWZreg.  If the
final result is signed, we can use MOVWreg.  Checking the type of the
operand does the wrong thing if truncating an unsigned value to a
signed value, or vice-versa.

Fixes #29943

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

Trivial typo

Change-Id: I3804f365519453bfa19997f55ead34742ac1a9db
GitHub-Last-Rev: 0e04e928d05121099b78a2cefc1cb7531f6a7650
GitHub-Pull-Request: golang/go#29930
Reviewed-on: https://go-review.googlesource.com/c/159479Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

Updates #28152
Fixes #29927

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

Fixes #26533

Change-Id: I5a48d667d474f3f222f9055e51131561a0cf45b6
Reviewed-on: https://go-review.googlesource.com/c/138757
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #28753
Updates #29628

Change-Id: I4a561be7d491a0d088e656b00151ae1bdbd16a84
Reviewed-on: https://go-review.googlesource.com/c/158357
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

If beta8 is unusually large, the addition loop might take a very long
time to bring x3-beta8 back positive.

This would lead to a DoS vulnerability in the implementation of the
P-521 and P-384 elliptic curves that may let an attacker craft inputs
to ScalarMult that consume excessive amounts of CPU.

This fixes CVE-2019-6486.

Fixes #29903

Change-Id: Ia969e8b5bf5ac4071a00722de9d5e4d856d8071a
Reviewed-on: https://team-review.git.corp.google.com/c/399777Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-on: https://go-review.googlesource.com/c/159218Reviewed-by: Julie Qiu <julie@golang.org>

Updates bundled http2 to x/net git rev ed066c81e7 for:

    http2: Revert a closed stream cannot receive data
    https://golang.org/cl/153977

Updates golang/go#28204

Change-Id: I0a489e4e8a581a107970199f64f0fa9281982efe
Reviewed-on: https://go-review.googlesource.com/c/159179
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

This is a more conservative version of the reverted CL 99135 (which
was reverted in CL 137716)

The net/url part rejects URLs with ASCII CTLs from being parsed and
the net/http part rejects writing them if a bogus url.URL is
constructed otherwise.

Updates #27302
Updates #22907

Change-Id: I09a2212eb74c63db575223277aec363c55421ed8
Reviewed-on: https://go-review.googlesource.com/c/159157
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>

I needed Go 1.10 to debug and fix a test failure on that Go version in
x/tools, but I forgot what the magic 'go get' command for this was.

Googling "download specific golang version" and similar keywords showed
no results, presumably because the golang.org/dl subrepo isn't
prominently recommended nor documented anywhere.

The most appropriate documentation page to add this to is doc/install,
since it goes into some detail and is well indexed. We only need a short
section to introduce the trick.

The example does mention a specific version, Go 1.10.7, but I couldn't
imagine a way to make it version-agnostic while still being clear on
what the commands effectively do.

Change-Id: I13158564d76d95caec412cdb35a50a4356df5863
Reviewed-on: https://go-review.googlesource.com/c/157457Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>