commit 2cfbef438049fd4c3f73d1562773ad1f93900897 [browse]
Author: Dmitri Goutnik
Date: 2022-05-20 08:07:03 -05:00

cmd/cgo: recognize clang 14 DWARF type names

Fixes #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>

commit c7ccabf3fea67f002bef190a5ffc7417f4371a23 [browse]
Author: Michael Pratt
Date: 2022-06-03 16:22:58 -04:00

runtime/cgo: retry _beginthread on EACCES

We occassionally see _beginthread failing with EACCES, meaning
"insufficient resources" according to the Microsoft documentation.
Exactly which resources is unclear.

Similar to pthread_create on unix systems, we can wait a bit and retry
to try to get success. The alternative is to abort, so we may as well
give it a try.

Fixes #52572.

Change-Id: I6e05add53b4ae36c61e53b1ee3fed6bc74e17dfa
Reviewed-on: https://go-review.googlesource.com/c/go/+/410355
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>

commit 91019cc13d9de72d5e43a0068311dc9e6012777a [browse]
Author: Michael Pratt
Date: 2022-06-03 16:03:55 -04:00

runtime/cgo: merge bodies of cgo_sys_thread_start on windows

The bodies of cgo_sys_thread_start (and x_cgo_sys_thread_create) are
nearly identical on all of the windows ports.

Create a single _cgo_beginthread implementation that contains the body
and is used on all ports. This will reduce churn in an upcoming CL to
add retry logic.

We could theoretically have a single implementation of
_cgo_sys_thread_start shared by all ports, but I keep them separate for
ease of searching. Right now every single port implements this function
in their gcc_GOOS_GOARCH.c file, so it is nice to keep this symmetry.

_cgo_dummy_export must move out of libcgo_windows.h because it is a
definition and the inclusion of libcgo_windows.h in multiple files
creates duplicate definitions.

For #52572.

Change-Id: I9fa22009389349c754210274c7db2631b061f9c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/410354
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>

commit 840e99ed742e55ddd00a57210a706e14234c8bc5 [browse]
Author: Cherry Mui
Date: 2022-06-09 10:59:05 -04:00

api: promote next to go1.19

Change-Id: I3d80f0691b399fe4ee4a0d161b5cee907ae6b94f
Reviewed-on: https://go-review.googlesource.com/c/go/+/411394
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>

commit 1a2ca95ad2d0e6599ab8b9772c30afbb743abc89 [browse]
Author: Robert Findley
Date: 2022-06-04 17:01:47 -04:00

go/types, types2: only set instance context if packages match

In CL 404885, we avoid infinite expansion of type instances by sharing a
context between the expanding type and new instances created during
expansion. This ensures that we do not create an infinite number of
identical but distinct instances in the presence of reference cycles.
This pins additional memory to the new instance, but no more
(approximately) than would be pinned by the original expanding instance.

However, we can do better: since type cycles are only possible within a
single package, we only need to share the local context if the two types
are in the same package. This reduces the scope of the shared local
context, and in particular can avoid pinning the package of the
expanding type to the package of the newly created instance.

Updates #52728

Change-Id: Iad2c85f4ecf60125f1da0ba22a7fdec7423e0338
Reviewed-on: https://go-review.googlesource.com/c/go/+/410416
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>