go/types: fix type inference

This is a 1:1 port of CL 311651 to go/types.

Change-Id: I9d91b45cc5fa7ce686d6a91d4dde274d9f80e0d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/314595
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

runtime: use a single definition of time_now for faketime

Build other definitions with the !faketime build tag.

This makes it easy for us to add new assembly implementations of time.now.

Change-Id: I4e48e41a4a04ab001030e6d1cdd9cebfa0161b0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314274
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

runtime: move Windows time.now implementations into separate files

This is a step toward separating whether time.now is implemented in
assembly from whether we are using faketime.

Change-Id: I8bf059b44a103b034835e3d3b799319cc05e9552
Reviewed-on: https://go-review.googlesource.com/c/go/+/314273
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

go/types: use a global atomic counter for type parameter ids

This is a 1:1 port of CL 309830 to go/types.

Change-Id: Ibf709f8194dd5e93a87145e5f9db674ce93af529
Reviewed-on: https://go-review.googlesource.com/c/go/+/314594
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

go/types: add example test for type inference

This is a port of CL 308973. The only change is to remove a TODO at
inference.go2:100 to improve the error position. The go/types error
position is fine.

Change-Id: Ibf61f3458adde91dec9c7531cbd892ca654a5497
Reviewed-on: https://go-review.googlesource.com/c/go/+/314593
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

go/types: use combined type and ordinary args for type inference

This is a port of CL 308372 to go/types. The only meaningful change was
to add TODOs to improve the positioning error messages.

Change-Id: I8314615d0851a59c2b5fd30eb897d581652eacc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/314435
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

crypto/cipher: make AES-GCM benchmarks match ChaCha20Poly1305 ones

It's useful to compare TLS AEADs. Here are the numbers on my MacBook
with an Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz.

name                            speed
AESGCM/Open-128-64-8             692MB/s ± 2%
AESGCM/Seal-128-64-8             568MB/s ± 1%
AESGCM/Open-128-1350-8          3.96GB/s ± 1%
AESGCM/Seal-128-1350-8          3.17GB/s ± 4%
AESGCM/Open-128-8192-8          5.46GB/s ± 2%
AESGCM/Seal-128-8192-8          4.40GB/s ± 3%

name                            speed
AESGCM/Open-256-64-8             602MB/s ± 2%
AESGCM/Seal-256-64-8             508MB/s ± 1%
AESGCM/Open-256-1350-8          3.06GB/s ± 1%
AESGCM/Seal-256-1350-8          2.65GB/s ± 2%
AESGCM/Open-256-8192-8          4.02GB/s ± 3%
AESGCM/Seal-256-8192-8          3.53GB/s ± 2%

name                            speed
Chacha20Poly1305/Open-64-8       385MB/s ± 3%
Chacha20Poly1305/Seal-64-8       396MB/s ± 3%
Chacha20Poly1305/Open-1350-8    1.67GB/s ± 2%
Chacha20Poly1305/Seal-1350-8    1.62GB/s ± 1%
Chacha20Poly1305/Open-8192-8    2.04GB/s ± 2%
Chacha20Poly1305/Seal-8192-8    2.04GB/s ± 3%

Change-Id: I9373ab85bf132b45b41078205259100fa2d46dda
Reviewed-on: https://go-review.googlesource.com/c/go/+/314610
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>

spec: clarify conditions for switch expression type

1. The existing prose implied that a switch expression type must
   be comparable because it is tested for equality against all case
   expressions. But for an empty switch (no case expressions), it
   was not clear if the switch expression needed to be comparable.
   Require it to match the behavior of compiler and type checkers.

2. While making this change, remove redundant language explaining
   what happens with untyped boolean switch expression values: the
   default type of an untyped boolean value is bool, this is already
   covered by the first part of the relevant sentence.

Fixes #43200.

Change-Id: Id8e0f29cfa8722b57cd2b7b58cba85b58c5f842b
Reviewed-on: https://go-review.googlesource.com/c/go/+/314411
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>

types2: disambiguate package qualifiers in error messages

This is a port of the go/types CL https://golang.org/cl/313035
with minor adjustments (use of package syntax rather than go/ast).

Change-Id: I89410efb3d27be85fdbe827f966c2c91ee5693b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314410
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>

cmd/compile/internal/types2: catch unexpected expression lists

This is a modified port of the https://golang.org/cl/313909
change for go/types.

- add catch-all cases for unexpected expression lists
- add Checker.singleIndex function to check single indices
- better syntax error handling in parser for invalid type
  instantiations that are missing a type argument

Change-Id: I6f0f396d637ad66b79f803d886fdc20ee55a98b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/314409
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>

cmd/go/internal/modfetch: fix comment that mentions no-longer returned error

In c9211577eb77df9c51f0565f1da7d20ff91d59df @bcmills removed the returned error from
`Lookup`. However, the function docstring still mentions that this can return an error.

So this corrects the docs.

Change-Id: Idca74a200dfdb024e3d7ff6c439c70632cfec11a
GitHub-Last-Rev: 62eaacf70c3886d8aba25b79212c61485a89fde0
GitHub-Pull-Request: golang/go#45822
Reviewed-on: https://go-review.googlesource.com/c/go/+/314572
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/gofmt: simplify arg handling

First, we can use flag.Args instead of flag.NArg and flag.Arg.

Second, just call filepath.WalkDir directly on each argument. We don't
need to check if each argument is a directory or not, since the function
will still work on regular files as expected.

To continue giving an error in the "gofmt does-not-exist.go" case, we
now need to return and handle errors from filepath.WalkDir, too.
Arguably, that should have always been the case.

While at it, I noticed that the printinf of the "diff" command did not
obey the "out" parameter. Fix that.

Finally, remove the code to ignore IsNotExist errors. It was added in CL
19301, though it didn't include tests and its reasoning is dubious.
Using gofmt on a directory treewhile another program is concurrently
editing or removing files is inherently racy. Hiding errors can hide
valid problems from the user, and such racy usages aren't supported.

Change-Id: I2e74cc04c53eeefb25231d804752b53562b97371
Reviewed-on: https://go-review.googlesource.com/c/go/+/284138
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/go/internal/modload: in importFromModules, do not wrap module graph errors in ImportMissingError

If an error occurs in loading the module graph (such as a missing
checksum for a relevant go.mod file), that error should be terminal
and we should not look elsewhere to try to resolve the import. An
ImportMissingError instructs the caller to do exactly that, so don't
use that error type for this case.

(This behavior is tested incidentally in a later CL in this stack.)

For #36460

Change-Id: I963e39cc7fbc457c12a626c1402c0be29203d23b
Reviewed-on: https://go-review.googlesource.com/c/go/+/314633
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>

go/types: split out function instantiation from index expr

This is a port of CL 308371 to go/types. The only meaningful change from
that CL is to use explicit return values in Checker.indexExpr, which I
felt was more readable. I made the same change in types2 to keep them in
sync

Change-Id: I3380c03fe49d3bf4167cadad305abe942785af19
Reviewed-on: https://go-review.googlesource.com/c/go/+/314432
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

cmd/compile: use desired register only if it satisfies register mask

In the register allocator, if possible, we allocate a value to its
desired register (the ideal register for its next use). In some
cases the desired register does not satisfies the value's output
register mask. We should not use the register in this case.

In the following example, v33 is going to be returned as a
function result, so it is allocated to its desired register AX.
However, its Op cannot use AX as output, causing miscompilation.

v33 = CMOVQEQF <int> v24 v28 v29 : AX (~R0[int])
v35 = MakeResult <int,int,mem> v33 v26 v18
Ret v35

Change-Id: Id0f4f27c4b233ee297e83077e3c8494fe193e664
Reviewed-on: https://go-review.googlesource.com/c/go/+/314630
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

testing: add -shuffle=off|on|N to alter the execution order of tests and benchmarks

This CL adds a new flag to the testing package and the go test command
which randomizes the execution order for tests and benchmarks.
This can be useful for identifying unwanted dependencies
between test or benchmark functions.
The flag is off by default. If `-shuffle` is set to `on` then the system
clock will be used as the seed value. If `-shuffle` is set to an integer
N, then N will be used as the seed value. In both cases, the seed will
be reported for failed runs so that they can reproduced later on.

Fixes #28592

Change-Id: I62e7dfae5f63f97a0cbd7830ea844d9f7beac335
Reviewed-on: https://go-review.googlesource.com/c/go/+/310033
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Bryan C. Mills <bcmills@google.com>

runtime: consolidate Windows time constants into single copy

Change-Id: I1a583d3da9cca4ac51f3fec9b508b7638b452d60
Reviewed-on: https://go-review.googlesource.com/c/go/+/314270
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

cmd/go: include C/C++/Fortran compiler version in build ID

This will force a rebuild if the C/C++/Fortran compiler changes.

No test because a real test requires installing two different compilers.

Fixes #40042

Change-Id: I83cc88ade90d665a6fce06435068f39c811e43af
Reviewed-on: https://go-review.googlesource.com/c/go/+/314276
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

test: do not run fuse test in noopt mode

Change-Id: Iad8ac2253ce28fd0a331bde36836d1b7f25797bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/314632
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/link: don't pass -Wl,--dynamic-linker if -static

As with -rdynamic, clang will pass -Wl,--dynamic-linker to the linker
even when linking statically. When using lld this will produce a statically
linked executable with a dynamic interpreter, which will crash at runtime.
This CL changes the linker to drop -Wl,--dynamic-linker when using -static,
as it already does with -rdynamic.

This has become more important since CL 310349, which changes the linker
to always pass a -Wl,--dynamic-linker option if the Go linker is invoked
with a -I option.

Change-Id: I68ed431064f02c70018bc0547585e5b0ebd20a41
Reviewed-on: https://go-review.googlesource.com/c/go/+/314412
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/go/internal/bug: use envcmd instead of go env

Add the printGoEnv function to print the go environment variables, using
the envcmd package instead of invoking go env.

Add the PrintEnv function to the envcmd package, to avoid duplicating
code.

Updates #45803

Change-Id: I38d5b936c0ebb16e741ffbee4309b95d6d0ecc6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/314230
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/go: populate module info even if an error occurs in loading package

The existing implementation ignores module info if there is any error loading the package.

Fixes #44287

Change-Id: I24142e4c7256517292fc654e29d759871b80bc09
GitHub-Last-Rev: 28e9bf85e8c119f3b805c38c79aef60322fcc551
GitHub-Pull-Request: golang/go#45777
Reviewed-on: https://go-review.googlesource.com/c/go/+/313549
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Matloob <matloob@golang.org>

cmd/link: use R12 as trampoline scratch register on ARM

The external linker uses R12. Do the same. We previously use R11,
the temp register in Go ABI. This does not really matter if the
caller is Go code, because all registers are clobbered at call.
But it the caller is C code, it may assume R11 live across a call.
Using R11 may clobber live value. On the callee side, R12 is not
an argument register in both Go and C calling convention.

Change-Id: I958c5dad52aa51bb282a7ad420f5423863e69c14
Reviewed-on: https://go-review.googlesource.com/c/go/+/314454
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

cmd/compile: mark R12 clobbered for special calls

In external linking mode the external linker may insert
trampolines, which use R12 as a scratch register. So a call could
potentially clobber R12 if the target is laid out too far. Mark
R12 clobbered.

Also, we will use R12 for trampolines in the Go linker as well.

CL 310731 updated the generated rewrite files so imports are
grouped, but the generator was not updated to do so. Grouped
imports are nice. But as those are generated files, for
simplicity and my laziness, just regenerate with the current
generator (which makes imports not grouped).

Change-Id: Iddb741ff7314a291ade5fbffc7d315f555808409
Reviewed-on: https://go-review.googlesource.com/c/go/+/314453
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

cmd/go: make TOOLEXEC_IMPORTPATH consistent with 'go list -f {{.ImportPath}}'

TOOLEXEC_IMPORTPATH is useful for the toolexec program to know what
package is currently being built. This is otherwise tricky to figure out.

Unfortunately, for test packages it was lacking. In the added test case,
we have a total of four packages in 'go list -test':

test/main
test/main.test
test/main [test/main.test]
test/main_test [test/main.test]

And, when running with -toolexec, one would get the following values:

        # test/main_test [test/main.test]
        compile TOOLEXEC_IMPORTPATH="test/main_test"
        # test/main [test/main.test]
        compile TOOLEXEC_IMPORTPATH="test/main"
        # test/main.test
        compile TOOLEXEC_IMPORTPATH="test/main.test"

Note how the " [test/main.test]" suffixes are missing. Because of that,
when one sees TOOLEXEC_IMPORTPATH="test/main", it is ambiguous whether
the regular "test/main" package is meant, or its test variant, otherwise
known as "test/main [test/main.test]" and including foo_test.go

To fix this, we need unambiguous strings to identify the packages
involved, just like one can do with "go list -test". "go list" already
has such a field, ImportPath, which is also used when printing output
from each build "action" as seen above.

That string is not really an import path - internally, it's
load.Package.Desc, and called a "description". However, it makes sense
to be consistent with "go list -json", because it's the source of truth
for practically all tools interacting with the Go toolchain.

To keep cmd/go more consistent, "go list -f {{.ImportPath}}" now calls
Package.Desc as well, instead of having its own copy of the string
concatenation for ForTest.

Fixes #44963.

Change-Id: Ibce7fbb5549209dac50526043c0c7daa0beebc08
Reviewed-on: https://go-review.googlesource.com/c/go/+/313770
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>

cmd/dist,runtime: support cgo on openbsd/mips64

Add support for cgo on openbsd/mips64.

Fixes #43005

Change-Id: I2386204f53fa984a01a9d89f0b6c96455768f326
Reviewed-on: https://go-review.googlesource.com/c/go/+/275896
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/compile/ssa: optimize the derivable known branch of If block

When the control value of a If block is known for a particular inbound edge
because its value can be inferred from the control value of its predecessor,
then this inbound edge can be redirected to the known successor directly,
This CL optimizes this kind of cases to eliminate unnecessary comparision.

For example, the following piece of code comes from runtime.atoi,
if !neg && un > uint(maxInt) {
return 0, false
}
if neg && un > uint(maxInt)+1 {
return 0, false
}

Before this optimization, if the first "if" statement does not return, both
conditions of the second "if" statement will be checked. But obviously the
value of neg is known through the first "if" statement, and there is no need
to check neg repeatedly.

After this optimization, this redundancy check is eliminated, and the execution
logic becomes as follows.
if !neg {
if un > uint(maxInt) {
return 0, false
}
} else {
if un > uint(maxInt)+1 {
return 0, false
}
}

This CL does not bring significant performance changes, but it makes the code
structure look more reasonable.

Statistical data from tool compilecmp on Linux/amd64:
name                      old time/op       new time/op       delta
Template                        380ms ± 4%        385ms ± 3%  +1.16%  (p=0.000 n=50+49)
Unicode                         168ms ± 9%        169ms ± 9%    ~     (p=0.421 n=49+46)
GoTypes                         1.99s ± 4%        2.02s ± 4%  +1.48%  (p=0.000 n=49+49)
Compiler                        188ms ± 8%        188ms ± 9%    ~     (p=0.997 n=49+50)
SSA                             11.8s ± 2%        12.0s ± 2%  +1.24%  (p=0.000 n=48+50)
Flate                           242ms ± 6%        244ms ± 9%    ~     (p=0.307 n=46+49)
GoParser                        361ms ± 3%        366ms ± 4%  +1.23%  (p=0.000 n=48+49)
Reflect                         836ms ± 3%        842ms ± 3%  +0.70%  (p=0.004 n=48+48)
Tar                             335ms ± 3%        340ms ± 4%  +1.47%  (p=0.000 n=49+46)
XML                             432ms ± 4%        437ms ± 4%  +1.11%  (p=0.002 n=49+49)
LinkCompiler                    701ms ± 4%        704ms ± 5%    ~     (p=0.278 n=49+50)
ExternalLinkCompiler            1.83s ± 3%        1.84s ± 3%  +0.51%  (p=0.034 n=48+49)
LinkWithoutDebugCompiler        436ms ± 6%        438ms ± 6%    ~     (p=0.419 n=48+49)
[Geo mean]                      612ms             617ms       +0.84%

name                      old alloc/op      new alloc/op      delta
Template                       38.7MB ± 1%       39.1MB ± 1%  +1.19%  (p=0.000 n=50+50)
Unicode                        28.1MB ± 0%       28.1MB ± 0%  +0.20%  (p=0.000 n=49+45)
GoTypes                         168MB ± 1%        170MB ± 1%  +1.05%  (p=0.000 n=48+49)
Compiler                       23.0MB ± 1%       23.1MB ± 1%  +0.63%  (p=0.000 n=50+50)
SSA                            1.54GB ± 1%       1.55GB ± 1%  +0.85%  (p=0.000 n=50+50)
Flate                          23.6MB ± 1%       23.9MB ± 1%  +1.36%  (p=0.000 n=43+46)
GoParser                       35.0MB ± 1%       35.3MB ± 1%  +0.94%  (p=0.000 n=50+50)
Reflect                        84.7MB ± 1%       86.1MB ± 1%  +1.72%  (p=0.000 n=49+49)
Tar                            34.5MB ± 1%       34.9MB ± 1%  +1.07%  (p=0.000 n=47+48)
XML                            44.2MB ± 3%       44.6MB ± 3%  +0.70%  (p=0.003 n=50+49)
LinkCompiler                    128MB ± 0%        128MB ± 0%  +0.01%  (p=0.004 n=49+50)
ExternalLinkCompiler            120MB ± 0%        120MB ± 0%  +0.01%  (p=0.000 n=49+50)
LinkWithoutDebugCompiler       77.3MB ± 0%       77.3MB ± 0%  +0.02%  (p=0.000 n=50+50)
[Geo mean]                     69.1MB            69.6MB       +0.75%

file      before    after     Δ       %
addr2line 4049276   4051308   +2032   +0.050%
api       5248940   5248996   +56     +0.001%
asm       4868093   4868037   -56     -0.001%
buildid   2627666   2626026   -1640   -0.062%
cgo       4614432   4615040   +608    +0.013%
compile   23298888  23301267  +2379   +0.010%
cover     4591609   4591161   -448    -0.010%
dist      3449638   3450254   +616    +0.018%
doc       3925667   3926363   +696    +0.018%
fix       3322936   3323464   +528    +0.016%
link      6628632   6629560   +928    +0.014%
nm        3991753   3996497   +4744   +0.119%
objdump   4396119   4395615   -504    -0.011%
pack      2399719   2399535   -184    -0.008%
pprof     13616418  13622866  +6448   +0.047%
test2json 2646121   2646081   -40     -0.002%
trace     10233087  10226359  -6728   -0.066%
vet       7117994   7121066   +3072   +0.043%
total     111026988 111039495 +12507  +0.011%

On linux arm64:
name                      old time/op       new time/op       delta
Template                        284ms ± 1%        286ms ± 1%  +0.70%  (p=0.000 n=49+50)
Unicode                         125ms ± 3%        125ms ± 2%    ~     (p=0.548 n=50+50)
GoTypes                         1.69s ± 1%        1.71s ± 1%  +1.02%  (p=0.000 n=49+49)
Compiler                        125ms ± 1%        124ms ± 2%  -0.35%  (p=0.020 n=50+50)
SSA                             12.7s ± 1%        12.8s ± 1%  +1.21%  (p=0.000 n=49+49)
Flate                           172ms ± 1%        173ms ± 1%  +0.20%  (p=0.047 n=50+50)
GoParser                        265ms ± 1%        266ms ± 1%  +0.64%  (p=0.000 n=50+50)
Reflect                         651ms ± 1%        650ms ± 1%    ~     (p=0.079 n=48+48)
Tar                             246ms ± 1%        246ms ± 1%    ~     (p=0.202 n=50+46)
XML                             328ms ± 1%        332ms ± 1%  +1.28%  (p=0.000 n=50+49)
LinkCompiler                    600ms ± 1%        599ms ± 1%    ~     (p=0.264 n=50+50)
ExternalLinkCompiler            1.88s ± 1%        1.90s ± 0%  +1.36%  (p=0.000 n=50+50)
LinkWithoutDebugCompiler        365ms ± 1%        365ms ± 1%    ~     (p=0.602 n=50+46)
[Geo mean]                      490ms             492ms       +0.47%

name                      old alloc/op      new alloc/op      delta
Template                       38.8MB ± 1%       39.1MB ± 1%  +0.92%  (p=0.000 n=44+42)
Unicode                        28.4MB ± 0%       28.4MB ± 0%  +0.22%  (p=0.000 n=44+45)
GoTypes                         169MB ± 1%        171MB ± 1%  +1.12%  (p=0.000 n=50+50)
Compiler                       23.2MB ± 1%       23.3MB ± 1%  +0.56%  (p=0.000 n=42+43)
SSA                            1.55GB ± 0%       1.56GB ± 0%  +0.91%  (p=0.000 n=48+49)
Flate                          23.7MB ± 2%       24.0MB ± 1%  +1.20%  (p=0.000 n=50+50)
GoParser                       35.3MB ± 1%       35.6MB ± 1%  +0.88%  (p=0.000 n=50+50)
Reflect                        85.0MB ± 0%       86.5MB ± 0%  +1.70%  (p=0.000 n=49+48)
Tar                            34.5MB ± 1%       34.9MB ± 1%  +1.03%  (p=0.000 n=47+50)
XML                            43.8MB ± 2%       44.0MB ± 0%  +0.41%  (p=0.002 n=49+38)
LinkCompiler                    136MB ± 0%        136MB ± 0%  +0.01%  (p=0.006 n=50+49)
ExternalLinkCompiler            127MB ± 0%        127MB ± 0%  +0.02%  (p=0.000 n=49+50)
LinkWithoutDebugCompiler       84.1MB ± 0%       84.1MB ± 0%    ~     (p=0.534 n=50+50)
[Geo mean]                     70.4MB            70.9MB       +0.69%

file      before    after     Δ       %
addr2line 4006004   4004556   -1448   -0.036%
api       5029716   5028828   -888    -0.018%
asm       4936863   4934943   -1920   -0.039%
buildid   2594947   2594099   -848    -0.033%
cgo       4399702   4399502   -200    -0.005%
compile   22233139  22230486  -2653   -0.012%
cover     4443681   4443881   +200    +0.005%
dist      3365902   3365486   -416    -0.012%
doc       3776175   3776151   -24     -0.001%
fix       3218624   3218600   -24     -0.001%
link      6365001   6361409   -3592   -0.056%
nm        3923345   3923065   -280    -0.007%
objdump   4295473   4296673   +1200   +0.028%
pack      2390561   2389393   -1168   -0.049%
pprof     12866419  12865115  -1304   -0.010%
test2json 2587113   2585561   -1552   -0.060%
trace     9609814   9610846   +1032   +0.011%
vet       6790272   6789760   -512    -0.008%
total     106832751 106818354 -14397  -0.013%

Update: #37608

Change-Id: I2831238b12e3af5aef2261f64f804bf0a8b43f86
Reviewed-on: https://go-review.googlesource.com/c/go/+/244737
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/asm: add check for register and shift/extension combination on arm64

The current code lacks a check on whether the register and shift/extension
combination is valid, for example the follow instructions also compiles.
ADD     F1<<1, R1, R3
ADD     V1<<1, R1, R3
MOVW    (R9)(F8.SXTW<<2), R19
VST1    R4.D[1], (R0)

Actually only general registers can perform shift operations, and element
and arrangement extensions are only applicable to vector registers. This
CL adds a check for the register and shift/extension combination on arm64.

Change-Id: I93dd9343e92a66899cba8eaf4e0ac5430e94692b
Reviewed-on: https://go-review.googlesource.com/c/go/+/312571
Trust: eric fang <eric.fang@arm.com>
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/internal/obj/arm64: fix the wrong error message of out-of-range checking

The error message of checking whether the offset value of load/store
instruction is out of range is wrong. The right range is [-256, 255], not
[-255, 254]. The CL fixes it.

Change-Id: Ia342957f1f6bcec65eceb45944221d3972641bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/313891
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>

cmd/compile: fix typechecking logical operators panic with non-boolean operand

In CL 255899, we added code to make clearer error when non-bool used
as operand to logical operators. The code is safe, because node type
is guaranteed to be non-nil.

In CL 279442, we refactored typechecking arith, including moving
typechecking logical operators to separate case. Now we have to
explicitly check if operand type is not nil, because calling Expr can
set operand type nil for non-bool operands.

Fixes #45804

Change-Id: Ie2b6e18f65c0614a803b343f60e78ee1d660bbeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/314209
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

cmd/link: disable plugin support if cgo is disabled

Functional plugin support requires cgo to be enabled. Disable
it if the environment has disabled cgo.

This prevents unexpected linker failures when linking large
binaries with cgo disabled which use the plugin package.

Fixes #45564

Change-Id: Ib71f0e089f7373b7b3e3cd53da3612291e7bc473
Reviewed-on: https://go-review.googlesource.com/c/go/+/314449
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>

go/types: factor out index/slice expr handling

This is a port of CL 308370 to go/types. There are some differences in
the index checking code, but the methodology for moving the code was the
same: replace `goto Error` with `x.mode = invalid; return`.

Change-Id: I880f577a7720e6ad8a5b096207001fcf7620396d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312095
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

testing: document that TestMain can be used with benchmarks

Fixes #45764

Change-Id: Ie6c18bb5c20721c2ffa8b4a9cf9f97cdc665a450
GitHub-Last-Rev: 8bcea7e0ff60227c05437b372c0a3546e151af31
GitHub-Pull-Request: golang/go#45808
Reviewed-on: https://go-review.googlesource.com/c/go/+/314349
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>

cmd/go/internal/modload: treat \ as a path separator instead of a shell special character

According to the code comment, \ should be treated as a path separator.
See fileNameOK in golang.org/x/mod/module/module.go.

Change-Id: I05e05246005191ecccfecf46848aba5cb1359956
Reviewed-on: https://go-review.googlesource.com/c/go/+/310429
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Robert Findley <rfindley@google.com>

cmd/compile/internal/walk: merge operations

Change-Id: I018872da519dfb4aa6c252ea28fc09289c2d9711
GitHub-Last-Rev: 5969776197003cae317f6b45f88ac4ced10beaf3
GitHub-Pull-Request: golang/go#45795
Reviewed-on: https://go-review.googlesource.com/c/go/+/313550
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>

time: increase slop for TestTicker

Also sleep a bit each time it fails, in case the system is overloaded.

Fixes #37332

Change-Id: Iabf3d0a27b5834c1e2a87c826b6206146b4f62c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/313849
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

cmd/compile: fix nongeneric closures in generic functions

Ensure that formal parameter Names are correctly copied and marked
with the correct Curfn. We need to ensure this even when the underlying
closure has no type parameters.

(Aside: it is strange that the types of things contain formal
parameter names that need to be copied. Maybe that's an underlying
larger problem that needs to be fixed.)

Fixes #45738

Change-Id: Ia13d69eea992ff7080bd44065115bc52eb624e73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313652
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>

cmd/go: use a real Go version in the go.mod files in TestScript/mod_readonly

For some reason, the go.mod file added to this test in CL 147281 lists
'go 1.20' instead of the version that was actually current when the
go.mod file was added.

That causes the test's behavior to change under lazy loading, because
1.20 is above the threshold to trigger lazy-loading invariants (1.17).

For #36460

Change-Id: I92400996cb051ab30e99bfffafd91ff32a1e7087
Reviewed-on: https://go-review.googlesource.com/c/go/+/314049
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>

syscall: move TestForegroundSignal create call out of goroutine

That way the skip takes effect.

Also ignore the result of calling TIOCSPGRP when cleaing up TestForeground.
It has started to fail for some reason, and the result doesn't matter.

Also call TIOCSPGRP to clean up in TestForegroundSignal.

For #37217

Change-Id: I2e4282d7d91ad9a198eeb12cef01c2214c2a98c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/314271
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

go: various minor cleanups with the help of Goland

    • fix some typos
    • remove superfluous conversions/parentheses
    • remove superfluous nil checks

Change-Id: I428bf6a7be551b79270567047878c3076dd6f2ff
GitHub-Last-Rev: 3b1c7573cfdf89ac184fd6ae44bca4be78b0cd64
GitHub-Pull-Request: golang/go#45799
Reviewed-on: https://go-review.googlesource.com/c/go/+/314069
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>

runtime/pprof: fix block profile bias

Block profiles were biased towards infrequent long events over frequent
short events. This fix corrects the bias by aggregating shorter events
as longer but less frequent in the profiles. As a result their
cumulative duration will be accurately represented in the profile
without skewing their sample mean (duration/count).

Credit to @dvyukov for suggesting to adjust the count in the
saveblockevent function.

Fixes #44192.

Change-Id: I71a99d7f6ebdb2d484d44890a2517863cceb4004
Reviewed-on: https://go-review.googlesource.com/c/go/+/299991
Trust: Michael Pratt <mpratt@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>

cmd/go/internal/load: treat packages with errors as potentially main packages

If a package declares 'package main' but for some reason we fail to
read its name (for example, due to a permission or checksum error),
we may be tempted to drop the package from the output of
mainPackagesOnly. However, that leads to a confusing
"no packages loaded from …" error message.

Instead, we will treat packages with errors as potentially-main
packages, and print the error. At least if we print why the package is
broken, the user will understand that the weird behavior is due to the
broken package rather than, say, a typo on their part in the command
arguments.

Updates #42088
For #36460

Change-Id: I033c0d28ac7d105d9df3ba5f9327e5c0c2a29954
Reviewed-on: https://go-review.googlesource.com/c/go/+/314050
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>

cmd/go: show warnings about symlinks only for patterns containing ...

Go commands show a warning message any time a pattern is expanded and a
symlink to a directory is encountered. For monorepo with non Go projects
using symlinks underneath, the output of go commands could be spammed by
this warning.

This commit includes the behavior change to only print this warning when
there's a pattern containing ... .

Fixes #35941

Change-Id: I094da2628bcd47b86fee8c6529d1066aa013a43b
Reviewed-on: https://go-review.googlesource.com/c/go/+/311890
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Michael Matloob <matloob@golang.org>

syscall: restore nosplit for ptrace1 on Darwin

ptrace1 must be nosplit because it is called from
forAndExecInChild. It was marked nosplit in the generated code
but not in the generator. CL 313230 regenerated the code and lost
the nosplit mark. This CL restores it.

Change-Id: I4645d83650f1818bed3cb650328bba97074b6b2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314249
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

go/scanner: optimize scanIdentifier

While profiling parsing, I noticed that scanIdentifier was extremely
hot, and could be optimized: it is responsible for a significant
fraction of scanning and had a lot of unnecessary branching, bounds
checks, and function calls.

This CL implements some of those optimizations, while trying to strike a
balance between optimization and readability. It achieves this by
optimizing for the common case of ASCII identifiers, falling back on the
slower scan when encountering the first non-ASCII character.

Benchmark results:

name                               old time/op    new time/op    delta
Scan-12                              16.9µs ± 4%    15.8µs ± 5%   -6.92%  (p=0.000 n=20+18)
ScanFiles/go/types/expr.go-12         793µs ± 4%     672µs ± 6%  -15.23%  (p=0.000 n=20+20)
ScanFiles/go/parser/parser.go-12     1.08ms ± 6%    0.90ms ± 4%  -16.68%  (p=0.000 n=20+20)
ScanFiles/net/http/server.go-12      1.44ms ± 4%    1.23ms ± 5%  -14.58%  (p=0.000 n=18+20)
ScanFiles/go/scanner/errors.go-12    40.7µs ± 2%    32.6µs ± 3%  -20.01%  (p=0.000 n=19+20)

Change-Id: If78380004248e3ea75cfc78eb7f38f528124dced
Reviewed-on: https://go-review.googlesource.com/c/go/+/308611
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

strconv: remove unused extfloat (Grisu3) ftoa code

Change-Id: Ie8995362f9e8072b173d08820330d2d1e512aa71
Reviewed-on: https://go-review.googlesource.com/c/go/+/314029
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>

cmd/compile: fix handling of ir.CurFunc during stenciling

The transform functions (specifically transformArgs, which is used from
transformCall/transformReturn) require that ir.CurFunc is set correctly.
Since transformCall() is used on the call of an instantiated generic
function, we need to set ir.CurFunc correctly in stencil(). Also,
correctly save/restore ir.CurFunc in genericSubst().

Without this fix, ir.CurFunc can be nil when we call TransformCall()
from stencil(), which leads to some temp variables being added
incorrectly to ir.TodoFunc (which leads to the fatal panic in the
issue).

Fixes #45722

Change-Id: Iddf4a67d28f2100dde8cde5dbc9ca1e00dad6089
Reviewed-on: https://go-review.googlesource.com/c/go/+/313869
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>

bits: use same expression with system bit size

Change-Id: Ibce07f8f36f7c64f7022ce656f8efbec5dff3f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/313829
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>

go/scanner: improve variety in benchmarks for file scanning

BenchmarkScanFile was scanning scanner.go, which makes comparison
difficult for a CL modifying that file. That file is also is not
necessarily representative syntax.

Add a few additional files as subtests to provide a larger variety of
metrics.

Change-Id: Ib78303c2546debd84a0b5478ae438ba891d9e6e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/308610
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

go/parser: add benchmarks for syntax-only parsing and object resolution

Change-Id: I73d1b2d18ab4051443d66c60df493d1163d0ba3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/306150
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

os: don't check non-nil err twice in Symlink on windows

Change-Id: I398d324723025b559fdca783fc334de9be68f2d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/314030
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>

runtime/metrics: add tiny allocs metric

Currently tiny allocations are not represented in either MemStats or
runtime/metrics, but they're represented in MemStats (indirectly) via
Mallocs. Add them to runtime/metrics by first merging
memstats.tinyallocs into consistentHeapStats (just for simplicity; it's
monotonic so metrics would still be self-consistent if we just read it
atomically) and then adding /gc/heap/tiny/allocs:objects to the list of
supported metrics.

Change-Id: Ie478006ab942a3e877b4a79065ffa43569722f3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312909
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>

syscall: restore signal mask after setting foreground process group

Fixes #37217

Change-Id: I0151bb77fc4c4552d1b19c31d784943b72f84b80
Reviewed-on: https://go-review.googlesource.com/c/go/+/313653
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>

go/types: don't panic when checking a ListExpr in exprInternal

As an alternative to CL 312149, add a catch-all error message in
exprInternal when encountering a ListExpr, rather than panicking.

We still might want something like CL 312149 to improve the error
message or recovery from bad indexing.

Change-Id: I865f7cc4eefa4a3b7bd8f3100df96d0144e1712f
Reviewed-on: https://go-review.googlesource.com/c/go/+/313909
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

cmd/link: enforce larger alignment on split ppc64 text sections

When laying out, we lazily increase the alignment for text sections
as symbols are found requiring more. This works if the start of
the virtual address (VA) for the section is greater than or equal
to the alignment required by any symbols placed in this section.

The minimum alignment of the section is only known after all
symbols are placed. The starting VA of this section is adjusted
upwards in ld.(*Link).address to meet the requested alignment.

This is a problem if the starting VA of the text section is not
already aligned. This can happen when the final symbol placed
into the previous section results in an insufficiently aligned
start VA of the next text section.

To workaround this, additional text sections are split, and both
the starting VA, and alignment of the section are aligned up to
match the known worst case alignment.

64B is chosen as the worst case alignment for all ppc64 targets,
as it will respect PCALIGN and eventually prefixed instructions
which will be introduced in the future.

Likewise, the xcoff size calculations need to be improved to
handle padding bytes when function symbols have been aligned.
This is done by tracking the largest valid VA offset encountered
when placing symbols.

Change-Id: Iefef09a1ee7c963fb8dfce2288a084a95cb77fca
Reviewed-on: https://go-review.googlesource.com/c/go/+/307431
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>

cmd/internal/obj: refactor ppc64 address relocation code generation

The code for generating a long constant versus generating an address
(either via a relocation, or known offset) should be handled in the
same place.

Resolve this by classifying memory arguments as C_LACON (a long
address constant) instead of C_LCON (a long constant).

Likewise, reorder AMOVD/AMOVW optab entries to keep similar
classifications near each other. An extra optab entry for
DWORD is also added to continue handling C_LACON arguments
correctly.

Change-Id: I5ce28400492a071f615125a9b8d260826f1600d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/312296
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>

runtime: replace --buildmode with -buildmode in tests

While debugging issue #45638, I discovered that some tests were using
--buildmode command line parameter instead of -buildmode.

The --buildmode parameter is handled properly by the flag package - it
is read as -buildmode. But we should correct code anyway.

Updates #45638

Change-Id: I75cf95c7d11dcdf4aeccf568b2dea77bd8942352
Reviewed-on: https://go-review.googlesource.com/c/go/+/313351
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

runtime: add missing import "C" in TestLibraryCtrlHandler

CL 211139 added TestLibraryCtrlHandler. But the CL left out import "C"
line in the test file that is supposed to be build with Cgo.

While debugging issue #45638, I discovered that the DLL built during
TestLibraryCtrlHandler does not have Dummy function. Adding import "C"
makes Dummy function appear in DLL function list.

TestLibraryCtrlHandler does not actually calls Dummy function. So I
don't see how this change affects issue #45638, but still let's make
this code correct.

Updates #45638

Change-Id: Ibab8fed29ef2ae446d0815842cf0bd040a5fb943
Reviewed-on: https://go-review.googlesource.com/c/go/+/313350
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

cmd/compile: tighten exportWriter.qualifiedIdent signature

It always takes an *ir.Name and would panic given anything else
anyway, so tighten the signature to match.

Change-Id: I44fec5c5cc6d7f0b9c59eb91c9f9633137485360
Reviewed-on: https://go-review.googlesource.com/c/go/+/314009
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>

doc: change <a/> to </a> in spec

Change-Id: I21d0ee83c9204d51c587bd944209df2232b460ad
GitHub-Last-Rev: 47fab8dc582baaab5f5cd58a1d53f1c24604c769
GitHub-Pull-Request: golang/go#45771
Reviewed-on: https://go-review.googlesource.com/c/go/+/313449
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

cmd/go/internal/modload: clean up error reporting

• Consolidate 'if ld.AllowErrors' conditions into an 'ld.errorf'
  method.

• Rename SilenceErrors to SilencePackageErrors and clarify its
  documentation. (There is currently no way to silence errors in the
  module graph. Perhaps we should add one, but for now let's at least
  clarify the existing behavior.)

• Move 'tidy -v' verbose logging into LoadPackages, where other
  logging happens.

• Make checkMultiplePaths a loader method (since it only matters
  during package loading anyway).

• Check package and module-graph errors in loadFromRoots instead of
  LoadPackages. These checks were previously omitted on the
  ImportFromFiles path, which seems likely to be a bug. (We now
  suppress package errors explicitly in ImportFromFiles, which at
  least makes the bug more explicit.)

This somewhat simplifies the code structure in preparation for
the lazy-mode tidy implementation.

For #36460

Change-Id: I3ce3586c6934989d5194f00f99e7cc4423cf767f
Reviewed-on: https://go-review.googlesource.com/c/go/+/313229
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>

cmd/go: add tests for convergence in 'go mod tidy'

For #36460

Change-Id: I40194bb1ebab77459e5c9d43bdac4d9c1b826ac2
Reviewed-on: https://go-review.googlesource.com/c/go/+/312449
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>

cmd/compile: add more doc for Name.Defn

As discussion in CL 313289, Name.Defn is also be set for variables
declared in type switch, or name function.

Change-Id: I3deb3d79fca269356e4432b77df7c7720a523674
Reviewed-on: https://go-review.googlesource.com/c/go/+/313889
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>

go/types: walk all imports when determining package name ambiguity

CL 209578 disambiguated paths among imported packages, but as
demonstrated in #43119, formatted types may reference packages that are
not directly imported.

Fix this by recursively walking all imports to determine whether there
is any ambiguity in the import graph. This might result in
over-qualification of names, but it is straightforward and should
eliminate any ambiguity.

In general this should be fine, but might introduce risk of infinite
recursion in the case of an importer bug, or performance problems for
very large import graphs. Mitigate the former by tracking seen packages,
and the latter by only walking the import graph once an error has been
produced.

Fixes #43119

Change-Id: If874f050ad0e808db8e354c2ffc88bc6d64fd277
Reviewed-on: https://go-review.googlesource.com/c/go/+/313035
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

cmd/compile: fix wrong package path for unsafe.Pointer

It's not a predeclared type, but a type defined in "unsafe" package.

Fixes #44830

Change-Id: If39815b1070059b608be8231dfac9b7f3307cb15
Reviewed-on: https://go-review.googlesource.com/c/go/+/313349
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

syscall: on linux use accept4 in Accept, fall back to accept

Android seems to block the accept syscall in newer versions. Use accept4
instead on kernel versions that support it (Linux 2.6.28 and newer) and
fall back to accept on ENOSYS.

Fixes #45767

Change-Id: If190ace0e0213207fdaf6eeb79a5543ef18456de
Reviewed-on: https://go-review.googlesource.com/c/go/+/313769
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/compile/internal/types2: respect IgnoreFuncBodies for function literals

Updates #45783.

Change-Id: Id552a60f262e2da62125acd6aec0901a82f5a29a
Reviewed-on: https://go-review.googlesource.com/c/go/+/313650
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/compile: workaround inlining of closures with type switches

Within clovar, n.Defn can also be *ir.TypeSwitchGuard. The proper fix
here would be to populate m.Defn and have it filled in too, but we
already leave it nil in inlvar. So for consistency, this CL does the
same in clovar too.

Eventually inl.go should be rewritten to fully respect IR invariants.

Fixes #45743.

Change-Id: I8b38e5d8b2329ad242de97670f2141f713954d28
Reviewed-on: https://go-review.googlesource.com/c/go/+/313289
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>

cmd/go/internal/modload: use (*loadPkg).mod only to indicate the module from which the package was loaded

The (*loadPkg).mod field normally indicates the module from which the
package was loaded. However, if the package was missing, we previously
used the mod field to instead store the module from which we intend to
load the package next time around.

That sort of dual use makes the semantics (and synchronization) of the
mod field much more complex to reason about. For example, it would be
nice to have the invariant that the mod field is always one of the
modules in the overall build list, or one of the modules selected in
the overall module graph. Similarly, it would be nice to have the
invariant that the version indicated by the mod field can coexist with
(without upgrading) all of the other versions indicated in the mod
fields of other packages.

This repurposing of the mod field appears to be solely in the service
of storing the module when resolving missing imports. To keep
conceptually-separate fields separate, I have changed
resolveMissingImports to store a slice of package–module pairs,
instead of just packages that need to be revisited.

This may increase allocation pressure slightly if we have many
unresolved packages, but most packages are not unresolved, and it
seems worth the cost to use a little extra memory if it means we can
reason more clearly about the (quite complex) behaviors of the module
loader.

For #36460

Change-Id: Ic434df0f38185c6e9e892c5e9ba9ff53b3efe01f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312930
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>

Revert "sync: improve sync.Pool object stealing"

This reverts CL 303949.

Reason for revert: broke linux-arm-aws TryBots.

Change-Id: Ib44949df70520cdabff857846be0d2221403d2f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/313630
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

runtime: use abi.FuncPCABI0 for libc syscall wrappers

In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.

As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.

Change-Id: I50645af74883e2d5dfcd67a5e8c739222c6f645b
Reviewed-on: https://go-review.googlesource.com/c/go/+/313250
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

runtime: fix offset in comment

Change-Id: I2770195cb53220948081a6265f891ef064e4f763
Reviewed-on: https://go-review.googlesource.com/c/go/+/313629
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

runtime: fix scavenge min fraction constant floor division

Currently there's a minor bug where the constant for the min fraction of
time spent scavenging is rounded down to zero. I don't think this
affects anything in practice because this case is exceedingly rare and
extreme, but currently it doesn't properly prevent the pacing parameters
from getting out of hand in these extreme cases.

Fixes #44036.

Change-Id: I7de644ab0ecac33765c337a736482a0966882780
Reviewed-on: https://go-review.googlesource.com/c/go/+/313249
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/go: don't add generated SWIG C++ files to CompiledGoFiles

Also include SWIG C++ files in cgo hash.

For #28749
Fixes #37098

Change-Id: I6d912db2788200c2abdf328e382d4fbefda0a9ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/313131
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

sync: improve sync.Pool object stealing

This CL provide abilty to randomly select P to steal object from its
shared queue. In order to provide such ability randomOrder structure
was copied from runtime/proc.go.
It should reduce contention in firsts Ps and improve balance of object
stealing across all Ps. Also, the patch provides new benchmark
PoolStarvation which force Ps to steal objects.
Benchmarks:
name                old time/op     new time/op     delta
Pool-8                 2.16ns ±14%     2.14ns ±16%    ~     (p=0.425 n=10+10)
PoolOverflow-8          489ns ± 0%      489ns ± 0%    ~     (p=0.719 n=9+10)
PoolStarvation-8       7.00µs ± 4%     6.59µs ± 2%  -5.86%  (p=0.000 n=10+10)
PoolSTW-8              15.1µs ± 1%     15.2µs ± 1%  +0.99%  (p=0.001 n=10+10)
PoolExpensiveNew-8     1.25ms ±10%     1.31ms ± 9%    ~     (p=0.143 n=10+10)
[Geo mean]             2.68µs          2.68µs       -0.28%

name                old p50-ns/STW  new p50-ns/STW  delta
PoolSTW-8               15.0k ± 1%      15.1k ± 1%  +0.92%  (p=0.000 n=10+10)

name                old p95-ns/STW  new p95-ns/STW  delta
PoolSTW-8               16.2k ± 3%      16.4k ± 2%    ~     (p=0.143 n=10+10)

name                old GCs/op      new GCs/op      delta
PoolExpensiveNew-8       0.29 ± 2%       0.30 ± 1%  +2.84%  (p=0.000 n=8+10)

name                old New/op      new New/op      delta
PoolExpensiveNew-8       8.07 ±11%       8.49 ±10%    ~     (p=0.123 n=10+10)

Change-Id: I3ca1d0bf1f358b1148c58e64740fb2d5bfc0bc02
Reviewed-on: https://go-review.googlesource.com/c/go/+/303949
Reviewed-by: David Chase <drchase@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>

syscall, etc.: use abi.FuncPCABI0 for libc syscall wrappers

In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.

As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.

Do it on OpenBSD as well, as OpenBSD and Darwin share code
generator.

Change-Id: I408120795f7fc826637c867394248f8f373906bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/313230
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

cmd/compile: spos handling fixes to improve prolog debuggability

With the new register ABI, the compiler sometimes introduces spills of
argument registers in function prologs; depending on the positions
assigned to these spills and whether they have the IsStmt flag set,
this can degrade the debugging experience. For example, in this
function from one of the Delve regression tests:

L13:  func foo((eface interface{}) {
L14: if eface != nil {
L15: n++
L16: }
L17   }

we wind up with a prolog containing two spill instructions, the first
with line 14, the second with line 13.  The end result for the user
is that if you set a breakpoint in foo and run to it, then do "step",
execution will initially stop at L14, then jump "backwards" to L13.

The root of the problem in this case is that an ArgIntReg pseudo-op is
introduced during expand calls, then promoted (due to lowering) to a
first-class statement (IsStmt flag set), which in turn causes
downstream handling to propagate its position to the first of the register
spills in the prolog.

To help improve things, this patch changes the rewriter to avoid
moving an "IsStmt" flag from a deleted/replaced instruction to an
Arg{Int,Float}Reg value, and adds Arg{Int,Float}Reg to the list of
opcodes not suitable for selection as statement boundaries, and
suppresses generation of additional register spills in defframe() when
optimization is disabled (since in that case things will get spilled
in any case).

This is not a comprehensive/complete fix; there are still cases where
we get less-than-ideal source position markers (ex: issue 45680).

Updates #40724.

Change-Id: Ica8bba4940b2291bef6b5d95ff0cfd84412a2d40
Reviewed-on: https://go-review.googlesource.com/c/go/+/312989
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/compile: extend GOSSAFUNC match to well-formed package suffix match.

e.g., LeadingZeros, bits.LeadingZeros, math/bits.LeadingZeros
but not its.LeadingZeros

Change-Id: Ib9a57e4db0af03c55bf5b5027aa6f8a5a84f2134
Reviewed-on: https://go-review.googlesource.com/c/go/+/312291
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

runtime: simplify TestSelectStackAdjust

Currently this test attempts to trigger a concurrent GC in a very
indirect way, but the way it does so is extremely error-prone. This test
is virtually always prone to flaking based on test order. For example if
the test that executed immediately before this one made a big heap but
didn't clean it up, then this test could easily fail to trigger a GC.
I was able to prove this with a small reproducer.

This roundabout way of triggering a GC is also way overkill for this
test. It just wants to get goroutines in a select and shrink their
stacks. Every GC will schedule a stack for shrinking if it can.

Replace all the complicated machinery with a single runtime.GC call.
I've confirmed that the test consistently triggers a stack shrink,
noting that both shrinkstack's copystack call is made and that
syncadjustsudogs (the relevant function that's being indirectly tested)
are both called.

Fixes #44610.

Change-Id: Ib1c091e0d1475bf6c596f56dc9b85eaea366fc73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>

cmd/dist: enable cgo on windows/arm64

Change-Id: I4d470e2af1bfb4fba004a6f3e00a163a575593da
Reviewed-on: https://go-review.googlesource.com/c/go/+/312047
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

misc/cgo/testso, misc/cgo/testsovar: fix for Windows

At least in mingw-clang it is not permitted to just name a .dll
on the command line. You must name the corresponding import
library instead, even though the dll is used when the executable
is run.

This fixes misc/cgo/testso and misc/cgo/testsovar on windows/arm64.

Change-Id: I516b6ccba2fe3a9ee2c01e710a71850c4df8522f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312046
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

all: do not test internal linking on windows/arm64

(It doesn't work and isn't used by default.)

Change-Id: I90118d889bd963471f0915d8183502b55bd9dbf2
Reviewed-on: https://go-review.googlesource.com/c/go/+/312045
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/link: implement windows/arm64 external linking

Change-Id: Ia73309ec7013138b37028e669d7ae5eac81126e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/312044
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

runtime/testdata: fix testprogcgo for windows/arm64

Our toolchain does not like -mnop-fun-dllimport.

Change-Id: Iaaee01fe0f4b0959406a35eb13aefa390116b483
Reviewed-on: https://go-review.googlesource.com/c/go/+/312043
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

runtime: fix windows/arm64 callbackasm1 for frame pointer hack

Fixes the previously failing TestStdcallAndCDeclCallbacks
for the 9+ argument case.

The last time this code passed, the invisible frame pointer
below SP was apparently not enabled on windows/arm64.

Change-Id: Ifc3064e894b2f39d6410f3be51c17309ebab08a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/312042
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

runtime: add windows/arm64 cgo-linking code

This code is needed for use with cgo proper
(as opposed to hand-written DLL calls, which
we always use but only exercise cgo execution,
not cgo linking).

Change-Id: Iddc31d9c1c924d83d032b80dca65ddfda6624046
Reviewed-on: https://go-review.googlesource.com/c/go/+/312041
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/link: force external link for windows/arm64 cgo binaries

Change-Id: I833cac61125513fde4b93ebf14da8bab88908eab
Reviewed-on: https://go-review.googlesource.com/c/go/+/312040
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/link: expand PE constants and fix doc URL

Change-Id: Ie3492b925f6d12430ce05e7d727e739a62f201e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/312038
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/link: fix PE emitRelocations for >4GB base address

Change-Id: I1dda31bb1efa177159e4e7b4c9c9cc615e2fdc0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/312037
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/link: make Loader.SymName not crash

Even if not presented with a valid symbol, recover gracefully,
so that debug prints do not crash.

Change-Id: I06bbe4bec5f90b79b4830e772a7fc3d7c919df1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/312036
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/link: count relocations better

Change-Id: Ie188abeb0194bf266d38c9bd0dda4b8f48934697
Reviewed-on: https://go-review.googlesource.com/c/go/+/312035
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/link: deal with no constructors

Change-Id: I6ed153b780c70fa90822e4daa5749478ac43afca
Reviewed-on: https://go-review.googlesource.com/c/go/+/312034
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/link: sort the pclntab relocations

llvm-mingw's lld produces an invalid windows/arm64 executable
when presented with relocations that are out of order
(the relocation for each function is emitted for two different
locations, so we end up with two sorted streams roughly
interlaced, not one sorted stream).

Sorting should not break other systems, so sort always.

Change-Id: Ic9a95e7145881db5984cbda442f27b0cc24748fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/312033
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/link: fix PE section attributes for windows/arm64

The clang-mingw toolchain on windows/arm64 expects
.text to NOT be listed as containing initialized data and
.dwarf* to be listed as  containing initialized data.
Neither is true today, resulting in the go .text and .dwarf*
not being merged with the system .text and .dwarf*.
Having multiple .text and .dwarf* sections confuses all
kinds of tools.

Change-Id: I1b9832804c5f5d594bf19e8ee0a5ed31bc1d381d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312032
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

debug/dwarf: skip over zero-length compilation units

DWARF sections generated by mingw-clang seem to include these
(not often - only one out of many in the binary that I am looking at).
Skipping over them, everything parses correctly.

This makes TestDefaultLinkerDWARF pass on windows/arm64.

Change-Id: Ie4a7daa1423f51cbc8c4aac88b1d27c3b52ee880
Reviewed-on: https://go-review.googlesource.com/c/go/+/312031
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/asm, cmd/link: use full objabi header

The cmd/link check of the objabi header was a bit lax because
historically the assembler has not included the full version string.
And the assembler didn't do that because it didn't have access to it:
that was buried inside the compiler.

But now that we have cmd/internal/objabi, all the tools have full
access to the expected string, and they can use it, which simplifies
the cmd/link consistency check.

Do that.

Change-Id: I33bd2f9d36c373cc3c32ff02ec6368365088b011
Reviewed-on: https://go-review.googlesource.com/c/go/+/312030
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

misc/cgo/test: do not redeclare exported Go functions

An exported Go function like

//export F
func F() {}

gets declared in _cgo_export.h as something like

extern void F(void);

The exact declaration varies by operating system.
In particular, Windows adds __declspec(dllimport).

Clang on Windows/ARM64 rejects code that contains
conflicting declarations for F, like:

extern void F(void);
extern void __declspec(dllimport) F(void);

This means that F must not be declared separately from _cgo_export.h:
any code that wants to refer to F must use #include "_cgo_export.h".

Unfortunately, the cgo prologue itself (the commented code before import "C")
cannot include "_cgo_export.h", because that file is itself produced from the
cgo Go sources and therefore cannot be a dependency of the cgo Go sources.

This CL rewrites misc/cgo/test to avoid redeclaring exported functions.
Most of the time, this is not a significant problem: just move the code
that needs the header into a .c file, perhaps with a wrapper exposed
to the cgo Go sources.

The one case that is potentially problematic is f7665, which is part of
the test for golang.org/issue/7665. That bug report explicitly identified
a bug in referring to the C name for an exported function in the same
Go source file as it was exported function. That is now impossible,
at least on Windows/ARM64, so the test is modified a bit and possibly
does not test what the original bug was. But the original bug should
be long gone: that part of the compiler has been rewritten.

Change-Id: I0d14d9336632f0e5e3db4273d9d32ef2cca0298d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312029
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/compile, internal/abi: add FuncPCABIxxx intrinsics

When ABI wrappers are used, there are cases where in Go code we
need the PC of the defined function instead of the ABI wrapper.
Currently we work around this by define such functions as
ABIInternal, even if they do not actually follow the internal ABI.

This CL introduces internal/abi.FuncPCABIxxx functions as compiler
intrinsics, which return the underlying defined function's entry
PC if the argument is a direct reference of a function of the
expected ABI, and reject it if it is of a different ABI.

As a proof of concept, change runtime.goexit back to ABI0 and use
internal/abi.FuncPCABI0 to retrieve its PC.

Updates #44065.

Change-Id: I02286f0f9d99e6a3090f9e8169dbafc6804a2da6
Reviewed-on: https://go-review.googlesource.com/c/go/+/304232
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

cmd/compile: generalize fix for lvalue-init evaluation

The previous fix to ensure early evaluation of lvalue-init statements
(CL 312632) added it after we'd already peeled away any array-OINDEX
expressions. But those might have init statements too, so we need to
do this earlier actually and perhaps more than once.

Longer term, lvalue expressions shouldn't have init statements anyway.
But rsc and I both spent a while looking into this earlier in the dev
cycle and couldn't come up with anything reasonable.

Fixes #45706.

Change-Id: I2d19c5ba421b3f019c62eec45774c84cf04b30ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/313011
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/go/internal/modload: remove the addedModuleFor map

At one point this map checked for infinite loops during package iteration.
The last write to the map was mistakenly removed in CL 251445.

However, looking at the code before that change, the map-based
termination strategy was never quite right to begin with: it checked
whether we had ever added any module for the given package, not
whether we had already added the module being proposed right now. (For
packages within nested modules, we could try adding multiple different
modules for a given package without looping.)

Moreover, the "looping trying to add package" failure message was only
marginally helpful. Users are capable of noticing that an invocation
of the 'go' command is taking too long, and will report a bug for an
infinite loop just as readily as a "looping trying to add package"
error.

We could try to add this tracking back in, but it's no substitute for
a proper proof of convergence, and the code is simpler without it.
Instead I'm going to add a proper proof of convergence — or, barring
that, a more accurate and useful check for failure to converge. In the
meantime, this invariantly-empty map isn't doing anybody any good.

For #36460

Change-Id: I2c111d4b4bf59159af0d7e62d1c0ef4ce0a43a71
Reviewed-on: https://go-review.googlesource.com/c/go/+/312929
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>