crypto/internal/cryptotest: add SkipTestAllocations

[                                                                     ]
[    It has been [ 0 ] days since Filippo broke a TestAllocations.    ]
[                                                                     ]

Concentrate all the skips in one place, so we don't have to re-discover
always the same ones via trial and error.

This might over-skip fixable allocations, but all these targets are not
fast anyway, so they are not worth going back for.

Removed the sysrand TestAllocations because it causes an import loop
with cryptotest and it's covered by TestAllocations in crypto/rand.

Change-Id: Icd40e97f9128e037f567147f8c9dafa758a47fac
Reviewed-on: https://go-review.googlesource.com/c/go/+/626438
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>

crypto/internal/fips/drbg: add CAST and service indicator

For #69536

Change-Id: If216a7537013bd9bbe90026ffe983a6bf50029c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/625435
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

crypto/internal/fips/drbg: implement FIPS-mode randomness generation

For #69536

Change-Id: I5bc83360fcd9114cc76314c3570977e9811fd1c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/624978
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>

crypto/internal/fips/drbg: implement CTR_DRBG

For #69536

Change-Id: I016bb723841acbda50f013db46f9d2dda200e1fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/624977
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>

crypto/rand: move OS interaction to crypto/internal/sysrand

We're going to use that package as the passive entropy source for the
FIPS module, and we need to import it from a package that will be
imported by crypto/rand.

Since there is no overridable Reader now, introduced a mechanism to test
the otherwise impossible failure of the OS entropy source.

For #69536

Change-Id: I558687ed1ec896dba05b99b937970bb809de3fe7
Reviewed-on: https://go-review.googlesource.com/c/go/+/624976
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

crypto/rand: replace crypto/aes with internal/chacha8rand for plan9

We will need to import this functionality from the FIPS module, and we
can't import AES from there. Plan 9 is not going to be FIPS validated
anyway, so we can use non-approved cryptography.

For #69536

Change-Id: I7921ec0829b576de2e80f3a7d0a9a776ff387684
Reviewed-on: https://go-review.googlesource.com/c/go/+/624975
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

crypto/aes: move to crypto/internal/fips/aes

The crypto/aes <-> crypto/cipher interfaces and the hardware support
upgrades were layered over the years, and had grown unwieldily.

Before: conditionally wrap the private crypto/aes type in private types
that implement an interface that's interface-upgraded by crypto/cipher
to replace the generic implementation in crypto/cipher.

crypto/aes depended on crypto/cipher, which is backwards.

After: provide concrete exported implementations of modes in
crypto/internal/fips/aes that crypto/cipher returns if the input Block
is the crypto/internal/fips/aes concrete implementation.

crypto/aes and crypto/cipher both depend on crypto/internal/fips/aes.

Also, made everything follow go.dev/wiki/TargetSpecific by only putting
the minimal code necessary and no exported functions in build-tagged
files.

The GCM integration still uses an interface upgrade, because the generic
implementation is complex enough that it was not trivial to duplicate.
This will be fixed in a future CL to make review easier.

For #69536

Change-Id: I21c2b93a498edb31c562b1aca824e21e8457fdff
Reviewed-on: https://go-review.googlesource.com/c/go/+/624395
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>

crypto/aes: speedup CTR mode on AMD64 and ARM64

The implementation runs up to 8 AES instructions in different registers
one after another in ASM code. Because CPU has instruction pipelining
and the instructions do not depend on each other, they can run in
parallel with this layout of code. This results in significant speedup
compared to the regular implementation in which blocks are processed in
the same registers so AES instructions do not run in parallel.

GCM mode already utilizes the approach.

The ASM implementation of ctrAble has most of its code in XORKeyStreamAt
method which has an additional argument, offset. It allows to use it
in a stateless way and to jump to any location in the stream. The method
does not exist in pure Go and boringcrypto implementations.

[ Mailed as CL 413594, then edited by filippo@ to manage the counter
with bits.Add64, remove bounds checks, make the assembly interface more
explicit, and to port the amd64 to Avo. Squeezed another -6.38% out. ]

goos: linux
goarch: amd64
pkg: crypto/cipher
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
            │  19df80d792  │             c8b0409d40              │
            │    sec/op    │   sec/op     vs base                │
AESCTR/50-8    64.68n ± 0%   26.89n ± 0%  -58.42% (p=0.000 n=10)
AESCTR/1K-8   1145.0n ± 0%   135.8n ± 0%  -88.14% (p=0.000 n=10)
AESCTR/8K-8   9145.0n ± 0%   917.5n ± 0%  -89.97% (p=0.000 n=10)
geomean        878.2n        149.6n       -82.96%

            │  19df80d792  │               c8b0409d40               │
            │     B/s      │      B/s       vs base                 │
AESCTR/50-8   737.2Mi ± 0%   1773.3Mi ± 0%  +140.54% (p=0.000 n=10)
AESCTR/1K-8   848.5Mi ± 0%   7156.6Mi ± 0%  +743.40% (p=0.000 n=10)
AESCTR/8K-8   853.8Mi ± 0%   8509.9Mi ± 0%  +896.70% (p=0.000 n=10)
geomean       811.4Mi         4.651Gi       +486.94%

Fixes #20967
Updates #39365
Updates #26673

Co-authored-by: Filippo Valsorda <filippo@golang.org>
Change-Id: Iaeea29fb93a56456f2e54507bc25196edb31b84b
Reviewed-on: https://go-review.googlesource.com/c/go/+/621958
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>

cmd/compile: strongly favor closure inlining

This tweaks the inlining cost knob for closures
specifically, they receive a doubled budget.  The
rationale for this is that closures have a lot of
"crud" in their IR that will disappear after inlining,
so the standard budget penalizes them unnecessarily.

This is also the cause of these bugs -- looking at the
code involved, these closures "should" be inlineable,
therefore tweak the parameters until behavior matches
expectations.  It's not costly in binary size, because
the only-called-from-one-site case is common (especially
for rangefunc iterators).

I can imagine better fixes and I am going to try to
get that done, but this one is small and makes things
better.

Fixes #69411, #69539.

Change-Id: I8a892c40323173a723799e0ddad69dcc2724a8f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/629195
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

os: correctly handle errno==0 in (*Process).blockUntilWaitable

CL 627478 inadvertently returns a non-nil error
containing a syscall.Errno(0).

Change-Id: I1d6a9d0575d3ed651ddc02f30505437d0d266bb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/629515
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>

weak: move internal/weak to weak, and update according to proposal

The updates are:
- API documentation changes.
- Removal of the old package documentation discouraging linkname.
- Addition of new package documentation with some advice.
- Renaming of weak.Pointer.Strong -> weak.Pointer.Value.

Fixes #67552.

Change-Id: Ifad7e629b6d339dacaf2ca37b459d7f903e31bf8
Reviewed-on: https://go-review.googlesource.com/c/go/+/628455
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>

os/user: skip tests that create users when running on dev machines

Creating and deleting users is tricky to get right, and it's not
something we want to do on a developer machine. This change skips the
tests that create users when not running on a Go builder.

This will fix #70396, although I still don't understand why the test
user couldn't be recreated.

Fixes #70396

Change-Id: Ie7004dc209f94e72152c7d6bd8ec95cc12c79757
Reviewed-on: https://go-review.googlesource.com/c/go/+/627877
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

runtime: get rid of gc programs for types

Instead, have the runtime build the gc bitmaps on demand
at runtime.

Change-Id: If7a245bc62e4bce3ce80972410b0ed307d921abe
Reviewed-on: https://go-review.googlesource.com/c/go/+/616255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>

cmd/link: use types (and not GC programs) to build data/bss ptrmasks

The linker knows the types of the global variables. We can use those
types to build the GC programs that describe the data and bss pointer masks.

That way we don't use the GC programs of the constituent types.
This is part of an effort to remove GC programs from the runtime.

There's a major complication in that when we're linking against a
shared library (typically, libstd.so), the relocations we need to
break apart arrays and structs into constituent types are difficult to
find. Load that additional data when linking against shared libraries.

Change-Id: I8516b24a0604479895c7b8a8a358d3cd8d421530
Reviewed-on: https://go-review.googlesource.com/c/go/+/546216
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>

sync: make HashTrieMap[any, any] the default implementation of Map

This change adds a GOEXPERIMENT, synchashtriemap, which replaces the
internals of a sync.Map with internal/sync.HashTrieMap[any, any]. The
main purpose behind this change is improved performance. Across almost
every benchmark, HashTrieMap[any, any] performs better than Map.

Also, relax TestMapClearNoAllocations to allow for one allocation.
Currently, the HashTrieMap allocates a new empty root node and stores
it: that's the whole clear operation. At the cost of some complexity, we
could allow Clear to have zero allocations by clearing the root node.
The complexity comes down to allowing threads to race to install a new
root node *or* creating a top-level mutex for installing a root node.

But I'm not sure this is worth it. Whether Clear or some other operation
takes the hit for allocating a single node almost certainly doesn't
matter. And Clear is still much, much faster in the new implementation
than the old, so I don't consider this a regression.

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

internal/sync: optimize CompareAndSwap and Swap

We observe the CompareAndSwap and Swap can both be substantially faster
if the value in each entry node is mutable. This change modifies the
map entry node to store the value indirectly, allowing us to perform
swaps for existing nodes and compare-and-swaps without taking the
parent node's lock.

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

sync: add HashTrieMap to Map tests and benchmarks

Also, rename Map benchmarks to make them easier to single out via
regexp.

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

internal/sync: add Range to HashTrieMap

This implementation is trivial given that All already exists. The
purpose of Range is to conform to sync.Map's API.

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

internal/sync: add Clear to HashTrieMap

This change adds the Clear operation to HashTrieMap to align it with
sync.Map.

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

internal/sync: add Delete to HashTrieMap

This change adds the Delete operation (with the same semantics as
sync.Map's Delete) to HashTrieMap.

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

internal/sync: refactor HashTrieMap tests into per-op suites

This change does a minor refactor of the HashTrieMap tests to be better
organized into suites for each operation. It might be worthwhile to
deduplicate some code in here, but it's also helpful to see exactly
what's happening when something goes wrong.

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

internal/sync: add LoadAndDelete to HashTrieMap

This change adds the LoadAndDelete operation (with the same semantics as
sync.Map's LoadAndDelete) to HashTrieMap.

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

internal/sync: add Store to HashTrieMap

This change adds the Store operation (with the same semantics as
sync.Map's Store) to HashTrieMap.

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

internal/sync: add Swap to HashTrieMap

This change adds the Swap operation (with the same semantics as
sync.Map's Swap) to HashTrieMap.

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

internal/sync: add CompareAndSwap to HashTrieMap

This change adds the CompareAndSwap operation (with the same semantics
as sync.Map's CompareAndSwap) to HashTrieMap.

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

internal/sync: make the HashTrieMap zero value ready to use

This improves ergonomics a little and aligns the HashTrieMap with
sync.Map.

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

internal/sync: relax value type constraint for HashTrieMap

Currently the HashTrieMap requires both keys and values to be
comparable, but it's actually OK if the value is not comparable. Some
operations may fail, but others will not, and we can check comparability
dynamically on map initialization. This makes the implementation
substantially more flexible.

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

internal/sync: use normal comparison for keys in HashTrieMap

There's are unnecessary calls to the key's equal function -- we can just
leverage the language here. Leave the values alone for now, we want to
relax that constraint.

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

internal/sync: factor out lookup for CompareAndDelete in HashTrieMap

This lookup will be reused for other operations, like CompareAndSwap.

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

internal/sync: move HashTrieMap from internal/concurrent

This change moves internal/concurrent.HashTrieMap from
internal/concurrent into internal/sync just to clean up the packages a
bit. This is all in anticipation of using HashTrieMap from the sync
package.

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

internal/concurrent: remove dependency on math/rand/v2

This change uses linkname for the one random function
internal/concurrent needs to avoid taking a dependency on math/rand/v2.
This lowers the bar to using this package.

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

internal/sync: move sync.Mutex implementation into new package

This CL refactors sync.Mutex such that its implementation lives in the
new internal/sync package. The purpose of this change is to eventually
reverse the dependency edge between internal/concurrent and sync, such
that sync can depend on internal/concurrent (or really, its contents,
which will likely end up in internal/sync).

The only change made to the sync.Mutex code is the frame skip count for
mutex profiling, so that the internal/sync frames are omitted in the
profile.

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

os/user: s/Acount/Account/ in function name

Change-Id: I9aa34951f2005c204aafd9da74e78c033c9b64ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/629315
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>

cmd: change from sort functions to slices functions

Doing this because the slices functions are slightly faster and
slightly easier to use. It also removes one dependency layer.

We did this outside of bootstrap tools in CL 587655.
Now that the bootstrap compiler is 1.22, we can do this in more code.

Change-Id: I9ed2dd473758cacd14f76a0639368523ccdff72f
Reviewed-on: https://go-review.googlesource.com/c/go/+/626038
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>

os: sysctl-based Executable implementation for NetBSD

FreeBSD and Dragonfly have used the sysctl method for years, while
NetBSD has read the name of the executable from /proc. Unfortunately,
some folks are hitting errors when building Go software in a sandbox
that lacks a mounted /proc filesystem.

Switch NetBSD to use the same implementation as FreeBSD and Dragonfly.
Unfortunately, the order of the arguments in the MIB is also
OS-dependent.

Change-Id: I6fd774904af417ccd127e3779af45a20dc8696ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/629035
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Bypass: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>

sync: add explicit noCopy fields to Map, Mutex, and Once

Following CLs will refactor Mutex and change the internals of Map. This
ends up breaking tests in x/tools for the copylock vet check, because
the error message changes. Let's insulate ourselves from such things
permanently by adding an explicit noCopy field. We'll update the vet
check to accept that as the problem, rather than depend on less explicit
internals.

We capture Once here too to clean up the error message as well.

Change-Id: Iead985fc8ec9ef3ea5ff615f26dde17bb03aeadb
Reviewed-on: https://go-review.googlesource.com/c/go/+/627777
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Tim King <taking@google.com>

cmd/compile: remove gc programs from stack frame objects

This is a two-pronged approach. First, try to keep large objects
off the stack frame. Second, if they do manage to appear anyway,
use straight bitmasks instead of gc programs.

Generally probably a good idea to keep large objects out of stack frames.
But particularly keeping gc programs off the stack simplifies
runtime code a bit.

This CL sets the limit of most stack objects to 131072 bytes (on 64-bit archs).
There can still be large objects if allocated by a late pass, like order, or
they are required to be on the stack, like function arguments.
But the size for the bitmasks for these objects isn't a huge deal,
as we have already have (probably several) bitmasks for the frame
liveness map itself.

Change-Id: I6d2bed0e9aa9ac7499955562c6154f9264061359
Reviewed-on: https://go-review.googlesource.com/c/go/+/542815
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>

internal/runtime/maps: don't copy indirect key/elem when growing maps

We can reuse the same indirect storage when growing, so we don't
need an additional allocation.

Change-Id: I57adb406becfbec648188ec66f4bb2e94d4b9cab
Reviewed-on: https://go-review.googlesource.com/c/go/+/625902
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>

runtime: fix MapCycle test

It wasn't actually testing what it says it was testing.
A random permutation isn't cyclic. It only probably hits a few
elements before entering a cycle.
Use an algorithm that generates a random cyclic permutation instead.

Fixing the test makes the previous CL look less good. But it still helps.

(Theory: Fixing the test makes it less cache friendly, so there are
more misses all around. That makes the benchmark slower, suppressing
the differences seen. Also fixing the benchmark makes the loop
iteration count less predictable, which hurts the raw loop
implementation somewhat.)

(baseline = tip, experiment = tip+previous CL, noswiss = GOEXPERIMENT=noswissmap)

goos: darwin
goarch: arm64
pkg: runtime
cpu: Apple M2 Ultra
            │  baseline   │             experiment             │
            │   sec/op    │   sec/op     vs base               │
MapCycle-24   20.59n ± 4%   18.99n ± 3%  -7.77% (p=0.000 n=10)
khr@Mac-Studio src % benchstat noswiss experiment
goos: darwin
goarch: arm64
pkg: runtime
cpu: Apple M2 Ultra
            │   noswiss   │             experiment              │
            │   sec/op    │   sec/op     vs base                │
MapCycle-24   16.12n ± 1%   18.99n ± 3%  +17.83% (p=0.000 n=10)

Change-Id: I3a4edb814ba97fec020a6698c535ce3a87a9fc67
Reviewed-on: https://go-review.googlesource.com/c/go/+/625900
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>

crypto/subtle: document and test XORBytes overlap rules

XORBytes doesn't say anything about how it deals with destination and
source overlaps. Current implementations as written do work if the
destination overlaps perfectly with a source, but will unavoidably
return nonsensical results if the destination is ahead of the source.
Lock in the current behavior with tests, docs, and panics.

Note that this introduces a new panic, but if any applications run into
it we are potentially catching a security issue.

Also, expand the tests and move them outside the FIPS module per #69536
convention. (We want to minimize changes within the module boundary.)

Updates #53021

Change-Id: Ibb0875fd38da3818079e31b83b1a227b53755930
Reviewed-on: https://go-review.googlesource.com/c/go/+/622276
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/compile: avoid static init of strings in FIPS mode

Strings have relocations, and data relocations are bad.
Other literals are fine.

Fixes build failure in pending CL 628776.

Change-Id: I7a38bbff9776a365c5823d54c4a00e068dda5d9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/628915
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>

cmd/internal/obj: exclude external test packages from FIPS scope

Excluding external test packages allows them to use
//go:embed, which requires data relocations in data.
(Obviously the external test code is testing the FIPS module,
not part of it, so this is reasonable.)

Change-Id: I4bae71320ccb5faf718c045540a9ba6dd93e378f
Reviewed-on: https://go-review.googlesource.com/c/go/+/628735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>

net/http/httputil: return after handling error

Fixes #70237

Change-Id: Ieb22b6e7284cb4a40d4987b0e4b9cfb6e5158161
Reviewed-on: https://go-review.googlesource.com/c/go/+/627635
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>

crypto/cipher: add small CTR benchmark, remove CFB/OFB benchmarks

CFB and OFB are mostly unused, and not a performance target.

Updates #39365
Updates #69445

Change-Id: Ice6441e4fee2112a9e72607c63e49dbc50441ba6
Reviewed-on: https://go-review.googlesource.com/c/go/+/621957
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>

crypto/internal/impl: use base package name

Otherwise we risk using crypto/aes in one place and
crypto/internal/fips/aes in another.

Change-Id: I8f498c9457875a9a11c4576281432b5b1c0278c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/624737
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

crypto/internal/fips/subtle: move constant time functions from crypto/subtle

Change-Id: I267a3cac168fc0366fafac4c26e6a80ca545436a
Reviewed-on: https://go-review.googlesource.com/c/go/+/624755
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>

crypto/internal/alias: move to crypto/internal/fips/alias

For #69536

Change-Id: Id0bb46fbb39c205ebc903e72e706bbbaaeec6dbd
Reviewed-on: https://go-review.googlesource.com/c/go/+/622275
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>

cmd/go: fix TestScript/build_json on Windows

The file system directory separator affects this test's output.

Fixes #70397.

Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-linux-amd64-longtest
Change-Id: Id8a3f3e1c26c94ea8f635df4e62e7b0cc2cd5515
Reviewed-on: https://go-review.googlesource.com/c/go/+/628916
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

text/template: don't crash piping to call with no arguments

Fixes #70341

Change-Id: I792b15d5e8d08c3762659fbcdfb3d620b59071ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/628096
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Zxilly Chou <zhouxinyu1001@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

internal/poll: use ignoringEINTR2 in copyFileRange

Change-Id: Id1b2cc4087885f01807f364ce107e4c9421a2ab8
Reviewed-on: https://go-review.googlesource.com/c/go/+/628295
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

os: use ignoringEINTR in (*Process).blockUntilWaitable

Instead of open-coding it.

Change-Id: I7430066550a82e5d69846a1ec08b74474207c006
Reviewed-on: https://go-review.googlesource.com/c/go/+/627478
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>

cmd/go: temporarily disable build JSON in test output

Unfortunately, this is tripping up the LUCI test output processor, so
we need to disable it until we can figure that out.

For #70402.
Updates #62067.

Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64_13,gotip-linux-amd64-longtest
Change-Id: I9ae722218e98b8060b8b4c46358f23381ac8537a
Reviewed-on: https://go-review.googlesource.com/c/go/+/628955
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>

internal/runtime/maps: fix noswiss builder

Missed initializing a field in the stub that lets the noswiss
builder test the swiss implementation.

Change-Id: Ie093478ad3e4301e4fe88ba65c132a9dbccd89a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/628895
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime: relax TestWindowsStackMemory from 100kB to 128kB

We've been getting intermittent flakes in this test since 2023,
all reporting values just barely over 100kB on windows-386.

If we were happy with 100kB, we should be happy with 128kB,
and it should fix the flakes.

Fixes #58570.

Change-Id: Iabe734cfbba6fe28a83f62e7811ee03fed424f0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/628795
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>

runtime/internal/maps: remove entryMask

It is easily recomputed as capacity-1.

This reduces a table from 40 to 32 bytes (on 64-bit archs).
That gets us down one sizeclass.

Change-Id: Icb74fb2de50baa18ca62052c7b2fe8e6af4c8837
Reviewed-on: https://go-review.googlesource.com/c/go/+/625198
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>

internal/runtime/maps: simplify small group lookup

We don't really need the index of the slot we're looking at.
Just keep looking until there are no more filled slots.

This particularly helps when there are only a few filled entries
(packed at the bottom), and we're looking for something that isn't
there. We exit earlier than we would otherwise.

goos: darwin
goarch: arm64
pkg: runtime
cpu: Apple M2 Ultra
                                                 │  baseline   │              experiment               │
                                                 │   sec/op    │   sec/op     vs base                  │
MapSmallAccessHit/Key=int64/Elem=int64/len=1-24    2.759n ± 0%   2.779n ± 2%        ~ (p=0.055 n=10)
MapSmallAccessHit/Key=int64/Elem=int64/len=2-24    2.862n ± 1%   2.922n ± 1%   +2.08% (p=0.000 n=10)
MapSmallAccessHit/Key=int64/Elem=int64/len=3-24    3.003n ± 0%   3.061n ± 1%   +1.91% (p=0.000 n=10)
MapSmallAccessHit/Key=int64/Elem=int64/len=4-24    3.170n ± 1%   3.188n ± 1%   +0.57% (p=0.030 n=10)
MapSmallAccessHit/Key=int64/Elem=int64/len=5-24    3.387n ± 1%   3.391n ± 1%        ~ (p=0.362 n=10)
MapSmallAccessHit/Key=int64/Elem=int64/len=6-24    3.601n ± 1%   3.584n ± 0%   -0.49% (p=0.009 n=10)
MapSmallAccessHit/Key=int64/Elem=int64/len=7-24    3.785n ± 1%   3.778n ± 3%        ~ (p=0.987 n=10)
MapSmallAccessHit/Key=int64/Elem=int64/len=8-24    3.960n ± 1%   3.946n ± 1%        ~ (p=0.256 n=10)
MapSmallAccessMiss/Key=int64/Elem=int64/len=0-24   2.004n ± 1%
MapSmallAccessMiss/Key=int64/Elem=int64/len=1-24   5.145n ± 1%   2.411n ± 1%  -53.14% (p=0.000 n=10)
MapSmallAccessMiss/Key=int64/Elem=int64/len=2-24   5.128n ± 0%   3.313n ± 1%  -35.40% (p=0.000 n=10)
MapSmallAccessMiss/Key=int64/Elem=int64/len=3-24   5.159n ± 1%   3.690n ± 1%  -28.48% (p=0.000 n=10)
MapSmallAccessMiss/Key=int64/Elem=int64/len=4-24   5.117n ± 1%   4.466n ± 6%  -12.73% (p=0.000 n=10)
MapSmallAccessMiss/Key=int64/Elem=int64/len=5-24   5.115n ± 1%   4.308n ± 1%  -15.79% (p=0.000 n=10)
MapSmallAccessMiss/Key=int64/Elem=int64/len=6-24   5.111n ± 1%   4.538n ± 2%  -11.19% (p=0.000 n=10)
MapSmallAccessMiss/Key=int64/Elem=int64/len=7-24   4.896n ± 4%   4.831n ± 1%   -1.33% (p=0.001 n=10)
MapSmallAccessMiss/Key=int64/Elem=int64/len=8-24   4.905n ± 1%   5.121n ± 1%   +4.40% (p=0.000 n=10)
geomean                                            3.917n        3.631n       -11.11%

Change-Id: Ife26ac457a513af24fa0921b839ee6cd5fed6fba
Reviewed-on: https://go-review.googlesource.com/c/go/+/627717
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

internal/runtime/maps: eliminate a load from the hot path

typ.Group.Size involves two loads.

Instead cache GroupSize as a separate fields of the map type
so we can get to it in just one load.

Change-Id: I10ffdce1c7f75dcf448da14040fda78f0d75fd1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/627716
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime/internal/maps: optimize long string keys for small maps

For large strings, do a quick equality check on all the slots.
Only if more than one passes the quick equality check do we
resort to hashing.

                               │    baseline    │             experiment              │
                               │     sec/op     │   sec/op     vs base                │
MegMap-24                        16609.50n ± 1%   13.91n ± 3%  -99.92% (p=0.000 n=10)
MegOneMap-24                     16655.00n ± 0%   12.27n ± 1%  -99.93% (p=0.000 n=10)
MegEqMap-24                         41.31µ ± 1%   25.03µ ± 1%  -39.40% (p=0.000 n=10)
MegEmptyMap-24                      2.034n ± 0%   2.027n ± 2%        ~ (p=0.541 n=10)
MegEmptyMapWithInterfaceKey-24      5.931n ± 2%   5.599n ± 1%   -5.60% (p=0.000 n=10)
MapStringKeysEight_16-24            8.473n ± 7%   8.224n ± 5%        ~ (p=0.315 n=10)
MapStringKeysEight_32-24            8.441n ± 2%   8.147n ± 1%   -3.48% (p=0.002 n=10)
MapStringKeysEight_64-24            8.769n ± 1%   8.517n ± 1%   -2.87% (p=0.000 n=10)
MapStringKeysEight_128-24           10.73n ± 4%   13.57n ± 8%  +26.57% (p=0.000 n=10)
MapStringKeysEight_256-24           12.97n ± 2%   14.35n ± 4%  +10.64% (p=0.001 n=10)
MapStringKeysEight_1M-24         17359.50n ± 3%   13.92n ± 4%  -99.92% (p=0.000 n=10)

Change-Id: I4cc2ea4edab12a4b03236de626c7bcf0f96b6cc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/625905
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

cmd/go: change Printer.Output -> Printer.Printf for consistency

Currently, the Printer interface has `Output`, which acts like Print
and `Errorf`, which acts like Printf. It's confusing that the
formatting style is tied to whether it's regular output or an error.

Fix this by replacing Output with Printf, so both use Printf-style
formatting.

Change-Id: I4c76f941e956f2599c5620b455bf41e21636b44e
Reviewed-on: https://go-review.googlesource.com/c/go/+/627795
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/go: print build errors during go test -json in JSON

Currently, if a test or imported package fails to build during "go
test -json", the build error text will be interleaved with the JSON
output of tests. Furthermore, there’s currently no way to reliably
associate a build error with the test package or packages it affected.
This creates unnecessary friction and complexity in tools that consume
the "go test -json" output.

This CL makes "go test -json" enable JSON reporting of build errors.
It also adds a "FailedBuild" field to the "fail" TestEvent, which
gives the package ID of the package that failed to build and caused
the test to fail.

Using this, CI systems should be able to consume the entire output
stream from "go test -json" in a structured way and easily associate
build failures with test failures during reporting.

Fixes #62067.
Updates #35169.
Updates #37486.

Change-Id: I49091dcc7aa52db01fc9fa6042771633e97b8407
Reviewed-on: https://go-review.googlesource.com/c/go/+/536399
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/go: track root failing Action

Currently, each Action tracks whether it failed, which is propagated
up from dependencies. Shortly, we'll need to know the root cause if a
test fails because of a build failure. To support this, replace the
Failed boolean with a Failed *Action that tracks the root Action that
failed and caused other Actions to fail.

For #62067.

Change-Id: I8f84a51067354043ae9531a4368c6f8b11d688d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/536398
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/go: report all loading errors in tests as "setup failed"

Currently, under *most* circumstances, if there's a package loading
error during "go test", that will get reported as a "FAIL p [setup
failed]" or "FAIL p [build failed] message and won't prevent running
unaffected test packages.

However, if there's a loading error from a non-test file in a package
listed directly on the "go test" command line, that gets reported as
an immediate fatal error, without any "FAIL" line, and without
attempting to run other tests listed on the command line. Likewise,
certain early build errors (like a package containing no Go files) are
currently immediately fatal rather than reporting a test failure.

Fix this by eliminating the check that causes that immediate failure.
This causes one minor follow-up problem: since
load.TestPackagesAndErrors was never passed a top-level package with
an error before, it doesn't currently propagate such an error to the
packages it synthesizes (even though it will propagate errors in
imported packages). Fix this by copying the error from the top-level
package into the synthesized test package while we're copying
everything else.

For #62067.

Change-Id: Icd563a3d9912256b53afd998050995e5260ebe5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/558637
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>

cmd/go: implement "go build -json"

This adds support for a "-json" flag in all build-related go
subcommands. This causes build output and build failures to be
reported to stdout in a machine-readable way.

For #62067.
Fixes #23037.

Change-Id: Id045c5bd5dde9d16cc09dde6248a4b9637896a30
Reviewed-on: https://go-review.googlesource.com/c/go/+/536397
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>

cmd/go: add Printer interface and use for error reporting

This replaces the existing Shell print function callback. The
interface also gives us a way to report build failures, which is the
other type of event that will appear in the build -json output.

This CL hooks up error reporting in two places:

- In Builder.Do, where all builder errors are reported.

- In load.CheckPackageErrors, where most loading errors are reported.

For #62067.

Change-Id: Id66a31b0d2c3786559c7d2bb376fffeffc9a66ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/536396
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

crypto/internal/fips/check: remove unreachable return

return statement is immediately after a panic. This is unreachable
code and vet complains.

Change-Id: I1e483a552b0d1d543414c1e173c1140aa32b5b26
Reviewed-on: https://go-review.googlesource.com/c/go/+/628555
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>

crypto/sha512: improve performance of riscv64 assembly

Implement optimised versions of Maj and Ch, which reduce the number of
instructions required per round. Reorder instructions for better
interleaving.

This gives around a 10% gain on a StarFive VisionFive 2:

                    │  sha512.1   │              sha512.2               │
                    │   sec/op    │   sec/op     vs base                │
Hash8Bytes/New-4      9.310µ ± 0%   8.564µ ± 0%   -8.01% (p=0.000 n=10)
Hash8Bytes/Sum384-4   8.833µ ± 0%   7.980µ ± 0%   -9.66% (p=0.000 n=10)
Hash8Bytes/Sum512-4   9.293µ ± 0%   8.162µ ± 0%  -12.17% (p=0.000 n=10)
Hash1K/New-4          49.60µ ± 0%   44.33µ ± 0%  -10.63% (p=0.000 n=10)
Hash1K/Sum384-4       48.93µ ± 0%   43.78µ ± 0%  -10.53% (p=0.000 n=10)
Hash1K/Sum512-4       49.48µ ± 0%   43.96µ ± 0%  -11.15% (p=0.000 n=10)
Hash8K/New-4          327.9µ ± 0%   292.6µ ± 0%  -10.78% (p=0.000 n=10)
Hash8K/Sum384-4       327.3µ ± 0%   292.0µ ± 0%  -10.77% (p=0.000 n=10)
Hash8K/Sum512-4       327.8µ ± 0%   292.2µ ± 0%  -10.85% (p=0.000 n=10)
geomean               52.87µ        47.31µ       -10.51%

                    │   sha512.1   │               sha512.2               │
                    │     B/s      │     B/s       vs base                │
Hash8Bytes/New-4      839.8Ki ± 0%   908.2Ki ± 0%   +8.14% (p=0.000 n=10)
Hash8Bytes/Sum384-4   888.7Ki ± 1%   976.6Ki ± 0%   +9.89% (p=0.000 n=10)
Hash8Bytes/Sum512-4   839.8Ki ± 0%   957.0Ki ± 0%  +13.95% (p=0.000 n=10)
Hash1K/New-4          19.69Mi ± 0%   22.03Mi ± 0%  +11.86% (p=0.000 n=10)
Hash1K/Sum384-4       19.96Mi ± 0%   22.31Mi ± 0%  +11.75% (p=0.000 n=10)
Hash1K/Sum512-4       19.74Mi ± 0%   22.21Mi ± 0%  +12.51% (p=0.000 n=10)
Hash8K/New-4          23.82Mi ± 0%   26.70Mi ± 0%  +12.09% (p=0.000 n=10)
Hash8K/Sum384-4       23.87Mi ± 0%   26.75Mi ± 0%  +12.07% (p=0.000 n=10)
Hash8K/Sum512-4       23.83Mi ± 0%   26.73Mi ± 0%  +12.16% (p=0.000 n=10)
geomean               7.334Mi        8.184Mi       +11.59%

Change-Id: I66e359e96b25b38efbc4d840e6b2d6a1e5d417ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/605495
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>

runtime/pprof: reduce label overhead

Switch labelMap from map[string]string to use LabelSet as a data
structure. Optimize Labels() for the case where the keys are given in
sorted order without duplicates.

This is primarily motivated by reducing the overhead of distributed
tracing systems that use pprof labels. We have encountered cases where
users complained about the overhead relative to the rest of our
distributed tracing library code. Additionally, we see this as an
opportunity to free up hundreds of CPU cores across our fleet.

A secondary motivation is eBPF profilers that try to access pprof
labels. The current map[string]string requires them to implement Go map
access in eBPF, which is non-trivial. With the enablement of swiss maps,
this complexity is only increasing. The slice data structure introduced
in this CL will greatly lower the implementation complexity for eBPF
profilers in the future. But to be clear: This change does not imply
that the pprof label mechanism is now a stable ABI. They are still an
implementation detail and may change again in the future.

goos: darwin
goarch: arm64
pkg: runtime/pprof
cpu: Apple M1 Max
                                   │ baseline.txt │             patch1.txt              │
                                   │    sec/op    │   sec/op     vs base                │
Labels/set-one-10                    153.50n ± 3%   75.00n ± 1%  -51.14% (p=0.000 n=10)
Labels/merge-one-10                   187.8n ± 1%   128.8n ± 1%  -31.42% (p=0.000 n=10)
Labels/overwrite-one-10               193.1n ± 2%   102.0n ± 1%  -47.18% (p=0.000 n=10)
Labels/ordered/set-many-10            502.6n ± 4%   146.1n ± 2%  -70.94% (p=0.000 n=10)
Labels/ordered/merge-many-10          516.3n ± 2%   238.1n ± 1%  -53.89% (p=0.000 n=10)
Labels/ordered/overwrite-many-10      569.3n ± 4%   247.6n ± 2%  -56.51% (p=0.000 n=10)
Labels/unordered/set-many-10          488.9n ± 2%   308.3n ± 3%  -36.94% (p=0.000 n=10)
Labels/unordered/merge-many-10        523.6n ± 1%   258.5n ± 1%  -50.64% (p=0.000 n=10)
Labels/unordered/overwrite-many-10    571.4n ± 1%   412.1n ± 2%  -27.89% (p=0.000 n=10)
geomean                               366.8n        186.9n       -49.05%

                                   │ baseline.txt │             patch1b.txt              │
                                   │     B/op     │     B/op      vs base                │
Labels/set-one-10                      424.0 ± 0%     104.0 ± 0%  -75.47% (p=0.000 n=10)
Labels/merge-one-10                    424.0 ± 0%     200.0 ± 0%  -52.83% (p=0.000 n=10)
Labels/overwrite-one-10                424.0 ± 0%     136.0 ± 0%  -67.92% (p=0.000 n=10)
Labels/ordered/set-many-10            1344.0 ± 0%     392.0 ± 0%  -70.83% (p=0.000 n=10)
Labels/ordered/merge-many-10          1184.0 ± 0%     712.0 ± 0%  -39.86% (p=0.000 n=10)
Labels/ordered/overwrite-many-10      1056.0 ± 0%     712.0 ± 0%  -32.58% (p=0.000 n=10)
Labels/unordered/set-many-10          1344.0 ± 0%     712.0 ± 0%  -47.02% (p=0.000 n=10)
Labels/unordered/merge-many-10        1184.0 ± 0%     712.0 ± 0%  -39.86% (p=0.000 n=10)
Labels/unordered/overwrite-many-10   1.031Ki ± 0%   1.008Ki ± 0%   -2.27% (p=0.000 n=10)
geomean                                843.1          405.1       -51.95%

                                   │ baseline.txt │             patch1b.txt              │
                                   │  allocs/op   │ allocs/op   vs base                  │
Labels/set-one-10                      5.000 ± 0%   3.000 ± 0%  -40.00% (p=0.000 n=10)
Labels/merge-one-10                    5.000 ± 0%   5.000 ± 0%        ~ (p=1.000 n=10) ¹
Labels/overwrite-one-10                5.000 ± 0%   4.000 ± 0%  -20.00% (p=0.000 n=10)
Labels/ordered/set-many-10             8.000 ± 0%   3.000 ± 0%  -62.50% (p=0.000 n=10)
Labels/ordered/merge-many-10           8.000 ± 0%   5.000 ± 0%  -37.50% (p=0.000 n=10)
Labels/ordered/overwrite-many-10       7.000 ± 0%   4.000 ± 0%  -42.86% (p=0.000 n=10)
Labels/unordered/set-many-10           8.000 ± 0%   4.000 ± 0%  -50.00% (p=0.000 n=10)
Labels/unordered/merge-many-10         8.000 ± 0%   5.000 ± 0%  -37.50% (p=0.000 n=10)
Labels/unordered/overwrite-many-10     7.000 ± 0%   5.000 ± 0%  -28.57% (p=0.000 n=10)
geomean                                6.640        4.143       -37.60%
¹ all samples are equal

Change-Id: Ie68e960a25c2d97bcfb6239dc481832fa8a39754
Reviewed-on: https://go-review.googlesource.com/c/go/+/574516
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

os: add and use ignoringEINTR2

Copy ignoringEINTR2 from internal/poll and make use of it to remove
open-coded implementations.

Change-Id: I8802862f2012980f2af445b75eb45bb5a97bcc2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/627479
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

fmt: document nil receiver handling for GoStringer

Fixes #70305

Change-Id: I8ae4e6dae3327a54039d470c8c8545e2cc6de98f
Reviewed-on: https://go-review.googlesource.com/c/go/+/627495
Reviewed-by: Rob Pike <r@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

runtime: implement Stop for AddCleanup

This change adds the implementation for AddCleanup.Stop. It allows the
caller to cancel the call to execute the cleanup. Cleanup will not be
stopped if the cleanup has already been queued for execution.

For #67535

Change-Id: I494b77d344e54d772c41489d172286773c3814e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/627975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>

runtime: implement AddCleanup

This change introduces AddCleanup to the runtime package. AddCleanup attaches
a cleanup function to an pointer to an object.

The Stop method on Cleanups will be implemented in a followup CL.

AddCleanup is intended to be an incremental improvement over
SetFinalizer and will result in SetFinalizer being deprecated.

For #67535

Change-Id: I99645152e3fdcee85fcf42a4f312c6917e8aecb1
Reviewed-on: https://go-review.googlesource.com/c/go/+/627695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

runtime/pprof: continued attempt to deflake the VMInfo test.

This PR will use test.Skip to bypass a test run for which the vmmap
subprocess appears to hang before the test times out.
In addition it catches a different error message from vmmap that can
occur due to transient resource shortages and triggers a retry for
this additional case.

Fixes #62352

Change-Id: I3ae749e5cd78965c45b1b7c689b896493aa37ba0
Reviewed-on: https://go-review.googlesource.com/c/go/+/560935
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime: improve CALLFN macro for loong64

The previous CALLFN macro was copying a single byte at a time
which is inefficient on loong64. In this CL, according to the
argsize, copy 16 bytes or 8 bytes at a time, and copy 1 byte
a time for the rest.

benchmark in reflect on 3A5000 and 3A6000:

goos: linux
goarch: loong64
pkg: reflect
cpu: Loongson-3A6000 @ 2500.00MHz
                       |  bench.old   |              bench.new              |
                       |    sec/op    |   sec/op     vs base                |
CallArgCopy/size=128      360.2n ± 0%   266.9n ± 0%  -25.90% (p=0.000 n=20)
CallArgCopy/size=256      473.2n ± 0%   277.5n ± 0%  -41.35% (p=0.000 n=20)
CallArgCopy/size=1024    1128.0n ± 0%   332.9n ± 0%  -70.49% (p=0.000 n=20)
CallArgCopy/size=4096    3743.0n ± 0%   672.6n ± 0%  -82.03% (p=0.000 n=20)
CallArgCopy/size=65536   58.888µ ± 0%   9.667µ ± 0%  -83.58% (p=0.000 n=20)
geomean                   2.116µ        693.4n       -67.22%

                       |  bench.old   |               bench.new                |
                       |     B/s      |      B/s       vs base                 |
CallArgCopy/size=128     338.9Mi ± 0%    457.3Mi ± 0%   +34.94% (p=0.000 n=20)
CallArgCopy/size=256     516.0Mi ± 0%    879.8Mi ± 0%   +70.52% (p=0.000 n=20)
CallArgCopy/size=1024    865.5Mi ± 0%   2933.6Mi ± 0%  +238.94% (p=0.000 n=20)
CallArgCopy/size=4096    1.019Gi ± 0%    5.672Gi ± 0%  +456.52% (p=0.000 n=20)
CallArgCopy/size=65536   1.036Gi ± 0%    6.313Gi ± 0%  +509.13% (p=0.000 n=20)
geomean                  699.6Mi         2.085Gi       +205.10%

goos: linux
goarch: loong64
pkg: reflect
cpu: Loongson-3A5000 @ 2500.00MHz
                       |  bench.old   |              bench.new              |
                       |    sec/op    |   sec/op     vs base                |
CallArgCopy/size=128      466.6n ± 0%   368.7n ± 0%  -20.98% (p=0.000 n=20)
CallArgCopy/size=256      579.4n ± 0%   384.6n ± 0%  -33.62% (p=0.000 n=20)
CallArgCopy/size=1024    1273.0n ± 0%   492.0n ± 0%  -61.35% (p=0.000 n=20)
CallArgCopy/size=4096    4049.0n ± 0%   978.1n ± 0%  -75.84% (p=0.000 n=20)
CallArgCopy/size=65536    69.01µ ± 0%   14.50µ ± 0%  -78.99% (p=0.000 n=20)
geomean                   2.492µ        997.9n       -59.96%

                       |  bench.old   |               bench.new                |
                       |     B/s      |      B/s       vs base                 |
CallArgCopy/size=128     261.6Mi ± 0%    331.0Mi ± 0%   +26.54% (p=0.000 n=20)
CallArgCopy/size=256     421.4Mi ± 0%    634.8Mi ± 0%   +50.66% (p=0.000 n=20)
CallArgCopy/size=1024    767.2Mi ± 0%   1985.0Mi ± 0%  +158.75% (p=0.000 n=20)
CallArgCopy/size=4096    964.8Mi ± 0%   3993.8Mi ± 0%  +313.95% (p=0.000 n=20)
CallArgCopy/size=65536   905.7Mi ± 0%   4310.6Mi ± 0%  +375.97% (p=0.000 n=20)
geomean                  593.9Mi         1.449Gi       +149.76%

Change-Id: I9570395af80b2e4b760058098a1b5b07d4b37ad7
Reviewed-on: https://go-review.googlesource.com/c/go/+/627175
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>

runtime: use ABIInternal for calls to sigtrampgo on linux/loong64

Change-Id: I13fd5a96daff66a2ecb54f5bafa3d6e5c60f3879
Reviewed-on: https://go-review.googlesource.com/c/go/+/586357
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Qiqi Huang <huangqiqi@loongson.cn>

runtime: unify lock2, allow deeper sleep

The tri-state mutex implementation (unlocked, locked, sleeping) avoids
sleep/wake syscalls when contention is low or absent, but its
performance degrades when many threads are contending for a mutex to
execute a fast critical section.

A fast critical section means frequent unlock2 calls. Each of those
finds the mutex in the "sleeping" state and so wakes a sleeping thread,
even if many other threads are already awake and in the spin loop of
lock2 attempting to acquire the mutex for themselves. Many spinning
threads means wasting energy and CPU time that could be used by other
processes on the machine. Many threads all spinning on the same cache
line leads to performance collapse.

Merge the futex- and semaphore-based mutex implementations by using a
semaphore abstraction for futex platforms. Then, add a bit to the mutex
state word that communicates whether one of the waiting threads is awake
and spinning. When threads in lock2 see the new "spinning" bit, they can
sleep immediately. In unlock2, the "spinning" bit means we can save a
syscall and not wake a sleeping thread.

This brings up the real possibility of starvation: waiting threads are
able to enter a deeper sleep than before, since one of their peers can
volunteer to be the sole "spinning" thread and thus cause unlock2 to
skip the semawakeup call. Additionally, the waiting threads form a LIFO
stack so any wakeups that do occur will target threads that have gone to
sleep most recently. Counteract those effects by periodically waking the
thread at the bottom of the stack and allowing it to spin.

Exempt sched.lock from most of the new behaviors; it's often used by
several threads in sequence to do thread-specific work, so low-latency
handoff is a priority over improved throughput.

Gate use of this implementation behind GOEXPERIMENT=spinbitmutex, so
it's easy to disable. Enable it by default on supported platforms (the
most efficient implementation requires atomic.Xchg8).

Fixes #68578

    goos: linux
    goarch: amd64
    pkg: runtime
    cpu: 13th Gen Intel(R) Core(TM) i7-13700H
                                │      old       │                 new                  │
                                │     sec/op     │    sec/op     vs base                │
    MutexContention                 17.82n ±   0%   17.74n ±  0%   -0.42% (p=0.000 n=10)
    MutexContention-2               22.17n ±   9%   19.85n ± 12%        ~ (p=0.089 n=10)
    MutexContention-3               26.14n ±  14%   20.81n ± 13%  -20.41% (p=0.000 n=10)
    MutexContention-4               29.28n ±   8%   21.19n ± 10%  -27.62% (p=0.000 n=10)
    MutexContention-5               31.79n ±   2%   21.98n ± 10%  -30.83% (p=0.000 n=10)
    MutexContention-6               34.63n ±   1%   22.58n ±  5%  -34.79% (p=0.000 n=10)
    MutexContention-7               44.16n ±   2%   23.14n ±  7%  -47.59% (p=0.000 n=10)
    MutexContention-8               53.81n ±   3%   23.66n ±  6%  -56.04% (p=0.000 n=10)
    MutexContention-9               65.58n ±   4%   23.91n ±  9%  -63.54% (p=0.000 n=10)
    MutexContention-10              77.35n ±   3%   26.06n ±  9%  -66.31% (p=0.000 n=10)
    MutexContention-11              89.62n ±   1%   25.56n ±  9%  -71.47% (p=0.000 n=10)
    MutexContention-12             102.45n ±   2%   25.57n ±  7%  -75.04% (p=0.000 n=10)
    MutexContention-13             111.95n ±   1%   24.59n ±  8%  -78.04% (p=0.000 n=10)
    MutexContention-14             123.95n ±   3%   24.42n ±  6%  -80.30% (p=0.000 n=10)
    MutexContention-15             120.80n ±  10%   25.54n ±  6%  -78.86% (p=0.000 n=10)
    MutexContention-16             128.10n ±  25%   26.95n ±  4%  -78.96% (p=0.000 n=10)
    MutexContention-17             139.80n ±  18%   24.96n ±  5%  -82.14% (p=0.000 n=10)
    MutexContention-18             141.35n ±   7%   25.05n ±  8%  -82.27% (p=0.000 n=10)
    MutexContention-19             151.35n ±  18%   25.72n ±  6%  -83.00% (p=0.000 n=10)
    MutexContention-20             153.30n ±  20%   24.75n ±  6%  -83.85% (p=0.000 n=10)
    MutexHandoff/Solo-20            13.54n ±   1%   13.61n ±  4%        ~ (p=0.206 n=10)
    MutexHandoff/FastPingPong-20    141.3n ± 209%   164.8n ± 49%        ~ (p=0.436 n=10)
    MutexHandoff/SlowPingPong-20    1.572µ ±  16%   1.804µ ± 19%  +14.76% (p=0.015 n=10)
    geomean                         74.34n          30.26n        -59.30%

    goos: darwin
    goarch: arm64
    pkg: runtime
    cpu: Apple M1
                                │     old      │                 new                  │
                                │    sec/op    │    sec/op     vs base                │
    MutexContention               13.86n ±  3%   12.09n ±  3%  -12.73% (p=0.000 n=10)
    MutexContention-2             15.88n ±  1%   16.50n ±  2%   +3.94% (p=0.001 n=10)
    MutexContention-3             18.45n ±  2%   16.88n ±  2%   -8.54% (p=0.000 n=10)
    MutexContention-4             20.01n ±  2%   18.94n ± 18%        ~ (p=0.469 n=10)
    MutexContention-5             22.60n ±  1%   17.51n ±  9%  -22.50% (p=0.000 n=10)
    MutexContention-6             23.93n ±  2%   17.35n ±  2%  -27.48% (p=0.000 n=10)
    MutexContention-7             24.69n ±  1%   17.15n ±  3%  -30.54% (p=0.000 n=10)
    MutexContention-8             25.01n ±  1%   17.33n ±  2%  -30.69% (p=0.000 n=10)
    MutexHandoff/Solo-8           13.96n ±  4%   12.04n ±  4%  -13.78% (p=0.000 n=10)
    MutexHandoff/FastPingPong-8   68.89n ±  4%   64.62n ±  2%   -6.20% (p=0.000 n=10)
    MutexHandoff/SlowPingPong-8   9.698µ ± 22%   9.646µ ± 35%        ~ (p=0.912 n=10)
    geomean                       38.20n         32.53n        -14.84%

Change-Id: I0058c75eadf282d08eea7fce0d426f0518039f7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/620435
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>

runtime: allow futex OSes to use sema-based mutex

Implement sema{create,sleep,wakeup} in terms of the futex syscall when
available. Split the lock2/unlock2 implementations out of lock_sema.go
and lock_futex.go (which they shared with runtime.note) to allow
swapping in new implementations of those.

Let futex-based platforms use the semaphore-based mutex implementation.
Control that via the new "spinbitmutex" GOEXPERMENT value, disabled by
default.

This lays the groundwork for a "spinbit" mutex implementation; it does
not include the new mutex implementation.

For #68578.

Change-Id: I091289c85124212a87abec7079ecbd9e610b4270
Reviewed-on: https://go-review.googlesource.com/c/go/+/622996
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime: validate all calls to SetFinalizer

This change moves the check for a change in the memory management
system to after the SetFinalizer parameters have been validated.
Moving the check ensures that invalid parameters will never pass the
validation checks.

Change-Id: I9f1d3454f891f7b147c0d86b6720297172e08ef9
Reviewed-on: https://go-review.googlesource.com/c/go/+/625035
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime: add race detector tips to reportZombies func

We can find a few issues finally turned out to be a race condition,
such as #47513. I believe such a tip can eliminate the need for developers
to file this kind of issue in the first place.

Change-Id: I1597fa09fde641882e8e87453470941747705272
GitHub-Last-Rev: 9f136f5b3bee78f90f434dcea1cabf397c6c05f2
GitHub-Pull-Request: golang/go#70331
Reviewed-on: https://go-review.googlesource.com/c/go/+/627816
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

crypto/internal/bigmod: add comparison test for addMulVVW

Sized addMulVVW (addMulVVW1024 etc.) have architecture-specific
implementations on a number of architectures. Add a test checking
that they match the generic implementation.

Change-Id: I574f00ad7cd27d4e1bf008561023f713876244f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/628256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>

crypto/internal/bigmod: apply wasm-specific implementation for only sized addMulVVW

Restore generic addMulVVW for wasm (and therefore for all
architectures). Apply wasm-specific implementation for only the
explicitly sized functions (addMulVVW1024 etc.).

Also, for the sized functions, use unsafe pointer calculations
directly, without converting them back to slices. (This is what
the assembly code does on other architectures.) This results in a
bit more speedup for crypto/rsa benchmarks on Wasm:

pkg: crypto/rsa
                     │   old.txt   │              new.txt                │
                     │   sec/op    │   sec/op     vs base                │
DecryptPKCS1v15/2048   4.906m ± 0%   4.221m ± 1%  -13.96% (p=0.000 n=25)
DecryptPKCS1v15/3072   15.18m ± 0%   13.57m ± 0%  -10.64% (p=0.000 n=25)
DecryptPKCS1v15/4096   35.49m ± 0%   32.64m ± 1%   -8.04% (p=0.000 n=25)
EncryptPKCS1v15/2048   177.1µ ± 0%   162.3µ ± 0%   -8.35% (p=0.000 n=25)
DecryptOAEP/2048       4.900m ± 1%   4.233m ± 0%  -13.61% (p=0.000 n=25)
EncryptOAEP/2048       181.8µ ± 0%   166.8µ ± 0%   -8.24% (p=0.000 n=25)
SignPKCS1v15/2048      5.026m ± 1%   4.341m ± 0%  -13.63% (p=0.000 n=25)
VerifyPKCS1v15/2048    177.2µ ± 0%   161.3µ ± 1%   -8.97% (p=0.000 n=25)
SignPSS/2048           5.020m ± 0%   4.344m ± 1%  -13.47% (p=0.000 n=25)
VerifyPSS/2048         182.2µ ± 1%   166.6µ ± 0%   -8.52% (p=0.000 n=25)
geomean                1.791m        1.598m       -10.78%

Change-Id: I89775c46a0bbe29380889047ba393c6cfc093ff1
Reviewed-on: https://go-review.googlesource.com/c/go/+/628255
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>

sync/atomic: make intrinsics noescape except 64bits op on 32bits arch and unsafe.Pointer

Fixes #16241

I made 64 bits op on 32 bits arches still leak since it was kinda promised.

The promised leaks were wider than this but I don't belive it's effect can
be observed in an breaking maner without using unsafe the way it's currently
setup.

Change-Id: I66d8df47bfe49bce3efa64ac668a2a55f70733a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/462298
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

cmd/go: add user provided auth mode for GOAUTH

This CL adds support for a custom authenticator as a valid GOAUTH command.
This follows the specification in
https://go.dev/issue/26232#issuecomment-461525141

For #26232

Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: Id1d4b309f11eb9c7ce14793021a9d8caf3b192ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/605298
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/go: add bzr based version stamping for binaries

This CL adds support for tagging binaries in a bzr vcs environment.

For: #50603
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I81eb72d9e0e15dbec8778dd06613ca212820a726
Reviewed-on: https://go-review.googlesource.com/c/go/+/627295
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

doc/next: pre-announce dropping macOS 11 support

Go 1.24 is the last release that will run on macOS 11 Big Sur.
Go 1.25 will require macOS 12 Monterey or later.

For #69839.
For #23011.

Change-Id: Ic58beff0f7eb69f600add5c17cf6edd960d09980
Reviewed-on: https://go-review.googlesource.com/c/go/+/627616
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>

os/user: support built-in service user accounts on Windows

Built-in service user accounts should be treated as special cases
of well-known groups and allowed in user.Lookup and user.LookupId.

Namely, these accounts are:
- NT AUTHORITY\SYSTEM (S-1-5-18)
- NT AUTHORITY\LOCAL SERVICE (S-1-5-19)
- NT AUTHORITY\NETWORK SERVICE (S-1-5-20)

See https://learn.microsoft.com/en-us/windows/win32/services/service-user-accounts.

Note that #49509 also mentions S-1-5-17 (NT AUTHORITY\IUSR) as
another well-known group that should be treated as a user. I haven't
found any documentation supporting this claim, and it is not an account
that is used usually, so I'm not adding it for now.

This CL is heavily based on CL 452497.

Fixes #49509

Change-Id: I6e204ddfb4ed0c01b4503001cf284602531e4a88
Reviewed-on: https://go-review.googlesource.com/c/go/+/626255
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>

cmd/compile/internal/staticinit: remove FIPS debugging

This is panicking on the darwin-amd64-longtest builders.
Not sure why, but it was added only to get a stack trace
during debugging. If there's still a problem, we should let
it proceed and find the real problem.

The test that was failing - internal/coverage/cfile - passes
with this CL, even when I set GODEBUG=fips140=on,
so there's hope that it will fix the longtest builders.

Change-Id: I9b3e743effdddcc0a76895922f87631527781dff
Reviewed-on: https://go-review.googlesource.com/c/go/+/628375
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

crypto/internal/fips: make linknames path-independent

When using a FIPS140 snapshot, the import paths will have
FIPS version numbers in them, so use explicit import paths
for coordination with package runtime, which expects
crypto/internal/fips, not (say) crypto/internal/fips/v1.1.

Change-Id: I3ac48c84810493152e039eaa5f44d7cfe13d35f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/627915
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>

crypto/internal/fips/check: fix for ASAN builds

For now, FIPS does not work with ASAN: ASAN detects reads
it doesn't like during the scans of memory done by verification.
It could be made to work if there was a way to disable ASAN
during verification, but that doesn't appear to be possible.

Instead of a cryptic ASAN message, panic with a clear error.
And disable the test during ASAN.

Fixes #70321.

Change-Id: Ibc3876836abb83248a23c18c3b44c4cbb4a0c600
Reviewed-on: https://go-review.googlesource.com/c/go/+/627603
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>

internal/fuzz: add benchmarks for byte slice mutators

Cover each byte slice mutation function in a benchmark.
Grants visibility into the cost of each transformation
and allows us to perform informed optimization.

Results on go1.23/Intel Alder Lake i5-12600K (n=16):

name                                                  time/op
ByteSliceMutators/RemoveBytes/64-16                   14.8ns ± 0%
ByteSliceMutators/RemoveBytes/128-16                  14.6ns ± 0%
ByteSliceMutators/RemoveBytes/256-16                  14.7ns ± 0%
ByteSliceMutators/RemoveBytes/512-16                  17.0ns ± 0%
ByteSliceMutators/RemoveBytes/1024-16                 18.3ns ± 0%
ByteSliceMutators/InsertRandomBytes/64-16             9.88ns ± 0%
ByteSliceMutators/InsertRandomBytes/128-16            9.88ns ± 1%
ByteSliceMutators/InsertRandomBytes/256-16            9.87ns ± 0%
ByteSliceMutators/InsertRandomBytes/512-16            9.88ns ± 0%
ByteSliceMutators/InsertRandomBytes/1024-16           9.87ns ± 0%
ByteSliceMutators/DuplicateBytes/64-16                12.4ns ± 0%
ByteSliceMutators/DuplicateBytes/128-16               12.3ns ± 0%
ByteSliceMutators/DuplicateBytes/256-16               12.3ns ± 0%
ByteSliceMutators/DuplicateBytes/512-16               12.3ns ± 0%
ByteSliceMutators/DuplicateBytes/1024-16              12.3ns ± 0%
ByteSliceMutators/OverwriteBytes/64-16                17.5ns ± 0%
ByteSliceMutators/OverwriteBytes/128-16               17.3ns ± 0%
ByteSliceMutators/OverwriteBytes/256-16               17.1ns ± 0%
ByteSliceMutators/OverwriteBytes/512-16               17.0ns ± 0%
ByteSliceMutators/OverwriteBytes/1024-16              17.0ns ± 0%
ByteSliceMutators/BitFlip/64-16                       5.06ns ± 1%
ByteSliceMutators/BitFlip/128-16                      5.07ns ± 1%
ByteSliceMutators/BitFlip/256-16                      5.07ns ± 1%
ByteSliceMutators/BitFlip/512-16                      5.07ns ± 0%
ByteSliceMutators/BitFlip/1024-16                     5.06ns ± 1%
ByteSliceMutators/XORByte/64-16                       5.33ns ± 1%
ByteSliceMutators/XORByte/128-16                      5.30ns ± 1%
ByteSliceMutators/XORByte/256-16                      5.29ns ± 1%
ByteSliceMutators/XORByte/512-16                      5.29ns ± 1%
ByteSliceMutators/XORByte/1024-16                     5.29ns ± 1%
ByteSliceMutators/SwapByte/64-16                      5.75ns ± 0%
ByteSliceMutators/SwapByte/128-16                     5.70ns ± 0%
ByteSliceMutators/SwapByte/256-16                     5.67ns ± 0%
ByteSliceMutators/SwapByte/512-16                     5.67ns ± 1%
ByteSliceMutators/SwapByte/1024-16                    5.67ns ± 0%
ByteSliceMutators/ArithmeticUint8/64-16               9.55ns ± 0%
ByteSliceMutators/ArithmeticUint8/128-16              9.56ns ± 0%
ByteSliceMutators/ArithmeticUint8/256-16              9.57ns ± 0%
ByteSliceMutators/ArithmeticUint8/512-16              9.56ns ± 0%
ByteSliceMutators/ArithmeticUint8/1024-16             9.56ns ± 0%
ByteSliceMutators/ArithmeticUint16/64-16              13.2ns ± 0%
ByteSliceMutators/ArithmeticUint16/128-16             13.2ns ± 0%
ByteSliceMutators/ArithmeticUint16/256-16             13.2ns ± 0%
ByteSliceMutators/ArithmeticUint16/512-16             13.2ns ± 0%
ByteSliceMutators/ArithmeticUint16/1024-16            13.2ns ± 0%
ByteSliceMutators/ArithmeticUint32/64-16              13.4ns ± 0%
ByteSliceMutators/ArithmeticUint32/128-16             13.4ns ± 0%
ByteSliceMutators/ArithmeticUint32/256-16             13.4ns ± 0%
ByteSliceMutators/ArithmeticUint32/512-16             13.4ns ± 0%
ByteSliceMutators/ArithmeticUint32/1024-16            13.4ns ± 0%
ByteSliceMutators/ArithmeticUint64/64-16              13.4ns ± 0%
ByteSliceMutators/ArithmeticUint64/128-16             13.5ns ± 0%
ByteSliceMutators/ArithmeticUint64/256-16             13.5ns ± 0%
ByteSliceMutators/ArithmeticUint64/512-16             13.5ns ± 0%
ByteSliceMutators/ArithmeticUint64/1024-16            13.5ns ± 0%
ByteSliceMutators/OverwriteInterestingUint8/64-16     5.39ns ± 2%
ByteSliceMutators/OverwriteInterestingUint8/128-16    5.38ns ± 1%
ByteSliceMutators/OverwriteInterestingUint8/256-16    5.37ns ± 1%
ByteSliceMutators/OverwriteInterestingUint8/512-16    5.41ns ± 2%
ByteSliceMutators/OverwriteInterestingUint8/1024-16   5.38ns ± 0%
ByteSliceMutators/OverwriteInterestingUint16/64-16    10.7ns ± 0%
ByteSliceMutators/OverwriteInterestingUint16/128-16   10.7ns ± 0%
ByteSliceMutators/OverwriteInterestingUint16/256-16   10.7ns ± 0%
ByteSliceMutators/OverwriteInterestingUint16/512-16   10.7ns ± 0%
ByteSliceMutators/OverwriteInterestingUint16/1024-16  10.7ns ± 0%
ByteSliceMutators/OverwriteInterestingUint32/64-16    10.9ns ± 0%
ByteSliceMutators/OverwriteInterestingUint32/128-16   10.9ns ± 0%
ByteSliceMutators/OverwriteInterestingUint32/256-16   10.9ns ± 0%
ByteSliceMutators/OverwriteInterestingUint32/512-16   10.9ns ± 0%
ByteSliceMutators/OverwriteInterestingUint32/1024-16  10.9ns ± 0%
ByteSliceMutators/InsertConstantBytes/64-16           10.1ns ± 0%
ByteSliceMutators/InsertConstantBytes/128-16          10.1ns ± 0%
ByteSliceMutators/InsertConstantBytes/256-16          10.1ns ± 0%
ByteSliceMutators/InsertConstantBytes/512-16          10.1ns ± 0%
ByteSliceMutators/InsertConstantBytes/1024-16         10.1ns ± 0%
ByteSliceMutators/OverwriteConstantBytes/64-16        18.7ns ± 0%
ByteSliceMutators/OverwriteConstantBytes/128-16       18.8ns ± 0%
ByteSliceMutators/OverwriteConstantBytes/256-16       18.8ns ± 0%
ByteSliceMutators/OverwriteConstantBytes/512-16       19.0ns ± 0%
ByteSliceMutators/OverwriteConstantBytes/1024-16      19.3ns ± 0%
ByteSliceMutators/ShuffleBytes/64-16                  24.5ns ± 0%
ByteSliceMutators/ShuffleBytes/128-16                 25.4ns ± 0%
ByteSliceMutators/ShuffleBytes/256-16                 26.6ns ± 0%
ByteSliceMutators/ShuffleBytes/512-16                 28.2ns ± 0%
ByteSliceMutators/ShuffleBytes/1024-16                33.3ns ± 0%
ByteSliceMutators/SwapBytes/64-16                     16.2ns ± 1%
ByteSliceMutators/SwapBytes/128-16                    15.8ns ± 0%
ByteSliceMutators/SwapBytes/256-16                    15.5ns ± 0%
ByteSliceMutators/SwapBytes/512-16                    15.4ns ± 0%
ByteSliceMutators/SwapBytes/1024-16                   15.3ns ± 0%
[Geo mean]                                            11.0ns

Note that implementing this via a single parent benchmark function
adds an overhead of about 1-8%, but that should be acceptable and
results in more concise code.

Change-Id: Ifa2693f8fc8c2058513a615208d0d6862efd3617
Reviewed-on: https://go-review.googlesource.com/c/go/+/623895
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>

crypto/internal/fips/check: enable windows/arm64

Looks like it works.

Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64
Change-Id: I4914d5076eccaf1dd850a148070f179edf291c40
Reviewed-on: https://go-review.googlesource.com/c/go/+/627958
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>

cmd/internal/obj/fips: mark R_ADDRPOWR_GOT as a pcrel relocation

It's actually a TOC relative relocation, but those are also accepted
as pcrel relocations here too. This fixes compilation on GOPPC64 <= power9.

Change-Id: I235125a76f59ab26c6c753540cfaeb398f9c105d
Reviewed-on: https://go-review.googlesource.com/c/go/+/628157
Auto-Submit: Paul Murphy <murp@ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>

log/slog: add DiscardHandler

This adds a package-level variable, slog.DiscardHandler, which is a
slog.Handler which performs no output. This serves a similar purpose
to io.Discard.

Fixes #62005

Change-Id: Ia8babc55f860dec9b663a5c400090a7669608fd5
GitHub-Last-Rev: 0a611174ee8819a2f4e1b8e196a60d5acc6ef9f7
GitHub-Pull-Request: golang/go#70296
Reviewed-on: https://go-review.googlesource.com/c/go/+/626486
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

internal/exportdata: introduce shared library for exportdata

Deduplicates FindPkg and FindExportData which were shared by
go/internal/gcimporter and cmd/compile/internal/importer into
a new package internal/exportdata.

This change only moves code.

Change-Id: I1daf24dd79fafbe9014b2b15671dcde46b54711e
Reviewed-on: https://go-review.googlesource.com/c/go/+/626700
Commit-Queue: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime: add test for mutex starvation

When multiple threads all need to acquire the same runtime.mutex, make
sure that none of them has to wait for too long. Measure how long a
single thread can capture the mutex, and how long individual other
threads must go between having a turn with the mutex.

For #68578

Change-Id: I56ecc551232f9c2730c128a9f8eeb7bd45c2d3b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/622995
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>

cmd/compile/internal/importer: minimize Import differences

Minimizes the differences with go/internal/gcimporter.Import.

Note that the copy in cmd/compile/internal/importer is currently
only used in tests.

The delta between the two Import functions is now just types vs types2.

Change-Id: I5e94d3aa5bbdb78252e47310c95807f63e27ef3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/626698
Commit-Queue: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/compile/internal/types2: enable disabled part of an example test (cleanup)

Change-Id: I8ffb198d64ec1b89e6d13bfa299bf699f1ca3830
Reviewed-on: https://go-review.googlesource.com/c/go/+/628156
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Tim King <taking@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>

go/internal/gcimporter,cmd/compile/internal/importer: reuse archive.ReadHeader

Reuse (or copy) cmd/internal/archive.ReadHeader in importers.

Change-Id: I3caa19b1b366c2bbffcdeb0ef4db337ee457b47e
Reviewed-on: https://go-review.googlesource.com/c/go/+/626776
Commit-Queue: Tim King <taking@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>

strconv: cleanup old compiler bits.TrailingZeros workaround

Since CL 599096 the compiler knows bits.TrailingZeros's maximum value
based on the input type size.

Since CL 603996 it knows it based on input's maximum value.

Change-Id: Ib0d6b15a3ba6894d3e7e12b79b387ddbffabe370
Reviewed-on: https://go-review.googlesource.com/c/go/+/618715
Auto-Submit: Robert Griesemer <gri@google.com>
Commit-Queue: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>

make.rc: correct test for undefined GOROOT_BOOTSTRAP

The test "if(! ~ $#GOROOT_BOOTSTRAP 1)", to check for the environment
variable GOROOT_BOOTSTRAP being undefined, will not succeed if the
variable is set to the empty string (as the coordinator was doing).
A better test is "if(~ $"GOROOT_BOOTSTRAP '')", which succeeds if
the variable is undefined, or set to an empty list or an empty string.

For #69038

Change-Id: Ic6e6944e0c76461daea206ba9575b863f92f6228
Reviewed-on: https://go-review.googlesource.com/c/go/+/627944
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>

cmd/go: print not-defaults arch-env

Fixes #67492
For #34208

Change-Id: Idcddf88aad8e18b0274ce8e2ff8a83d57db603a6
GitHub-Last-Rev: 8ef7cf59d0fd6d2d99177277c8a4237e7a86f895
GitHub-Pull-Request: golang/go#67493
Reviewed-on: https://go-review.googlesource.com/c/go/+/586241
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>