Alex Brachet [Sat, 3 Dec 2022 18:52:26 +0000 (18:52 +0000)]
[release-branch.go1.18] cmd/cgo: allow DW_TAG_variable's with no name
https://reviews.llvm.org/D123534 is emitting DW_TAG_variable's that don't have a DW_AT_name. This is allowed in the DWARF standard. It is adding DIE's for string literals for better symbolization on buffer overlows etc on these strings. They no associated name because they are not user provided variables.
Fixes #57044
Updates #53000
Change-Id: I2cf063160508687067c7672cef0517bccd707d7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/406816
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
(cherry picked from commit e66f895667cd51d0d28c42d369a803c12db8bb35)
Change-Id: I2cf063160508687067c7672cef0517bccd707d7b
GitHub-Last-Rev: 32208e4fa20272b80cfffd95a4701e1473f47ca9
GitHub-Pull-Request: golang/go#57067
Reviewed-on: https://go-review.googlesource.com/c/go/+/455055 Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Keith Randall [Sat, 10 Dec 2022 03:49:53 +0000 (19:49 -0800)]
[release-branch.go1.18] cmd/compile: fix conditional move rule on PPC64
Similar to CL 456556 but for ppc64 instead of arm64.
Change docs about how booleans are stored in registers for ppc64.
We now don't promise to keep the upper bits zeroed; they might be junk.
To test, I changed the boolean generation instructions (MOVBZload* and ISEL*
with boolean type) to OR in 0x100 to the result. all.bash still passed,
so I think nothing else is depending on the upper bits of booleans.
Update #57211
Change-Id: Ie66f8934a0dafa34d0a8c2a37324868d959a852c
Reviewed-on: https://go-review.googlesource.com/c/go/+/456437
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: KAMPANAT THUMWONG (KONG PC) <1992kongpc.kth@gmail.com>
Run-TryBot: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/456735 Reviewed-by: Than McIntosh <thanm@google.com>
ARM64 maintains booleans in the low byte of registers. Upper parts
of that register are junk.
This rule is using all 32 bits of a boolean-containing register, which
is wrong. Change the rule to only look at the low bit.
Fixes #57211
Change-Id: Ibbef86b2be859df3d06d993db00e1231c481c428
Reviewed-on: https://go-review.googlesource.com/c/go/+/456556
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/456558 Reviewed-by: Than McIntosh <thanm@google.com>
Ian Lance Taylor [Fri, 9 Dec 2022 19:22:32 +0000 (11:22 -0800)]
[release-branch.go1.18] os: skip size test in TestLstat if the file is a symlink
Tested by temporarily changing sysdir to use a directory where
the expected files were all symlinks. We should consider using
a different approach that doesn't rely on sysdir, but for now
do a minimal fix.
For #57210
Fixes #57213
Change-Id: Ifb1becef03e014ceb48290ce13527b3e103c0e07
Reviewed-on: https://go-review.googlesource.com/c/go/+/456557 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 9b8750f53ed89fb326e4d811524e647683136bac)
Reviewed-on: https://go-review.googlesource.com/c/go/+/456561 Reviewed-by: Austin Clements <austin@google.com>
If a compatible trampoline has been inserted by a previously laid
function in the same section, and is known to be sufficiently close,
it can be reused.
When testing if the trampoline can be reused, the addend of the direct
call should be ignored. It is already encoded in the trampoline. If the
addend is non-zero, and the target sufficiently far away, and just
beyond direct call reach, this may cause the trampoline to be
incorrectly reused.
This was observed on go1.17.13 and openshift-installer commit f3c53b382
building in release mode with the following error:
github.com/aliyun/alibaba-cloud-sdk-go/services/cms.(*Client).DescribeMonitoringAgentAccessKeyWithChan.func1: direct call too far: runtime.duffzero+1f0-tramp0-1 -2000078
Fixes #56833
Change-Id: I54af957302506d4e3cd5d3121542c83fe980e912
Reviewed-on: https://go-review.googlesource.com/c/go/+/451415 Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/451916 Reviewed-by: Joedian Reid <joedian@golang.org>
This was a regression test added for a 'git' command line
used for build stamping. Unfortunately, 'gpg' has proved to
be extremely fragile:
* In recent versions, it appears to always require 'gpg-agent' to be
installed for anything involving secret keys, but for some reason is
not normally marked as requiring gpg-agent in Debian's package
manager.
* It tries to create a Unix domain socket in a subdirectory of $TMPDIR
without checking the path length, which fails when $TMPDIR is too
long to fit in the 'sun_path' field of a sockaddr_un struct (which
typically tops out somewhere between 92 and 108 bytes).
We could theoretically address those by artificially reducing the
script's TMPDIR length and checking for gpg-agent in addition to gpg,
but arguably those should both be fixed upstream instead. On balance,
the incremental value that this test provides does not seem worth the
complexity of dealing with such a fragile third-party tool.
Damien Neil [Wed, 30 Nov 2022 18:57:33 +0000 (13:57 -0500)]
[release-branch.go1.18] net: reenable SRV tests with _ldap._tcp.google.com
TestLookupDotsWithRemoteSource and TestLookupGoogleSRV
were disabled because they look up the no-longer-present
SRV record for _xmpp-server._tcp.google.com.
Change the tests to look for _ldap._tcp.google.com and
reenable them.
For #56708.
Fixes #56711.
Change-Id: I26475fa3ff6fc008048a4e5f24f0e96ee12f655c
Reviewed-on: https://go-review.googlesource.com/c/go/+/453861
Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit cb42bbddeb80ff08599079ee6b94088e5be88e5b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454295
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Jenny Rakoczy <jenny@golang.org>
The gopkg.in service has had a lot of flakiness lately. Go users in
general are isolated from that flakiness by the Go module mirror
(proxy.golang.org), but this test intentionally bypasses the module
mirror because the mirror itself uses cmd/go to download the module.
In the long term, we can redirect the gopkg.in URL to the local
(in-process) vcweb server added for #27494.
In the meantime, let's skip the test to reduce the impact of upstream
outages.
Damien Neil [Thu, 10 Nov 2022 20:16:27 +0000 (12:16 -0800)]
[release-branch.go1.18] os, net/http: avoid escapes from os.DirFS and http.Dir on Windows
Do not permit access to Windows reserved device names (NUL, COM1, etc.)
via os.DirFS and http.Dir filesystems.
Avoid escapes from os.DirFS(`\`) on Windows. DirFS would join the
the root to the relative path with a path separator, making
os.DirFS(`\`).Open(`/foo/bar`) open the path `\\foo\bar`, which is
a UNC name. Not only does this not open the intended file, but permits
reference to any file on the system rather than only files on the
current drive.
Make os.DirFS("") invalid, with all file access failing. Previously,
a root of "" was interpreted as "/", which is surprising and probably
unintentional.
Dmitri Goutnik [Fri, 20 May 2022 13:07:03 +0000 (08:07 -0500)]
[release-branch.go1.18] cmd/cgo: recognize clang 14 DWARF type names
Fixes #57028
Updates #53013
Change-Id: I169d4eb2420a6da52cc9abe17da98c3092a91be6
Reviewed-on: https://go-review.googlesource.com/c/go/+/407514
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 2cfbef438049fd4c3f73d1562773ad1f93900897)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454415 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Cherry Mui [Wed, 9 Nov 2022 15:55:54 +0000 (10:55 -0500)]
[release-branch.go1.18] runtime: make GC see object as allocated after it is initialized
When the GC is scanning some memory (possibly conservatively),
finding a pointer, while concurrently another goroutine is
allocating an object at the same address as the found pointer, the
GC may see the pointer before the object and/or the heap bits are
initialized. This may cause the GC to see bad pointers and
possibly crash.
To prevent this, we make it that the scanner can only see the
object as allocated after the object and the heap bits are
initialized. Currently the allocator uses freeindex to find the
next available slot, and that code is coupled with updating the
free index to a new slot past it. The scanner also uses the
freeindex to determine if an object is allocated. This is somewhat
racy. This CL makes the scanner use a different field, which is
only updated after the object initialization (and a memory
barrier).
Updates #54596.
Fixes #56751.
Change-Id: I2a57a226369926e7192c253dd0d21d3faf22297c
Reviewed-on: https://go-review.googlesource.com/c/go/+/449017 Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit febe7b8e2a4dd7cce6ab8d02cf79a5430819cbe5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/453255
Cherry Mui [Fri, 30 Sep 2022 23:01:09 +0000 (19:01 -0400)]
[release-branch.go1.18] runtime: don't jump stack if at entry of systemstack
The traceback code has special "jump stack" logic, to trace back
stack switches through systemstack. If we're at the entry of
systemstack, the stack switch hasn't happened, so don't jump to
user stack.
The jump stack logic is only used if we're on the g0 stack. It can
happen that we're at the entry of a recursive systemstack call on
the g0 stack. In we jump stack here, there will be two problems:
1. There are frames between entering the g0 stack and this
recursive systemstack call. Those frames will be lost.
2. Worse, we switched frame.sp but frame.fp calculation will use
the entry SP delta (0), which will be wrong, which in turn
leads wrong frame.lr and things will go off.
For now, don't jump stack if we're at entry of systemstack (SP
delta is 0).
Using a per-PC SPWRITE marker may be a better fix. If we haven't
written the SP, we haven't switched the stack so we can just
unwind like a normal function.
Updates #55851.
Fixes #56635.
Change-Id: I2b624c8c086b235b34d9c7d3cebd4a37264f00f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/437299
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit 500bc6b8056ee2eaf7640610a48ffa00bdd896a5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/448517
Matthew Dempsky [Thu, 3 Nov 2022 18:56:43 +0000 (11:56 -0700)]
[release-branch.go1.18] cmd/compile: allow ineffectual //go:linkname in -lang=go1.17 and older
Prior to Go 1.18, ineffectual //go:linkname directives (i.e.,
directives referring to an undeclared name, or to a declared type or
constant) were treated as noops. In Go 1.18, we changed this into a
compiler error to mitigate accidental misuse.
However, the x/sys repo contained ineffectual //go:linkname directives
up until go.dev/cl/274573, which has caused a lot of user confusion.
It seems a bit late to worry about now, but to at least prevent
further user pain, this CL changes the error message to only apply to
modules using "go 1.18" or newer. (The x/sys repo declared "go 1.12"
at the time go.dev/cl/274573 was submitted.)
Matthew Dempsky [Thu, 3 Nov 2022 18:02:51 +0000 (11:02 -0700)]
[release-branch.go1.18] os/exec: allow NUL in environment variables on Plan 9
Plan 9 uses NUL as os.PathListSeparator, so it's almost always going
to appear in the environment variable list. Exempt GOOS=plan9 from the
check for NUL in environment variables.
For #56284.
For #56544.
Fixes #56550.
Change-Id: I23df233cdf20c0a9a606fd9253e15a9b5482575a
Reviewed-on: https://go-review.googlesource.com/c/go/+/447715 Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/447875
Run-TryBot: David du Colombier <0intro@gmail.com>
Cherry Mui [Fri, 14 Oct 2022 23:52:00 +0000 (19:52 -0400)]
[release-branch.go1.18] cmd/compile: copy blank parameter node when substituting function type
When a function type is copied (e.g. for substituting type
parameters), we make copies of its parameter ir.Name nodes, so
they are not shared with the old function type. But currently a
blank (_) identifier is not copied but shared. The parameter
node's frame offset is assigned (in ABI analysis) and then used in
the concurrent backend. Shared node can cause a data race. Make a
new blank parameter node to avoid sharing. (Unified IR does already
not have this problem. This fixes non-unified-IR mode.)
Updates #55357.
Fixes #56359.
Change-Id: Ie27f08e5589ac7d5d3f0d0d5de1a21e4fd2765c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/443158 Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com>
(cherry picked from commit 4725c71b735143a138b24f2b0e055c717d8d69ca)
Reviewed-on: https://go-review.googlesource.com/c/go/+/445177
Paul E. Murphy [Thu, 20 Oct 2022 22:01:01 +0000 (17:01 -0500)]
[release-branch.go1.18] runtime: fix usleep on linux/PPC64
The existing implementation fails to convert the remainder
microseconds to nanoseconds. This causes sysmon to consume
much more cpu, and generate lots of context switches.
We can also do a little better here to avoid division by a
constant. I used go to determine the magic numbers.
Check for and reject environment variables containing NULs.
The conventions for passing environment variables to subprocesses
cause most or all systems to interpret a NUL as a separator. The
syscall package rejects environment variables containing a NUL
on most systems, but erroneously did not do so on Windows. This
causes an environment variable such as "FOO=a\x00BAR=b" to be
interpreted as "FOO=a", "BAR=b".
Check for and reject NULs in environment variables passed to
syscall.StartProcess on Windows.
Add a redundant check to os/exec as extra insurance.
Michael Pratt [Tue, 18 Oct 2022 16:01:18 +0000 (12:01 -0400)]
[release-branch.go1.18] runtime: always keep global reference to mp until mexit completes
Ms are allocated via standard heap allocation (`new(m)`), which means we
must keep them alive (i.e., reachable by the GC) until we are completely
done using them.
Ms are primarily reachable through runtime.allm. However, runtime.mexit
drops the M from allm fairly early, long before it is done using the M
structure. If that was the last reference to the M, it is now at risk of
being freed by the GC and used for some other allocation, leading to
memory corruption.
Ms with a Go-allocated stack coincidentally already keep a reference to
the M in sched.freem, so that the stack can be freed lazily. This
reference has the side effect of keeping this Ms reachable. However, Ms
with an OS stack skip this and are at risk of corruption.
Fix this lifetime by extending sched.freem use to all Ms, with the value
of mp.freeWait determining whether the stack needs to be freed or not.
For #56243.
Fixes #56308.
Change-Id: Ic0c01684775f5646970df507111c9abaac0ba52e
Reviewed-on: https://go-review.googlesource.com/c/go/+/443716
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit e252dcf9d38ce9192bccacb7e33867cbfbd22b6c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/443816 Reviewed-by: Austin Clements <austin@google.com>
Query parameter smuggling occurs when a proxy's interpretation
of query parameters differs from that of a downstream server.
Change ReverseProxy to avoid forwarding ignored query parameters.
Remove unparsable query parameters from the outbound request
* if req.Form != nil after calling ReverseProxy.Director; and
* before calling ReverseProxy.Rewrite.
This change preserves the existing behavior of forwarding the
raw query untouched if a Director hook does not parse the query
by calling Request.ParseForm (possibly indirectly).
Fixes #55842
For #54663
For CVE-2022-2880
Change-Id: If1621f6b0e73a49d79059dae9e6b256e0ff18ca9
Reviewed-on: https://go-review.googlesource.com/c/go/+/432976 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
(cherry picked from commit 7c84234142149bd24a4096c6cab691d3593f3431)
Reviewed-on: https://go-review.googlesource.com/c/go/+/433695 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Cherry Mui [Thu, 15 Sep 2022 01:01:04 +0000 (21:01 -0400)]
[release-branch.go1.18] cmd/link: suppress -no_pie deprecation warning on darwin
Apparently the new darwin linker starts to emit a warning about
-no_pie deprecation. Maybe we want to switch to PIE by default.
For now, suppress the warning. This also makes it easier for
backporting to previous releases.
Fixes #55113.
Updates #55112, #54482.
Change-Id: I1a3b74c237a9d00ec3b030fc3a9940a31e5cd37e
Reviewed-on: https://go-review.googlesource.com/c/go/+/430937
Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 706d84fca2b36fdf670a0d921e6a8a3b481eaa05)
Reviewed-on: https://go-review.googlesource.com/c/go/+/431518 Reviewed-by: Austin Clements <austin@google.com>
Cherry Mui [Wed, 14 Sep 2022 23:50:00 +0000 (19:50 -0400)]
[release-branch.go1.18] cmd/link: stop passing -pagezero_size to darwin linker
We added -pagezero_size in CL 72730, where it was intented for iOS.
The current code passes it only on macOS/AMD64 instead. It is not
really necessary there. Also, the new darwin linker starts to emit
a warning about deprecation of the flag. Stop passing it.
For #55113
Updates #54482, #55112.
Change-Id: If9db7a1645c37d4284e48f075856912df8d8c1a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/430936
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
(cherry picked from commit 5231ba2f054f2ecb1387bad00b8745d6fe532ea4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/431516 Reviewed-by: Austin Clements <austin@google.com>
Robert Griesemer [Mon, 12 Sep 2022 22:51:32 +0000 (15:51 -0700)]
[release-branch.go1.18] go/types, types2: allow (string...) signature with NewSignatureType
Includes cases where the core type of the variadic parameter is
a slice or bytestring. Permits a client to create the signature
for various instantiations of append.
Fixes #55148.
Change-Id: I0f4983eb00c088cbe1d87954ee0b2df0ccc3bc49
Reviewed-on: https://go-review.googlesource.com/c/go/+/430455
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/431915
Keith Randall [Sat, 17 Sep 2022 22:52:35 +0000 (18:52 -0400)]
[release-branch.go1.18] cmd/compile: avoid using destination pointer base type in memmove optimization
The type of the source and destination of a memmove call isn't
always accurate. It will always be a pointer (or an unsafe.Pointer), but
the base type might not be accurate. This comes about because multiple
copies of a pointer with different base types are coalesced into a single value.
In the failing example, the IData selector of the input argument is a
*[32]byte in one branch of the type switch, and a *[]byte in the other branch.
During the expand_calls pass both IDatas become just copies of the input
register. Those copies are deduped and an arbitrary one wins (in this case,
*[]byte is the unfortunate winner).
Generally an op v can rely on v.Type during rewrite rules. But relying
on v.Args[i].Type is discouraged.
Fixes #55151
Change-Id: I348fd9accf2058a87cd191eec01d39cda612f120
Reviewed-on: https://go-review.googlesource.com/c/go/+/431496
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com>
(cherry picked from commit e283473ebbebf4a80db166e7e852d03c5cff1a61)
Reviewed-on: https://go-review.googlesource.com/c/go/+/431918
ir.ClosureExpr implements ir.InitNode, so ir.InitExpr can prepend init
statements to it. However, CalleeEffects wasn't aware of this and
could cause the init statements to get dropped when inlining a call to
a closure.
This isn't an issue today, because we don't create closures with init
statements. But I ran into this within unified IR.
Easy and robust solution: just take advantage that ir.TakeInit can
handle any node.
Fixes #54918.
Change-Id: Ica05fbf6a8c5be4b11927daf84491a1140da5431
Reviewed-on: https://go-review.googlesource.com/c/go/+/422196 Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/429897 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Cherry Mui [Wed, 24 Aug 2022 22:33:21 +0000 (18:33 -0400)]
[release-branch.go1.18] runtime: mark morestack_noctxt SPWRITE on LR architectures
On LR architectures, morestack (and morestack_noctxt) are called
with a special calling convention, where the caller doesn't save
LR on stack but passes it as a register, which morestack will save
to g.sched.lr. The stack unwinder currently doesn't understand it,
and would fail to unwind from it. morestack already writes SP (as
it switches stack), but morestack_noctxt (which tailcalls
morestack) doesn't. If a profiling signal lands right in
morestack_noctxt, the unwinder will try to unwind the stack and
go off, and possibly crash.
Marking morestack_noctxt SPWRITE stops the unwinding.
Ideally we could teach the unwinder about the special calling
convention, or change the calling convention to be less special
(so the unwinder doesn't need to fetch a register from the signal
context). This is a stop-gap solution, to stop the unwinder from
crashing.
Updates #54332.
Fixes #54674.
Change-Id: I75295f2e27ddcf05f1ea0b541aedcb9000ae7576
Reviewed-on: https://go-review.googlesource.com/c/go/+/425396
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit e4be2ac79f3cc7219ae1cf8334463d11cae24e01)
Reviewed-on: https://go-review.googlesource.com/c/go/+/425616
Cuong Manh Le [Mon, 29 Aug 2022 03:48:28 +0000 (10:48 +0700)]
[release-branch.go1.18] cmd/compile: only inline method wrapper if method don't contain closures
CL 327871 changes methodWrapper to always perform inlining after global
escape analysis. However, inlining the method may reveal closures, which
require walking all function bodies to decide whether to capture free
variables by value or by ref.
To fix it, just not doing inline if the method contains any closures.
Bryan C. Mills [Wed, 24 Aug 2022 13:45:18 +0000 (09:45 -0400)]
[release-branch.go1.18] cmd/go: avoid registering AtExit handlers in tests
Ever since 'go build' was added (in CL 5483069), it has used an atexit
handler to clean up working directories.
CL 154109 introduced 'cc' command to the script test framework that
called Init on a builder once per invocation. Unfortunately, since
base.AtExit is unsynchronized, the Init added there caused any script
that invokes that command to be unsafe for concurrent use.
This change fixes the race by having the 'cc' command pass in its
working directory instead of allowing the Builder to allocate one.
Following modern Go best practices, it also replaces the in-place Init
method (which is prone to typestate and aliasing bugs) with a
NewBuilder constructor function.
Normally, when moving Go values of type T from one location to another,
we don't need to worry about partial overlaps. The two Ts must either be
in disjoint (nonoverlapping) memory or in exactly the same location.
There are 2 cases where this isn't true:
1) Using unsafe you can arrange partial overlaps.
2) Since Go 1.17, you can use a cast from a slice to a ptr-to-array.
https://go.dev/ref/spec#Conversions_from_slice_to_array_pointer
This feature can be used to construct partial overlaps of array types.
var a [3]int
p := (*[2]int)(a[:])
q := (*[2]int)(a[1:])
*p = *q
We don't care about solving 1. Or at least, we haven't historically
and no one has complained.
For 2, we need to ensure that if there might be partial overlap,
then we can't use OpMove; we must use memmove instead.
(memmove handles partial overlap by copying in the correct
direction. OpMove does not.)
Note that we have to be careful here not to introduce a call when
we're marshaling arguments to a call or unmarshaling results from a call.
Fixes #54603
Change-Id: I1ca6aba8041576849c1d85f1fa33ae61b80a373d
Reviewed-on: https://go-review.googlesource.com/c/go/+/425076 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
(cherry picked from commit 332a5981d0ae3f21f668f94755f43ecd8ee9a9eb)
Reviewed-on: https://go-review.googlesource.com/c/go/+/425198
Jeremy Quirke [Tue, 9 Aug 2022 17:20:33 +0000 (17:20 +0000)]
[release-branch.go1.18] cmd/link: fix trampolines breaking DWARF line info
When trampolines are needed (e.g. Darwin ARM64), the DWARF LPT (Line
Program Table - see DWARF section 6.1) generation fails because the
replacement symbols are marked as external symbols and skipped during
the DWARF LPT generation phase.
Fixes #54502
Change-Id: I6c93f5378f50e5edf30d5121402a48214abb1ce2
GitHub-Last-Rev: 085bbc55dbc95d55456cc2acc46a0d02416c2848
GitHub-Pull-Request: golang/go#54321
Reviewed-on: https://go-review.googlesource.com/c/go/+/422154 Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 2340d371796f95acdcc399e60f9ecefec2add8df)
Reviewed-on: https://go-review.googlesource.com/c/go/+/424536
Run-TryBot: Cherry Mui <cherryyz@google.com>
Ian Lance Taylor [Fri, 19 Aug 2022 21:43:47 +0000 (14:43 -0700)]
[release-branch.go1.18] misc/cgo/testcarchive: permit SIGQUIT for TestSignalForwardingExternal
Occasionally the signal will be sent to a Go thread, which will cause
the program to exit with SIGQUIT rather than SIGSEGV.
Add TestSignalForwardingGo to test the case where the signal is
expected to be delivered to a Go thread.
This is a roll forward of CL 419014 which was rolled back in CL 424954.
This CL differs from 419014 in that it skips TestSignalForwardingGo
on darwin-amd64.
For #53907
Fixes #54056
Change-Id: I5df3fd610c068df3bd48d9b3d7a9379248b97999
Reviewed-on: https://go-review.googlesource.com/c/go/+/425002
Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
(cherry picked from commit d05ce23756573c6dc2c5026d936f2ef6ac140ee2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/425486 Reviewed-by: David Chase <drchase@google.com>
Cherry Mui [Mon, 9 May 2022 16:57:31 +0000 (12:57 -0400)]
[release-branch.go1.18] cmd/compile: more fix on boolean ops on ARM64
Following CL 421457, the extension rule is also wrong. It is safe
to drop the extension if the value is from a boolean-generating
instruction, but not a boolean-typed Value in general (e.g. a Phi
or a in-register parameter). Fix it.
Updates #52788.
Updates #53397.
Change-Id: Icf3028fe8e90806f9f57fbe2b38d47da27a97e2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/405115 Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/421458 Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Cherry Mui [Mon, 9 May 2022 15:29:36 +0000 (11:29 -0400)]
[release-branch.go1.18] cmd/compile: fix If lowering on ARM64
On ARM64, an If block is lowered to (NZ cond yes no). This is
incorrect because cond is a boolean value and therefore only the
last byte is meaningful (same as AMD64, see ARM64Ops.go). But here
we are comparing a full register width with 0. Correct it by
comparing only the last bit.
For #52788.
Fixes #53397.
Change-Id: I2cacf9f3d2f45e149c361a290f511b2d4ed845c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/405114
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/421457 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Roland Shoemaker [Thu, 14 Jul 2022 19:09:19 +0000 (12:09 -0700)]
[release-branch.go1.18] encoding/xml: skip TestCVE202230633 for short tests
TestCVE202230633 uses a bunch of memory, and the input cannot be
feasibly reduced while maintaining the behavior hasn't regressed. This
test could be reasonably removed, but I'd rather keep it around if we
can.
Updates #53814.
Fixes #54128.
Change-Id: Ie8b3f306efd20b2d9c0fb73122c26351a55694c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/417655
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
(cherry picked from commit 783ff7dfc49d207114bb80e565e50ea6ff079326)
Reviewed-on: https://go-review.googlesource.com/c/go/+/421094 Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Bryan C. Mills [Fri, 27 May 2022 19:54:44 +0000 (15:54 -0400)]
[release-branch.go1.18] cmd/go: omit build metadata that may contain system paths when -trimpath is set
CGO flag variables often include system paths for header files and
compiled libraries. The point of -trimpath is to avoid dependending on
system paths, so stamping these variables is counterproductive.
Moreover, the point of stamping build information is to improve
reproducibility. Since we don't also stamp the versions of C
compilers, headers, and libraries used in a cgo build, only the most
trivial cgo programs can be faithfully reproduced from the stamped
information.
Likewise, the -ldflags flag may include system-specific paths,
particularly if external linking is in use. For now, we omit -ldflags
entirely; however, in the future we may instead want to parse and
redact the individual flags.
Updates #52372.
Fixes #53119.
Change-Id: I73318a01cce4371d66955b3261fc7ee58d4b33dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/409174
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
(cherry picked from commit a6e5be0d30770e8bd1ba1e4bac2089218df121d9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/414794 Reviewed-by: Nooras Saba <saba@golang.org>
Michael Pratt [Wed, 13 Jul 2022 15:48:04 +0000 (11:48 -0400)]
[release-branch.go1.18] runtime: clear timerModifiedEarliest when last timer is deleted
timerModifiedEarliest contains the lowest possible expiration for a
modified earlier timer, which may be earlier than timer0When because we
haven't yet updated the heap. Note "may", as the modified earlier timer
that set timerModifiedEarliest may have since been modified later or
deleted.
We can clear timerModifiedEarliest when the last timer is deleted
because by definition there must not be any modified earlier timers.
Why does this matter? checkTimersNoP claims that there is work to do if
timerModifiedEarliest has passed, causing findRunnable to loop back
around to checkTimers. But the code to clean up timerModifiedEarliest in
checkTimers (i.e., the call to adjusttimers) is conditional behind a
check that len(pp.timers) > 0.
Without clearing timerModifiedEarliest, a spinning M that would
otherwise go to sleep will busy loop in findRunnable until some other
work is available.
Note that changing the condition on the call to adjusttimers would also
be a valid fix. I took this approach because it feels a bit cleaner to
clean up timerModifiedEarliest as soon as it is known to be irrelevant.
For #51654.
Fixes #53847.
Change-Id: I3f3787c67781cac7ce87939c5706cef8db927dd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/417434
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
(cherry picked from commit c006b7ac2765252f397dec40fef610a3c17d956d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/417475
Cherry Mui [Fri, 15 Apr 2022 16:23:06 +0000 (12:23 -0400)]
[release-branch.go1.18] runtime: use saved LR when unwinding through morestack
On LR machine, consider F calling G calling H, which grows stack.
The stack looks like
...
G's frame:
... locals ...
saved LR = return PC in F <- SP points here at morestack
H's frame (to be created)
At morestack, we save
gp.sched.pc = H's morestack call
gp.sched.sp = H's entry SP (the arrow above)
gp.sched.lr = return PC in G
Currently, when unwinding through morestack (if _TraceJumpStack
is set), we switch PC and SP but not LR. We then have
frame.pc = H's morestack call
frame.sp = H's entry SP (the arrow above)
As LR is not set, we load it from stack at *sp, so
frame.lr = return PC in F
As the SP hasn't decremented at the morestack call,
frame.fp = frame.sp = H's entry SP
Unwinding a frame, we have
frame.pc = old frame.lr = return PC in F
frame.sp = old frame.fp = H's entry SP a.k.a. G's SP
The PC and SP don't match. The unwinding will go off if F and G
have different frame sizes.
Fix this by preserving the LR when switching stack.
Also add code to detect infinite loop in unwinding.
TODO: add some test. I can reproduce the infinite loop (or throw
with added check) but the frequency is low.
Limit nested parsing to 100,000, which prevents stack exhaustion when
parsing deeply nested statements, types, and expressions. Also limit
the scope depth to 1,000 during object resolution.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Paul E. Murphy [Mon, 3 May 2021 16:00:54 +0000 (11:00 -0500)]
[release-branch.go1.18] cmd/link: use TOC-relative trampolines on PPC64 when needed
When linking a PIE binary with the internal linker, TOC relative
relocations need to be generated. Update trampolines to indirect
call using R12 to more closely match the AIX/ELFv2 regardless of
buildmode, and work with position-indepdent code.
Likewise, update the check for offseting R_CALLPOWER relocs to
make a local call. It should be checking ldr.AttrExternal, not
ldr.IsExternal. This offset should not be adjusted for external
(non-go) object files, it is handled when ELF reloc are translated
into go relocs.
And, update trampoline tests to verify these are generated correctly
and produce a working binary using -buildmode=pie on ppc64le.
Fixes #53107
Change-Id: I8a2dea06c3237bdf0e87888b56a17b6c4c99a7de
Reviewed-on: https://go-review.googlesource.com/c/go/+/400234 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/409075
Run-TryBot: Cherry Mui <cherryyz@google.com>
Michael Pratt [Tue, 28 Jun 2022 20:32:50 +0000 (16:32 -0400)]
[release-branch.go1.18] runtime: add race annotations to cbs.lock
cbs.lock protects a map. The map implementation is race instrumented
regardless of which package is it called from.
lock/unlock are not automatically race instrumented, so we can trigger
race false positives without manually annotating our lock acquire and
release.
compileCallback is used during initialization before the P is available,
at which point raceacquire will crash during a racecallback to get the
race proc. Thus we skip instrumentation until scheduler initialization
is complete.
Fixes #53613.
For #50249.
Change-Id: Ie49227c9e9210ffbf0aee65f86f2b7b6a2f64638
Reviewed-on: https://go-review.googlesource.com/c/go/+/414518
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
(cherry picked from commit 20760cff001e9acc05627dfeab42ea50b57920e6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/415198
Run-TryBot: Heschi Kreinick <heschi@google.com>
Michael Pratt [Tue, 28 Jun 2022 19:17:12 +0000 (15:17 -0400)]
[release-branch.go1.18] runtime: add race annotations to metricsSema
metricsSema protects the metrics map. The map implementation is race
instrumented regardless of which package is it called from.
semacquire/semrelease are not automatically race instrumented, so we can
trigger race false positives without manually annotating our lock
acquire and release.
See similar instrumentation on trace.shutdownSema and reflectOffs.lock.
Fixes #53590.
For #53542.
Change-Id: Ia3fd239ac860e037d09c7cb9c4ad267391e70705
Reviewed-on: https://go-review.googlesource.com/c/go/+/414517
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit d6481d5b9662b29453004204746945a93a6b4eb2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/415195
Keith Randall [Tue, 21 Jun 2022 00:06:09 +0000 (17:06 -0700)]
[release-branch.go1.18] cmd/compile: allow 128-bit values to be spilled
We sometimes use 16-byte load+store to move values around in memory.
In rare circumstances, the loaded value must be spilled because the
store can't happen yet.
In that case, we need to be able to spill the 16-byte value.
Fixes #53471
Change-Id: I09fd08e11a63c6ba3ef781d3f5ede237e9b0132e
Reviewed-on: https://go-review.googlesource.com/c/go/+/413294 Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
(cherry picked from commit c2d373d5d1802d7479f3c81dcf01d41bef3646dd)
Reviewed-on: https://go-review.googlesource.com/c/go/+/413455 Reviewed-by: Alex Rakoczy <jenny@golang.org>
Cuong Manh Le [Mon, 30 May 2022 14:34:01 +0000 (21:34 +0700)]
[release-branch.go1.18] cmd/compile: fix wrong unsafe.Offsetof evaluation inside generic function
For instantiated generic functions, all implicit dot operations are
resolved. Thus unsafe.Offsetof may calculating the offset against the
wrong base selector.
To fix it, we must remove any implicit dot operations to find the first
non-implicit one, which is the right base selector for calculating the
offset.
Fixes #53159
Change-Id: I38504067ce0f274615b306edc8f7d7933bdb631a
Reviewed-on: https://go-review.googlesource.com/c/go/+/409355
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/409494
Michael Anthony Knyszek [Thu, 9 Jun 2022 18:25:01 +0000 (18:25 +0000)]
[release-branch.go1.18] runtime: store consistent total allocation stats as uint64
Currently the consistent total allocation stats are managed as uintptrs,
which means they can easily overflow on 32-bit systems. Fix this by
storing these stats as uint64s. This will cause some minor performance
degradation on 32-bit systems, but there really isn't a way around this,
and it affects the correctness of the metrics we export.
For #52680.
Fixes #52689.
Change-Id: I8b1926116e899ae9f03d58e0320bcb9264945b3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/411495
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
[release-branch.go1.18] path/filepath: do not remove prefix "." when following path contains ":".
For #52476
Fixes #52479
Fixes CVE-2022-29804
Change-Id: I9eb72ac7dbccd6322d060291f31831dc389eb9bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/401595
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/405234 Reviewed-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
David Taylor [Mon, 17 Jan 2022 21:54:17 +0000 (21:54 +0000)]
[release-branch.go1.18] crypto/tls: avoid extra allocations in steady-state Handshake calls
The Read and Write methods of *tls.Conn call Handshake
unconditionally, every time they are called, expecting it to only
perform a new handshake if required.
However in go 1.17 handshakeContext was extended to set up a
cancelable Context, and importantly did so prior to checking if a
handshake is required. This thus causes it to allocate on every call,
even in those that are no-ops when called in a Read or Write on an
established connection, sometimes leading to very large numbers of
allocations during reads.
This change adds an early return, prior to setting up the context or
proceeding into the handshakeMutex and checking the handshake error, if
the handshake status atomic indicates handshake is already complete.
As required by RFC 8446, section 4.6.1, ticket_age_add now holds a
random 32-bit value. Before this change, this value was always set
to 0.
This change also documents the reasoning for always setting
ticket_nonce to 0. The value ticket_nonce must be unique per
connection, but we only ever send one ticket per connection.
Russ Cox [Tue, 3 May 2022 19:14:56 +0000 (15:14 -0400)]
[release-branch.go1.18] os/exec: return clear error for missing cmd.Path
Following up on CL 403694, there is a bit of confusion about
when Path is and isn't set, along with now the exported Err field.
Catch the case where Path and Err (and lookPathErr) are all unset
and give a helpful error.
Updates #52574
Followup after #43724.
Fixes #53057
Fixes CVE-2022-30580
Change-Id: I03205172aef3801c3194f5098bdb93290c02b1b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/403759 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
(cherry picked from commit 960ffa98ce73ef2c2060c84c7ac28d37a83f345e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/408577
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Rob Pike [Mon, 14 Mar 2022 23:21:08 +0000 (10:21 +1100)]
[release-branch.go1.18] text/template/parse: allow space after continue or break
Trivial fix: We must skip space after either of these keywords
before we expect a closing delimiter.
Also delete the stutter-generating extra 'in' in the error message.
(See what I did there?)
For #51670
Fixes #52878
Change-Id: If5415632c36eaac6699bdc0aa6ce18be956c9b53
Reviewed-on: https://go-review.googlesource.com/c/go/+/392615 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 41a82aa9c36bffab2593d50aa55a462fef4e5bd4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/406074 Reviewed-by: Alex Rakoczy <alex@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Matthew Dempsky [Tue, 3 May 2022 00:36:04 +0000 (17:36 -0700)]
[release-branch.go1.18] cmd/compile: backport fix for #51840
This CL is a manual backport of CLs 403837 and 404914 to Go 1.18.
CL 403837 was intended just as a simplification CL, but evidently it
also fixed #51840. However, for backporting to Go 1.18, the existing
logic needs to be preserved to support -G=0 mode (which still relies
on Ntype).
Fixes #51849.
Change-Id: Ib060b0bc67ecf26de8a65d5b4d2f8a65cd547517
Reviewed-on: https://go-review.googlesource.com/c/go/+/405436
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Noder pass will build a closure to implement generic function
instantiation which may produce `.dict` and `.rcvr` ident.
Since we allow `.dict` during exporting, we should allow `.rcvr` too.
Fixes #52242.
Change-Id: Ifc3912ba5155b5ac1887f20830da64f4fb3fceb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/404314
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit ac39dbdf58e50a2575b891675e7d2e1400b20cfe)
Reviewed-on: https://go-review.googlesource.com/c/go/+/404774 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Roland Shoemaker [Tue, 26 Apr 2022 02:02:35 +0000 (19:02 -0700)]
[release-branch.go1.18] [release-branch.go1.18 crypto/rand: properly handle large Read on windows
Use the batched reader to chunk large Read calls on windows to a max of
1 << 31 - 1 bytes. This prevents an infinite loop when trying to read
more than 1 << 32 -1 bytes, due to how RtlGenRandom works.
This change moves the batched function from rand_unix.go to rand.go,
since it is now needed for both windows and unix implementations.
Cherry Mui [Tue, 24 May 2022 00:20:07 +0000 (20:20 -0400)]
[release-branch.go1.18] misc/cgo/testsanitizers: use buffered channel in tsan12.go
os/signal.Notify requires that "the caller must ensure that c has
sufficient buffer space to keep up with the expected signal rate"
as it does a nonblocking send when it receives a signal. The test
currently using a unbuffered channel, which means it may miss the
signal if the signal arrives before the channel receive operation.
Fixes #53043.
Updates #52998.
Change-Id: Icdcab9396d735506480ef880fb45a4669fa7cc8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/407888 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 62e130226767a088ace196da90a774c9a9d14689)
Reviewed-on: https://go-review.googlesource.com/c/go/+/408114
Robert Findley [Wed, 4 May 2022 21:41:39 +0000 (17:41 -0400)]
[release-branch.go1.18] go/types, types2: use a type lookup by identity in method lookup
Named type identity is no longer canonical. For correctness, named types
need to be compared with types.Identical. Our method set algorithm was
not doing this: it was using a map to de-duplicate named types, relying
on their pointer identity. As a result it was possible to get incorrect
results or even infinite recursion, as encountered in #52715.
To fix this, look up types by identity in NewMethodSet and
LookupFieldOrMethod. This does a linear search among types with equal
origin. Alternatively we could use a *Context to do a hash lookup, but
in practice we will be considering a small number of types, and so
performance is not a concern and a linear lookup is simpler. This also
means we don't have to rely on our type hash being perfect, which we
don't depend on elsewhere.
Also add more tests for NewMethodSet and LookupFieldOrMethod involving
generics.
Fixes #52804
Change-Id: I04dfeff54347bc3544d95a30224c640ef448e9b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/404099
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
(cherry picked from commit f088f4962e628992833444df7486d392715ea73d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/405117 Reviewed-by: Alan Donovan <adonovan@google.com>