commit e92be18fd8b525b642ca25bdb3e2056b35d9d73c [browse]
Author: Rodolfo Carvalho
Date: 2020-06-10 13:30:42 Z

runtime: fix typo in FuncForPC doc

Change-Id: I04037e13b131e79ebc5af84896bfeda49ddc0eaa
GitHub-Last-Rev: b0d0de930862e4f163e158876cba70d81ed2d52e
GitHub-Pull-Request: golang/go#39500
Reviewed-on: https://go-review.googlesource.com/c/go/+/237220
Reviewed-by: Keith Randall <khr@golang.org>

commit ac743dea8e7d351d48a79bf4e7aea62ba3b4a515 [browse]
Author: Michael Munday
Date: 2020-06-09 03:17:17 -07:00

cmd/compile: always tighten and de-duplicate tuple selectors

The scheduler assumes two special invariants that apply to tuple
selectors (Select0 and Select1 ops):

  1. There is only one tuple selector of each type per generator.
  2. Tuple selectors and generators reside in the same block.

Prior to this CL the assumption was that these invariants would
only be broken by the CSE pass. The CSE pass therefore contained
code to move and de-duplicate selectors to fix these invariants.

However it is also possible to write relatively basic optimization
rules that cause these invariants to be broken. For example:

  (A (Select0 (B))) -> (Select1 (B))

This rule could result in the newly added selector (Select1) being
in a different block to the tuple generator (see issue #38356). It
could also result in duplicate selectors if this rule matches
multiple times for the same tuple generator (see issue #39472).

The CSE pass will 'fix' these invariants. However it will only do
so when optimizations are enabled (since disabling optimizations
disables the CSE pass).

This CL moves the CSE tuple selector fixup code into its own pass
and makes it mandatory even when optimizations are disabled. This
allows tuple selectors to be treated like normal ops for most of
the compilation pipeline until after the new pass has run, at which
point we need to be careful to maintain the invariant again.

Fixes #39472.

Change-Id: Ia3f79e09d9c65ac95f897ce37e967ee1258a080b
Reviewed-on: https://go-review.googlesource.com/c/go/+/237118
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

commit 2a4e71c752875f84dc0061f75fdcbfc96ae8d5f2 [browse]
Author: Bryan C. Mills
Date: 2020-06-09 22:00:18 -04:00

run.bat: do not unset GOROOT_FINAL before running tests

This removes the same logic from run.bat that was removed from
cmd/dist in CL 236819.

The duplicated logic was removed from run.bash and run.rc in CL 6531,
but that part of run.bat was apparently missed (and not noticed
because its effect was redundant).

Also fix a path-separator bug in cmd/addr2line.TestAddr2Line that was
exposed as a result.

Fixes #39478
Updates #39385

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

commit b9332ed31aa4c2b73134a1b968761fc4c259ccac [browse]
Author: Russ Cox
Date: 2020-06-05 13:51:17 -04:00

doc: document encoding/xml change in CL 203417

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

commit 7b872b6d955d3e749ea62dbfced68ab5c61eae91 [browse]
Author: Roland Shoemaker
Date: 2020-05-15 12:49:04 -07:00

crypto/tls: restore OCSP and SCTs during session resumption

Restore previously sent SCTs and stapled OCSP response during session
resumption for both TLS 1.2 and 1.3. This behavior is somewhat
complicated for TLS 1.2 as SCTs are sent during the server hello,
so they override what is saved in ClientSessionState. It is likely
that if the server is sending a different set of SCTs there is probably
a reason for doing so, such as a log being retired, or SCT validation
requirements changing, so it makes sense to defer to the server in
that case.

Fixes #39075

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