commit f296b7a6f045325a230f77e9bda1470b1270f817 [browse]
Author: Andrew Bonventre
Date: 2020-05-14 14:05:45 -04:00

[release-branch.go1.14] go1.14.3

Change-Id: I8bd94ad129f0f229a7994ea7dd5a4309821dac4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/234000
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

commit 14c92c5f8032bcc45761e6f1759fa140dc131f76 [browse]
Author: Gregory Petrosyan
Date: 2020-04-04 15:27:23 Z

[release-branch.go1.14] go/doc: fix detection of whole file examples

After CL 211357 (commit 499dc1c),
hasTests and numDecl were not updated properly for function
declarations with parameters, which affected the whole file
example detection logic. This caused examples like

	package foo_test

	func Foo(x int) {
	}

	func Example() {
		fmt.Println("Hello, world!")
		// Output: Hello, world!
	}

to not be detected as whole file ones.

Fixes #38418.
For #38409.

Change-Id: I9ebd47e52d7ee9d91eb6f8e0257511de69b2a402
GitHub-Last-Rev: cc71c31124f6e3514f4e33ac7b169eca74c8bcb7
GitHub-Pull-Request: golang/go#37730
Reviewed-on: https://go-review.googlesource.com/c/go/+/222477
Reviewed-by: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit c4961dc247ca39c251a5a3c80ebfe59609b4e669)
Reviewed-on: https://go-review.googlesource.com/c/go/+/232868
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Gregory Petrosyan <gregory.petrosyan@gmail.com>

commit f4274e64aac99aaa9af05988f2f8c36c47554889 [browse]
Author: Matthew Dempsky
Date: 2020-03-27 14:33:54 -07:00

[release-branch.go1.14] cmd/compile: fix constant conversion involving complex types

In CL 187657, I refactored constant conversion logic without realizing
that conversions between int/float and complex types are allowed for
constants (assuming the constant values are representable by the
destination type), but are never allowed for non-constant expressions.

This CL expands convertop to take an extra srcConstant parameter to
indicate whether the source expression is a constant; and if so, to
allow any numeric-to-numeric conversion. (Conversions of values that
cannot be represented in the destination type are rejected by
evconst.)

Fixes #38123.
For #38117.

Change-Id: Id7077d749a14c8fd910be38da170fa5254819f2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/226197
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
(cherry picked from commit 34314280e46da1558bc7f9cd7e8a9ed610cf417b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/232719
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

commit b7eca1cf3e27ab0796dd8766bf8cc08b14b3cc0d [browse]
Author: Michael Anthony Knyszek
Date: 2020-04-24 14:46:28 Z

[release-branch.go1.14] runtime: make the scavenger's pacing logic more defensive

This change adds two bits of logic to the scavenger's pacing. Firstly,
it checks to make sure we scavenged at least one physical page, if we
released a non-zero amount of memory. If we try to release less than one
physical page, most systems will release the whole page, which could
lead to memory corruption down the road, and this is a signal we're in
this situation.

Secondly, the scavenger's pacing logic now checks to see if the time a
scavenging operation takes is measured to be exactly zero or negative.
The exact zero case can happen if time update granularity is too large
to effectively capture the time the scavenging operation took, like on
Windows where the OS timer frequency is generally 1ms. The negative case
should not happen, but we're being defensive (against kernel bugs, bugs
in the runtime, etc.). If either of these cases happen, we fall back to
Go 1.13 behavior: assume the scavenge operation took around 10µs per
physical page. We ignore huge pages in this case because we're in
unknown territory, so we choose to be conservative about pacing (huge
pages could only increase the rate of scavenging).

Currently, the scavenger is broken on Windows because the granularity of
time measurement is around 1 ms, which is too coarse to measure how fast
we're scavenging, so we often end up with a scavenging time of zero,
followed by NaNs and garbage values in the pacing logic, which usually
leads to the scavenger sleeping forever.

For #38617.
Fixes #38856.

Change-Id: Iaaa2a4cbb21338e1258d010f7362ed58b7db1af7
Reviewed-on: https://go-review.googlesource.com/c/go/+/229997
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit c7915376ce3cdd172bf71ca4127c67f196b8e43e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/232743

commit 6143ce337f246456ce7c9d675dbfe7483e44f8df [browse]
Author: Keith Randall
Date: 2020-04-11 08:51:21 -07:00

[release-branch.go1.14] runtime/race: rebuild netbsd .syso

For #14481
For #37355
For #38321

Change-Id: Idfceaf0e64d340b7304ce9562549a82ebfc27e3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/227867
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(cherry picked from commit 3afa74115b1c458319e5a07fba5bdacc39ef7f88)
Reviewed-on: https://go-review.googlesource.com/c/go/+/232417
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>