commit c0c804730258be3a4841de3a406bcc4d3acf26f6 [browse]
Author: Sergey Matveev
Date: 2024-10-04 13:13:30 +03:00

Autogenerated TLS-related strings

go install golang.org/x/tools/cmd/stringer@latest
cd src/crypto/tls ; go generate

commit 12f981ab3d6479d9bba2221ff3446a24482abd22 [browse]
Author: Sergey Matveev
Date: 2023-02-02 00:19:57 +03:00

GOST X.509 and TLS 1.3 support via GoGOST

commit ed07b321aef7632f956ce991dd10fdd7e1abd827 [browse]
Author: Gopher Robot
Date: 2024-10-01 16:56:29 Z

[release-branch.go1.23] go1.23.2

Change-Id: I904d2e951796dd4142d6e9de4a55af07852bca51
Reviewed-on: https://go-review.googlesource.com/c/go/+/617019
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

commit 3b2e846e11d0c31a556b198f6c700745de5c9780 [browse]
Author: Ian Lance Taylor
Date: 2024-09-06 17:19:34 -07:00

[release-branch.go1.23] runtime: if stop/reset races with running timer, return correct result

The timer code is careful to ensure that if stop/reset is called
while a timer is being run, we cancel the run. However, the code
failed to ensure that in that case stop/reset returned true,
meaning that the timer had been stopped. In the racing case
stop/reset could see that t.when had been set to zero,
and return false, even though the timer had not and never would fire.

Fix this by tracking whether a timer run is in progress,
and using that to reliably detect that the run was cancelled,
meaning that stop/reset should return true.

For #69312
Fixes #69333

Change-Id: I78e870063eb96650638f12c056e32c931417c84a
Reviewed-on: https://go-review.googlesource.com/c/go/+/611496
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 2ebaff4890596ed6064e2dcbbe5e68bc93bed882)
Reviewed-on: https://go-review.googlesource.com/c/go/+/616096
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>

commit fbddfae62f19b5f04555aa593970ac4c6f5a38e5 [browse]
Author: Cuong Manh Le
Date: 2024-09-18 22:39:05 +07:00

[release-branch.go1.23] cmd/compile: fix wrong esacpe analysis for rangefunc

CL 584596 "-range<N>" suffix to the name of closure generated for a
rangefunc loop body. However, this breaks the condition that escape
analysis uses for checking whether a closure contains within function,
which is "F.funcN" for outer function "F" and closure "funcN".

Fixing this by adding new "-rangeN" to the condition.

Updates #69434
Fixes #69511

Change-Id: I411de8f63b69a6514a9e9504d49d62e00ce4115d
Reviewed-on: https://go-review.googlesource.com/c/go/+/614096
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/614195