os: Simplify size using io.Discard.

Change-Id: Ib7cc86643a3dcae788a94472e54de171e0d655fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/355449
Trust: Michael Pratt <mpratt@google.com>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>

internal/fuzz: fix -fuzzminimizetime with 'x' bug

Fixes #48928

Change-Id: I3825ec615ab5fc19389ef4c10ad1042005a3761c
Reviewed-on: https://go-review.googlesource.com/c/go/+/355450
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/dist: run a checkNotStale on the builders before running tests

This should be a no-op, but if the sharded builders are for some
reason distributing stale snapshots — or testing them with mismatched
environments — this should catch them out at a relatively low cost
(#24300 notwithstanding).

Given the frequently at which (*tester).runPending already checks for
staleness, we do not expect the impact of this extra check to be
significant for most builders.

For #33598
Updates #24300

Change-Id: I197d6a69c72e2eec9e4563b459206de76c89e8a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/223755
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

[dev.typeparams] cmd/compile: add test for number of instantiations

Add a test for a generic sort function, operating on several different
pointer types (across two packages), so they should all share the same
shape-based instantiation. Actually check that only one instantiation of
Sort is created using 'go tool nm', and also check that the output is
correct.

In order to do the test on the executable using 'go nm', added this as a
'go test' in cmd/compile/internal/test.

Added the genembed.go test that I meant to include with a previous CL.

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

testing: don't create unique subtest names while fuzzing

T.Run uses a map[string]int64 to keep track of subtest names that may
be returned through T.Name. T.Name can't return duplicate names for
subtests started with T.Run.

If a fuzz target calls T.Run, this map takes a large amount of memory,
since there are a very large number of subtests that would
otherwise have duplicate names, and the map stores one entry per subtest.
The unique suffixes are not useful (and may be confusing) since the
full sequence of tests cannot be re-run deterministically.

This change deletes all entries in the map before each call to the
function being fuzzed. There is a slight change in the contract of
T.Name while fuzzing.

This change was discussed in CL 351452.

Fixes #44517

Change-Id: I3093a2e5568099ce54aca1006fac84a6fd2c3ddf
Reviewed-on: https://go-review.googlesource.com/c/go/+/354430
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>

cmd/compile: some fixes in type substituter for Instantiate

In the case in (*TSubster).Type() that we were running into an
incomplete underlying type (TFORW), we should just be immediately
returning the type returned by ts.SubstForwFunc(forw), since that call
returns a proper type node, and has set up any remaining work that has
to be done when we get done with the current top-level type definition.
(For import, that function is doInst, which does an Instantiate of the
new substituted type, with the delayed part via deferredInstStack.) We
should not continue doing the later parts of (*TSubster).Type(), since
the underlying type may not yet have its methods filled in, etc.

Also, in Instantiate(), we need to put the desired new type on
deferredInstStack, even if the base type node already exists, if the
type node is in TFORW state. This is now exactly the case when
Instantiate is called from (*TSubster).Type via doInst, since
(*TSubster).Type has already called NewIncompleteNamedType().

Fixes #48716
Fixes #48889

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

go/types: export TypeParam.Index and remove TypeParam._SetId

This change resolves a TODO regarding a couple uncertain APIs for
types.TypeParam. In the case of TypeParam._Index, we've decided it is
worth exporting. In the case of TypeParam._SetId, we've decided it is
unnecessary.

This aligns go/types with types2 (a doc comment in types2 is also
updated).

Updates #47916

Change-Id: I705e8b3437d014775c473e2f8be6f32b1540bb0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/354370
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/go: adjust documentation mentioning 'go get'

In module-aware mode, 'go get' no longer builds or installs packages.

- 'go generate' explains build commands do not run generate
  commands. 'go get' is no longer a build command, so this CL removes
  mention of it.
- 'go get' will continue to accept build flags, but they're
  ignored. The documentation no longer mentions them, though it does
  mention -x for printing VCS commands.

For #43684

Change-Id: I1eea7241eecf72ba9f98238b729d91cc77ec7665
Reviewed-on: https://go-review.googlesource.com/c/go/+/355209
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

cmd/compile: do not reuse dead value in expand_calls pass

We reuse a value for the same selector on the same arg. But if the
value is already marked dead, don't reuse it. A use of an
OpInvalid will confuse the compiler.

Fixes #48916.

Change-Id: I15b9e15b49f6e1991fe91df246cd12a193385e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/355409
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

testing: fix -run behavior with fuzz tests

This change fixes some issues with -run, and
the subsequent command line output when running
in verbose mode. It replaces CorpusEntry.Name
with CorpusEntry.Path, and refactors the code
accordingly.

This change also adds a lot of additional tests
which check explicit command line output when
fuzz targets are run without fuzzing. This will
be important to avoid regressions.

Updates #48149

Change-Id: If34b1f51db646317b7b51c3c38ae53231d01f568
Reviewed-on: https://go-review.googlesource.com/c/go/+/354632
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

cmd/internal/obj/ppc64: support alignment of prefixed insn

Insert machine NOPs when a prefixed instruction crosses a 64B boundary.
ISA 3.1 prohibits prefixed instructions being placed across them. Such
instructions generate SIGILL if executed.

Likewise, adjust the function alignment to guarantee such instructions
can never cross one. And, don't pad the PC based on alignment. The
linker can fit these more optimally.

Likewise, include the function alignment when printing function debug
information. This is needed to verify function alignment happens.

Updates #44549

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

compress/lzw: output a Clear code first, per GIF spec

The TestStartsWithClearCode test is new, but if it existed beforehand,
the want strings would be "\x81" and "Hi\x81" without a starting "\x80".

Fixes #26108
Fixes #33748
Updates makeworld-the-better-one/didder#7
Updates nothings/stb#1222

Change-Id: I35ac0ed862ba6ee921ba9aee257bc19828abaa82
Reviewed-on: https://go-review.googlesource.com/c/go/+/354710
Trust: Nigel Tao <nigeltao@golang.org>
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

cmd/link/internal/ld: use libc based fcntl for (*OutBuf).fallocate on darwin

Direct syscalls are no longer supported on darwin. Instead, use libc
fcntl go:linkname'd from the syscall package.

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

cmd/api: support type parameters

Fixes #48706

Change-Id: If0f8d0b49300027e3b2b46f6870302acf2e00f4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/354612
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/compile/internal/types2: avoid duplicate errors for invalid bounds

Resolve a TODO from an earlier CL: we should only check type parameter
bounds once in collectTypeParams.

Change-Id: Icf6053ec359f8ac8143cf68ee2defd504f8f86e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/355069
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: mark implicit interfaces as such

This is a straightforward port of CL 353396 to go/types.

For #48424

Change-Id: I3040c2ad3a8c9573026277de01deb9c47953cec8
Reviewed-on: https://go-review.googlesource.com/c/go/+/354991
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/internal/gcimporter: enable importing typeparam/issue48424.go

This is a partial revert of CL 353389, now that go/types supports
eliding interface in constraints.

For #48424

Change-Id: Ibde26fb66bf6bd5a4c919acffd045a57783d1b47
Reviewed-on: https://go-review.googlesource.com/c/go/+/354990
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: accept constraint literals with elided interfaces

This is a port of CL 353139 to go/types, adjusted for error reporting
and for the different representation of field lists in go/ast. A TODO is
added to verify if types2 produces redundant error messages for type
parameters sharing a bound.

For #48424

Change-Id: I3549942be0328de616d1d87d0ba621311fc53576
Reviewed-on: https://go-review.googlesource.com/c/go/+/354989
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: allow eliding interface in constraint literals

This is a port of CL 353133 from cmd/compile/internal/syntax, with
significant adjustments for the mechanics of go/parser.

Some additional cleanup is made along the way: parseParameterList can
call parseParamDecl without indirection, and the tparams argument is
redundant with the closing token. Also, the error that "all type
parameters must be named" is positioned on the first unnamed type
parameter.

Error recovery in go/parser is notably worse here than the compiler
parser, so the test data had to be adjusted to synchronize positions.
Fixing this error recovery will have to wait for a later CL.

As with the compiler changes, these changes are guarded behind a flag so
that they may be easily removed if #48424 is not accepted.

For #48424

Change-Id: If87925d246f36aaab11a95442f75f659462d4286
Reviewed-on: https://go-review.googlesource.com/c/go/+/354870
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>

encoding/gob: follow documented io.EOF semantics

The docs say:

If the input is at EOF, Decode returns io.EOF and does not modify e.

However, the added test fails:

--- FAIL: TestDecodePartial (0.00s)
encoder_test.go:1263: 31/81: expected io.ErrUnexpectedEOF: EOF
encoder_test.go:1263: 51/81: expected io.ErrUnexpectedEOF: EOF

In particular, the decoder would return io.EOF after reading a valid
message for a type specification, and then hit EOF before reading a data
item message.

Fix that by only allowing a Decode call to return io.EOF if the reader
hits EOF immediately, without successfully reading any message.
Otherwise, hitting EOF is an ErrUnexpectedEOF, like in other cases.

Also fix a net/rpc test that, coincidentally, expected an io.EOF
as an error when feeding bad non-zero data to a gob decoder.
An io.ErrUnexpectedEOF is clearly better in that scenario.

Fixes #48905.

Change-Id: Ied6a0d8ac8377f89646319a18c0380c4f2b09b85
Reviewed-on: https://go-review.googlesource.com/c/go/+/354972
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

cmd/compile: adjust debug/gosym to deal with instantiated types/funcs/methods

This changes debug/gosym so it can deal with instantiated
types/funcs/methods. I also added tests for instantiated names. My
assumption is that the concatenation of PackageName, ReceiverName, and
BaseName in order should cover the entire symbol name, so either the
ReceiverName or the BaseName should include any bracketed information
(either the instantiation of the receiver of a method or the
instantiation of function).

This can provide a model for how to parse instantiated functions and
method names.

Fixes #48032

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

cmd/go: insert goroot to the hash of build cache when the packages include C files

This reverts CL 351851, which itself reverted CL 348991.

The problem with the original CL, as far as I can tell, was due to a
bug in the Go project's builder infrastructure (#33598) and not the
change itself. Once the build infrastructure is fixed, this change
can be resubmitted.

Fixes #48319
Updates #33598

Change-Id: I0fdbcc241eb2bdeb350944aad58bf58774fb591e
Reviewed-on: https://go-review.googlesource.com/c/go/+/353352
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

cmd/compile: deal with TODO related to generic wrappers with embedded fields

It turns out there is no real TODO here - things are working fine. If we
are generating a wrapper for a method on a generic type that is actually
the method on embedded type, then we should just just generate the
normal embedded wrapper, which calls the wrapper for the real receiver
type on that method. There is no need to do the generic path where we
add in the dictionary argument. So, just updated that TODO comment with
this explanation.

Added a new test case embedded.go, which specifically tests various
situations involving converting to empty and non-empty interfaces.
issue44688.go already tests a bunch of these situations as well.

Also made some other cleanups in reflect.go:

 - The shape test (that I had added) at the top of imethods is useless
   (never true), since it is always an interface type, so removed it.

 - Added usual helper function deref() to make code clearer in several
   places.

 - The shape test in methodWrapper() doesn't have to check HasShape() on
   each targ - it can just check HasShape() on the whole receiver.

 - The comment about disabling the tail call optimization for RegABI is
   no longer true.

 - Simplified code in several places by using the value of existing
   variable 'methodrcvr'.

Change-Id: I8b1a5dc518dad37585824a1f73ceebb7627a9f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/355129
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>

all: update vendored golang.org/x/tools

Now that x/tools/go/types/objectpath has been updates to support type
parameters, I ran the following commands to update x/tools inside the
cmd module:

go get -d golang.org/x/tools@18fa840216958359dc43466f3e70d96add38edbb # main branch
go mod tidy
go mod vendor

Updates #48588

Change-Id: Ibebc1ac2f721d6e2eb1a4f6c610918770d4879ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/355012
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/internal/obj/ppc64: fix mtocrf, cleanup other CR ops

Fix "MOVW CRx, Rx" and "MOVFL Rx, constant", The FXM field was not
encoded correctly.

Generate mtocrf instead of mtcrf when a CRx argument is used. This
form is much faster.

Simplify several conditional statements which test if the register
argument is REG_CR or one of REG_CRx if the tested argument is known
to be matched as C_CREG. Likewise, a4 is (the From3 arg) is always
TYPE_NONE in the existing optab entries for type_ 69.

Change-Id: I3a4749b1cbfdfab6a2616586ae59e932e01dae50
Reviewed-on: https://go-review.googlesource.com/c/go/+/352789
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>

cmd/link: do not mark holes in functab

With multiple text sections, there may be holes (non-Go code) in
the PC range of Go code and covered by the functab. Previously, we
use a linear search with actual PCs to find the functab entry. We
need to use special entries to mark holes, so a PC in the hole can
be distinguished from the previous function.

Now, with the previous CL we find if the PC is in between of the
sections upfront in textOff. There is no need to mark holes in the
functab.

Change-Id: I22ff27279422bfc855c2ca35ba0fdfb63234c113
Reviewed-on: https://go-review.googlesource.com/c/go/+/354874
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

runtime: simplify multiple text section handling in findfunc

In findfunc, we first us the relative PC to find the function's
index in functab. When we split text sections, as the external
linker may shift the sections, and the PC may not match the
(virtual) PC we used to build the functab. So the index may be
inaccurate, and we need to do a (forward or backward) linear
search to find the actual entry.

Instead of using the PC directly, we can first compute the
(pre-external-link virtual) relative PC and use that to find the
index in functab. This way, the index will be accurate and we will
not need to do the special backward linear search.

Change-Id: I8ab11c66b7a5a3d79aae00198b98780e10db27b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/354873
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

doc/go1.18: document FreeBSD 11.x will no longer be supported

Mention future versions will require the COMPAT_FREEBSD12 kernel option
set in the kernel.

For #47694.

Change-Id: Ia94c4f9dbb38c68025d3c1d12dd2e241a5480a6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/354971
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>

regexp: document and implement that invalid UTF-8 bytes are the same as U+FFFD

What should it mean to run a regexp match on invalid UTF-8 bytes?
The coherent behavior options are:

1. Invalid UTF-8 does not match any character classes,
   nor a U+FFFD literal (nor \x{fffd}).
2. Each byte of invalid UTF-8 is treated identically to a U+FFFD in the input,
   as a utf8.DecodeRune loop might.

RE2 uses Rule 1.
Because it works byte at a time, it can also provide \C to match any
single byte of input, which matches invalid UTF-8 as well.
This provides the nice property that a match for a regexp without \C
is guaranteed to be valid UTF-8.

Unfortunately, today Go has an incoherent mix of these two, although
mostly Rule 2. This is a deviation from RE2, and it gives up the nice
property, but we probably can't correct that at this point.
In particular .* already matches entire inputs today, valid UTF-8 or
not, and I doubt we can break that.

This CL adopts Rule 2 officially, fixing the few places that deviate from it.

Fixes #48749.

Change-Id: I96402527c5dfb1146212f568ffa09dde91d71244
Reviewed-on: https://go-review.googlesource.com/c/go/+/354569
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

go/parser: clean up unnecessary arguments and replace an if statement

Eliminate an unnecessary argument from parseGenericType, and replace an
if statement with a switch.

Change-Id: Iaa8afeface929332579f183c8e523961cca9aca4
Reviewed-on: https://go-review.googlesource.com/c/go/+/354869
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/internal/obj/ppc64: remove unused REG_DCR types

The assembler does not support parsing DCRx registers,
nor does the compiler generate opcodes with these.

Likewise, these registers are only available on ISA
2.07 embedded processors which are not supported in
golang.

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

cmd/compile: used TESTL instead of TESTQ for cpu feature flag detection

Uses one less byte when encoded. Performance is unchanged.

Change-Id: If400c9c9fc07a033e5ae9bf975ec512e432f7825
Reviewed-on: https://go-review.googlesource.com/c/go/+/354949
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

cmd/compile: use the shorter version of XOR for breaking POPCNT register

dependency

XORL accomplishes the same thing while being shorter to encode.

Change-Id: I4397999ff617edb61a7fb7d1eca757a202ab8134
Reviewed-on: https://go-review.googlesource.com/c/go/+/354832
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>

cmd/compile: mark NOT as an op that doesn't clobber flags on i386/AMD64

NOT does not affect any FLAGS register values on i386/AMD64 so we do not
need to mark it as an Op that clobbers them.

Change-Id: I6d99cad49cfa2568b01e58190256582b18fb3b7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/354831
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>

sync: use example.com for url in ExampleWaitGroup

Fixes #48886

Change-Id: I1093ae0ba30dab5a73d4d6bcfd083564d13877a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/354830
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>

cmd/compile: eliminate successive swaps

The code generated when storing eight bytes loaded from memory in big
endian introduced two successive byte swaps that did not actually
modified the data.

The new rules match this specific pattern both for amd64 and for arm64,
eliminating the double swap.

Fixes #41684

Change-Id: Icb6dc20b68e4393cef4fe6a07b33aba0d18c3ff3
Reviewed-on: https://go-review.googlesource.com/c/go/+/320073
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Dmitri Shuralyov <dmitshur@golang.org>

cmd/internal/obj: rename MOVBE{LL,QQ,WW} to just MOVBE{L,Q,W}

The double suffix doesn't seem to serve any purpose, and we can keep
the old spelling as a backwards compatible alias in cmd/asm.

Change-Id: I3f01fc7249fb093ac1b25bd75c1cb9f39b8f62a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/354700
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>

cmd/go: do not expect a specific timing in test_fuzz_minimize

Empirically, it may take more than 3 seconds for minimization to begin.
If that is the case, the "elapsed:" message may start at 4s or higher.

Fixes #48870

Change-Id: I6bb4367b61377454b0af664d80232fdb46e7c245
Reviewed-on: https://go-review.googlesource.com/c/go/+/354794
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

go/build, internal/goarch: sort goarchList alphabetically

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

cmd/cgo: use "!compiler_bootstrap" tag instead of "go1.18"

The illumos builder is using a Go 1.18 prerelease toolchain for
bootstrapping, which doesn't have ast.IndexListExpr. But we can
instead check for the "compiler_bootstrap" build tag that's already
used for distinguishing binaries built for toolchain1.

Fixes #48863.

Change-Id: I87b672322eee22a60ab8d0bb3be5f76cffc97545
Reviewed-on: https://go-review.googlesource.com/c/go/+/354695
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

cmd/link: put gcprog symbols along with gcbits

A stack object record may refer to the object's type's GC mask or
GC program (for very large types). For the latter, currently the GC
program symbol is named "type..gcprog.XXX" which is then laid out
along with type symbols at link time. When relro is used, the type
symbols end up in a different section.

As we now use relative addressing for stack object records to refer
to GC masks or GC programs, it is important that it is laid out in
the rodata section (not rodata.rel.ro). Move GC program symbols to
be along with GC masks, as they are similar and accessed the same
way. They don't have relocations so they don't need to be laid to a
relro section.

This fixes flaky failures like
https://build.golang.org/log/3bdbaaf786ec831b4393a64a959d2130edb5e050

Change-Id: I97aeac1234869da5b0f3a73a3010513d6a3156c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/354793
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

runtime: fix uint64->float32 conversion for softfloat

The fix for #48807 in CL 354429 forgot that we also need to fix
the softfloat implementation.

Update #48807

Change-Id: I596fb4e14e78145d1ad43c130b2cc5122b73655c
Reviewed-on: https://go-review.googlesource.com/c/go/+/354613
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

go/types: rename rparamMap to recvTParamMap to match types2

See also CL 354693.

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

cmd/compile/internal/types2: use an identifier map rather than isubst for recv type params

This is a port of CL 354643 from go/types to types2 with adjustments:
- use of syntax rather than go/ast package as needed
- adjustments due to the different code for type parameter declarations
- rename of Checker.rparamMap to Checker.recvTParamMap, which seems clearer

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

cmd/compile: allow delaying of transformCompLit, new transformAddr

For this unusual case, where a constraint specifies exactly one type, we
can have a COMPLIT expression with a type that is/has typeparams.

Therefore, we add code to delay transformCompLit for generic functions.
We also need to break out transformAddr (which corresponds to tcAddr),
and added code for delaying it as well. Also, we now need to export
generic functions containing untransformed OCOMPLIT and OKEY nodes, so
added support for that in iexport.go/iimport.go. Untransformed OKEY
nodes include an ir.Ident/ONONAME which we can now export.

Had to adjust some code/asserts in transformCompLit(), since we may now
be transforming an OCOMPLIT from an imported generic function (i.e. from
a non-local package).

Fixes #48537

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

go/ast, go/types: remove some stale TODOs

We've decided to leave TParams on FuncType, and type list syntax is
no longer part of the proposal.

Change-Id: Id34f6495a358d76994df331384a4b93487275c4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/354751
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>

misc/cgo/testshared: pass the testing.T to goCmd when available

Noticed while investigating the test failure in
https://build.golang.org/log/4fc4aa11087c74bb8f66c81a8b212f41fb495be4.

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

time: allow minimum int64 in ParseDuration

ParseDuration should handle minimum int64 (-1<<63) nanosecond
since type Duration is alias of int64

name           old time/op  new time/op  delta
ParseDuration  91.4ns ± 0%  86.4ns ± 1%  -5.49%  (p=0.000 n=9+8)

Fixes: #48629
Change-Id: I81b7035b25cefb4c1e5b7801c20f2d335e29358a
Reviewed-on: https://go-review.googlesource.com/c/go/+/352269
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

go/types: use an identifier map rather than isubst for recv type params

Receiver type parameters are the only type expressions allowed to be
blank. Previously this was handled by substitution of synthetic
non-blank names in the receiver type expression, but that introduced
problems related to AST mangling: the scope had extra elements,
Object.Name() was inaccurate, and synthetic nodes were recorded in
types.Info.

Fix this instead by recording a map of *ast.Ident->*TypeParam on the
Checker, which is read in Checker.ident to resolve blank identifiers
denoting receiver type parameters.

Change-Id: I6a7a86b823409f54778c0f141e8bd269a2cc85d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/354643
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>

image/png: fix interlaced palette out-of-bounds

PNG images can be paletted, where each pixel value (a uint8) indexes a
slice of colors. In terms of wire format, the PLTE chunk explicitly
contains the palette length. However, in practice, some arguably
malformed images contain pixel values greater than or equal to the
explicit PLTE length.

Go's image/png decoder accomodates such images by lengthening the
decoded image's palette if the implicit maximum is larger than the
explicit maximum. This was already done, prior to this commit, by the
"if len(paletted.Palette) <= int(idx)" lines in decoder.readImagePass.

Separately, PNG images can also be interlaced, where the final image is
the result of merging multiple partial images, also called passes. Prior
to this commit, we applied the palette lengthening to the pass images
but not the final image. This commit fixes that.

Fixes #48612

Change-Id: I77606538cc9a504fbd726071756ebcd10c9da73f
Reviewed-on: https://go-review.googlesource.com/c/go/+/354709
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

go/types: partial revert of incorrect unification "fix"

This is a port of CL 354690 from types2 to go/types.

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

cmd/compile/internal/types2: partial revert of incorrect unification "fix"

The "fix" (CL 352832) for #48619 was incorrect and broke
the unification algorithm in some cases (e.g., #48695).

This CL reverts the changes made by CL 352832 to unify.go,
and comments out code in corresponding tests.

As a result, #48695 will be fixed, and we will re-open #48619.

Fixes #48695.
For #48619.
For #48656.

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

unicode: use IsSpace not IsUpper in IsSpace example test

Change-Id: Ie3017e5507f57cbb2ae9c8b737b378cef91fefeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/354509
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/link: mark holes in functab with end PC-1

When we have multiple text sections, we need to mark holes between
the sections in the functab. A hole is marked with an entry with
the end PC of the previous section. As we now use offsets instead
of (relocated) PCs, the end offset of a section may be the same of
the start of the next one. Distinguish it by using the end address
-1.

For #48837.

Change-Id: I121aac53b32a869378632cf151cb1b6f98ad3089
Reviewed-on: https://go-review.googlesource.com/c/go/+/354636
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

runtime: handle end PC in textAddr

As the func table contains the end marker of the text section, we
sometimes need to get that address from an offset. Currently
textAddr doesn't handle that address, as it is not within any
text section. Instead of letting the callers not call textAddr
with the end offset, just handle it more elegantly in textAddr.

For #48837.

Change-Id: I6e97e455f6cb66e9680a7aac6152ba6f4cda2e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/354635
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

testing: with -benchtime=1x, run the benchmark loop exactly once

Like with -benchtime=1ns, if we find that the "discovery" round (run1)
has already crossed the -benchtime threshold, we skip running more
iterations.

Fixes #32051

Change-Id: I76aaef2ba521ba8ad6bbde2b14977e191aada5e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/331089
Trust: Caleb Spare <cespare@gmail.com>
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>

cmd/compile: improving printing of type names in func/meth instantiations

Change to using types.(*Type).LinkString() for printing names of types
in function/method instantiations. (e.g. f[int] or Value[p.Myint].Set())

LinkString already generates a unique string description for t, using
package paths, except that it uses "" for the local package path. The ""
will be expanded in the linker, so the names in the executable will have
full package paths everywhere and de-duplication of function/method
instantiations will work properly. We do need to add an explicit
substitution of "" in ReadImports() for function/method names. We
previously were using NameString(), which doesn't use full package
paths, so is not fully unique.

We had also discussed that we would prefer to minimize spaces in
function/method instantiation names. So, I changed LinkString() to
eliminate all unneeded spaces. In the one case where we need a
separator, which is between field names and types, we use a "#" instead
of a space.

This change has the advantage of eliminating spaces in some existing
non-generic function name - mainly .type.eq functions for anonymous
types (e.g. "type..eq.struct { runtime.gList; runtime.n int32 }") shows
up in a hello-world executable (as Cherry pointed out).

We do not need an analogous function for types2 right now, since we
create all instantiations using types1 types. In the one case where we
need to create an instantiation during types2-to-types1 translation, we
convert the types to types1 first (see (*irgen).instTypeName2).

Change-Id: Iac4748fa0d0d6f89af59bd51076266986daee945
Reviewed-on: https://go-review.googlesource.com/c/go/+/353609
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

internal/fuzz: log that minimization is occurring

Previously, when fuzzing for a period of time, the
command line output would look something like this:

   fuzz: minimizing 34995-byte crash input...
   fuzz: elapsed: 3s, execs: 13821 (4604/sec), new interesting: 0 (total: 1)
   fuzz: elapsed: 6s, execs: 13821 (2303/sec), new interesting: 0 (total: 1)
   fuzz: elapsed: 9s, execs: 13821 (1535/sec), new interesting: 0 (total: 1)
   --- FAIL: FuzzFoo (9.05s)

This is the same output it has while fuzzing, so if
minimization runs for a long time (default allows 1
minute), then it looks like minimization is hanging.
It's also confusing that the execs/sec would continually
decrease.

Now, when minimization is running, the command line
output will look something like this:

   fuzz: minimizing 34995-byte crash input...
   fuzz: elapsed: 3s, minimizing
   fuzz: elapsed: 6s, minimizing
   fuzz: elapsed: 9s, minimizing
   fuzz: elapsed: 9s, minimizing
   --- FAIL: FuzzFoo (9.05s)

The final "fuzz: elapsed: 6s, minimizing" could be
printed twice because we always print one final log
to the command line before we exit.

Updates #48820

Change-Id: Ie5b9fde48b8d4e36e13a81ae50a6d69bf4d0dbe3
Reviewed-on: https://go-review.googlesource.com/c/go/+/354371
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

os: don't use wait6 on netbsd

CL 315281 changed the os package use wait6 on netbsd. This seems to be
causing frequent test failures as reported in #48789. Revert that change
using wait6 on netbsd for now.

Updates #13987
Updates #16028
For #48789

Change-Id: Ieddffc65611c7f449971eaa8ed6f4299a5f742c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/354249
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

cmd/go/internal/web: improve IP check testing on ipv6 env

The existing implementation lacks consideration of running test on a
machine which has ipv6 address but no ipv4 address. Use net.IP.IsLoopback
and net.IP.IsUnspecified instead of hardcoded addresses.

Fixes: #48575
This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.

Change-Id: I9c3c26d2ba13c7a24065751b59a1e002098ed654
GitHub-Last-Rev: fc45adbf7b944122d8f07bd451a8eeed1e69140c
GitHub-Pull-Request: golang/go#48850
Reviewed-on: https://go-review.googlesource.com/c/go/+/354609
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>

test/fixedbugs: fix issue48784.go to pass with -G=0

This test is currently failing in the longtest builders.

I do not know how or why the builders are adding the -G=0 parameter.

Updates #48784

Change-Id: I62248d3fbc47567a8c73b4868a2d4aeb0bc47bc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/354631
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

misc/wasm, cmd/link: do not let command line args overwrite global data

On Wasm, wasm_exec.js puts command line arguments at the beginning
of the linear memory (following the "zero page"). Currently there
is no limit for this, and a very long command line can overwrite
the program's data section. Prevent this by limiting the command
line to 4096 bytes, and in the linker ensuring the data section
starts at a high enough address (8192).

(Arguably our address assignment on Wasm is a bit confusing. This
is the minimum fix I can come up with.)

Thanks to Ben Lubar for reporting this issue.

Fixes #48797
Fixes CVE-2021-38297

Change-Id: I0f50fbb2a5b6d0d047e3c134a88988d9133e4ab3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1205933
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/354571
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/compile,runtime: implement uint64->float32 correctly on 32-bit archs

The old way of implementing it, float32(float64(x)), involves 2 roundings
which can cause accuracy errors in some strange cases. Implement a runtime
version of [u]int64tofloat32 which only does one rounding.

Fixes #48807

Change-Id: Ie580be480bee4f3a479e58ef8dce23032f231704
Reviewed-on: https://go-review.googlesource.com/c/go/+/354429
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

math: add Remainder example

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

cmd/cgo: update to handle ast.IndexListExpr

Allows cgo to work with generics.

Updates #47781.

Change-Id: Id1a5d1a0a8193c5b157e3e671b1490d687d10384
Reviewed-on: https://go-review.googlesource.com/c/go/+/353882
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

cmd/compile: fix the index variable is shadowed in dictPass

The CL 349613 causes this problem.
In fact, we want to use the outer i to find m.List[i],
but the newly created index variable i in the nearest
for range shadow the outer i.

Fixes #48838.

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

go/types: better error message for invalid untyped nil conversion

This is port of CL 354049 for types2 to go/type.

The change is identical, but for some tweaks to the error message/position
in tests, since when go/types reports the exact operation "cannot convert"
instead of the general "invalid operation" like types2.

Updates #48784

Change-Id: I3e99f2721501d23187fd0a8970eb1de28e0c41d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/354050
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: Robert Findley <rfindley@google.com>

cmd/compile: better error message for invalid untyped nil conversion

In case of an invalid untyped nil conversion, the compiler's original
type checker leaves it to the caller to report a suitable error message.
But types2 does not, it always reports the invalid conversion.

CL 328053 made types2 report a better error message, and match the
original compiler behavior. But it ignored the case of untyped nil.

This CL adds that missing case, by checking whether the two operands can
be mixed when untyped nil is present.

Fixes #48784

Change-Id: Idc7d86eb0245aa18ca428e278f4416d6b3679058
Reviewed-on: https://go-review.googlesource.com/c/go/+/354049
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

runtime,sync: using fastrandn instead of modulo reduction

fastrandn is ~50% faster than fastrand() % n.
`ack -v 'fastrand\(\)\s?\%'` finds all modulo on fastrand()

name              old time/op  new time/op  delta
Fastrandn/2       2.86ns ± 0%  1.59ns ± 0%  -44.35%  (p=0.000 n=9+10)
Fastrandn/3       2.87ns ± 1%  1.59ns ± 0%  -44.41%  (p=0.000 n=10+9)
Fastrandn/4       2.87ns ± 1%  1.58ns ± 1%  -45.10%  (p=0.000 n=10+10)
Fastrandn/5       2.86ns ± 1%  1.58ns ± 1%  -44.84%  (p=0.000 n=10+10)

Change-Id: Ic91f5ca9b9e3b65127bc34792b62fd64fbd13b5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/353269
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

go/types: implement copy for generic argument types

This is a port of CL 354432 from types2 to go/types
with minor adjustments:
- an error message has a different position
- the constraint literals are wrapped in interfaces
  because the interface-free notation has not been
  ported yet

Change-Id: I167094b57b39027566f2b7ce3aa97a071bae4da5
Reviewed-on: https://go-review.googlesource.com/c/go/+/354489
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

cmd/compile/internal/types2: implement copy for generic argument types

For now, the underlying types of the the argument types' constraints
must be a single type that is a slice (the source operand may also
be a string).

Change-Id: I9e705e3349c9242f126b9c3e0af65e9ffb25fe6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/354432
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

test: skip endian inlining test on noopt builder

Change-Id: I73b1ac23f322bcaff36eff7a5829654f299c1fdd
Reviewed-on: https://go-review.googlesource.com/c/go/+/354353
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

net/http: add Cookie.Valid method

The (*http.Cookie).String method used by SetCookie will silently discard
or sanitize any fields it deems invalid, making it difficult to tell
whether a cookie will be sent as expected.

This change introduces a new (*http.Cookie).Valid method which may be
used to check if any cookie fields will be discarded or sanitized prior
to calling (*http.Cookie).String.

Fixes #46370

Change-Id: I2db80078de190d267a9c675a9717c8be8acc8704
Reviewed-on: https://go-review.googlesource.com/c/go/+/338590
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>

cmd/compile: fix -W=3 output after the # line

I've noticed for a while that there is some duplicated and some useful
information being put out in -W=3 mode after the comment marker (besides
the position).

dumpNodeHeader puts out a comment marker '#' before putting out the
position of a node (which is for almost all nodes). Therefore, we shouldn't
print out anything on the same line after calling dumpNodeHeader().

But we happen to be putting out a duplicate type of the node in some
cases. Also, we put out the Sym() associate with the node after
dumpNodeHeader(). So, I got rid of the duplicate type print-out, and moved
the print-out of n.Sym() to be inside dumpNodeHeader() before the
position information. Also, moved the tc flag to be right after the type
information, which seems like it makes more sense.

Change-Id: I05210fbf9f3b2d8e3b73fc0ceab26a7bce5dc104
Reviewed-on: https://go-review.googlesource.com/c/go/+/354355
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

unicode: add examples for the Is functions

Change-Id: If4afe33985dc0a758db32564244095190b82e5c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/353691
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Rob Pike <r@golang.org>

time: fallback to slower TestTicker test after one failure

TestTicker is sensitive to overloaded or slow systems, where a 20ms
ticker running for 10 ticks has a total run time out of the range
[110ms, 290ms]. To counter this flakiness, it tries five times to
get a successful result. This is insufficient--an overloaded test
machine can introduce more than 100ms of delay across the test.

Reduce the five attempts to two, but use a 1s ticker for 8 ticks
in the second attempt.

Updates #46474.
Updates #35692.

Change-Id: Ibd5187b00ccceeb981b652f2af9a1c3766357b78
Reviewed-on: https://go-review.googlesource.com/c/go/+/339892
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

strings,bytes: avoid allocations in Trim/TrimLeft/TrimRight

There is evidence that the vast majority of uses for Trim* involve
cutsets with a single ASCII character, and the vast majority of
remaining uses involve cutsets with a small (<4) ASCII characters.
For this reason it makes sense to provide better fast paths for these
common cases.

Furthermore the current implementation needlessly allocates for unclear
benefits. This CL also replaces all paths to avoid allocations and, as
a side effect, it speeds up also the slow path.

strings:
name                    old time/op    new time/op    delta
Trim                      1.71µs ± 1%    0.70µs ± 0%   -58.93%  (p=0.008 n=5+5)
TrimASCII/1:1             6.43ns ± 0%    6.34ns ± 0%    -1.41%  (p=0.008 n=5+5)
TrimASCII/1:2             97.3ns ± 0%    18.2ns ± 1%   -81.34%  (p=0.008 n=5+5)
TrimASCII/1:4              101ns ± 0%      21ns ± 0%   -78.77%  (p=0.008 n=5+5)
TrimASCII/1:8              109ns ± 0%      29ns ± 0%   -73.60%  (p=0.008 n=5+5)
TrimASCII/1:16             124ns ± 0%      43ns ± 0%   -65.16%  (p=0.008 n=5+5)
TrimASCII/16:1            19.8ns ± 0%    18.6ns ± 0%    -5.90%  (p=0.008 n=5+5)
TrimASCII/16:2             167ns ± 0%      33ns ± 0%   -80.21%  (p=0.008 n=5+5)
TrimASCII/16:4             169ns ± 0%      35ns ± 0%   -79.01%  (p=0.008 n=5+5)
TrimASCII/16:8             177ns ± 0%      43ns ± 0%   -75.88%  (p=0.008 n=5+5)
TrimASCII/16:16            193ns ± 2%      57ns ± 1%   -70.30%  (p=0.008 n=5+5)
TrimASCII/256:1            232ns ± 0%     232ns ± 0%      ~     (p=1.000 n=5+5)
TrimASCII/256:2           1.28µs ± 1%    0.26µs ± 0%   -79.46%  (p=0.008 n=5+5)
TrimASCII/256:4           1.27µs ± 0%    0.27µs ± 0%   -78.95%  (p=0.008 n=5+5)
TrimASCII/256:8           1.28µs ± 0%    0.28µs ± 1%   -78.28%  (p=0.008 n=5+5)
TrimASCII/256:16          1.30µs ± 1%    0.29µs ± 0%   -77.49%  (p=0.008 n=5+5)
TrimASCII/4096:1          3.47µs ± 0%    3.47µs ± 0%    -0.14%  (p=0.008 n=5+5)
TrimASCII/4096:2          18.2µs ± 0%     3.9µs ± 0%   -78.53%  (p=0.008 n=5+5)
TrimASCII/4096:4          18.2µs ± 0%     3.9µs ± 0%   -78.55%  (p=0.008 n=5+5)
TrimASCII/4096:8          18.2µs ± 0%     3.9µs ± 0%   -78.49%  (p=0.008 n=5+5)
TrimASCII/4096:16         18.3µs ± 0%     3.9µs ± 0%   -78.44%  (p=0.008 n=5+5)
TrimByte                  10.6ns ± 1%    10.1ns ± 0%    -5.01%  (p=0.008 n=5+5)
TrimSpace/NoTrim          5.90ns ± 0%    5.89ns ± 0%      ~     (p=0.135 n=5+5)
TrimSpace/ASCII           10.6ns ± 0%     9.9ns ± 0%    -6.21%  (p=0.008 n=5+5)
TrimSpace/SomeNonASCII     127ns ± 0%     126ns ± 0%    -0.96%  (p=0.008 n=5+5)
TrimSpace/JustNonASCII     178ns ± 0%     178ns ± 0%      ~     (p=0.825 n=5+4)

name                    old alloc/op   new alloc/op   delta
Trim                        456B ± 0%        0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:1              0.00B          0.00B           ~     (all equal)
TrimASCII/1:2              48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:4              48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:8              48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:16             48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:1             0.00B          0.00B           ~     (all equal)
TrimASCII/16:2             48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:4             48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:8             48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:16            48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:1            0.00B          0.00B           ~     (all equal)
TrimASCII/256:2            48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:4            48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:8            48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:16           48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:1           0.00B          0.00B           ~     (all equal)
TrimASCII/4096:2           48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:4           48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:8           48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:16          48.0B ± 0%      0.0B           ~     (p=0.079 n=4+5)
TrimByte                   0.00B          0.00B           ~     (all equal)
TrimSpace/NoTrim           0.00B          0.00B           ~     (all equal)
TrimSpace/ASCII            0.00B          0.00B           ~     (all equal)
TrimSpace/SomeNonASCII     0.00B          0.00B           ~     (all equal)
TrimSpace/JustNonASCII     0.00B          0.00B           ~     (all equal)

name                    old allocs/op  new allocs/op  delta
Trim                        18.0 ± 0%       0.0       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:1               0.00           0.00           ~     (all equal)
TrimASCII/1:2               2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:4               2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:8               2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:16              2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:1              0.00           0.00           ~     (all equal)
TrimASCII/16:2              2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:4              2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:8              2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:16             2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:1             0.00           0.00           ~     (all equal)
TrimASCII/256:2             2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:4             2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:8             2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:16            2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:1            0.00           0.00           ~     (all equal)
TrimASCII/4096:2            2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:4            2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:8            2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:16           2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimByte                    0.00           0.00           ~     (all equal)
TrimSpace/NoTrim            0.00           0.00           ~     (all equal)
TrimSpace/ASCII             0.00           0.00           ~     (all equal)
TrimSpace/SomeNonASCII      0.00           0.00           ~     (all equal)
TrimSpace/JustNonASCII      0.00           0.00           ~     (all equal)

bytes:
name                    old time/op    new time/op    delta
TrimSpace/NoTrim          5.89ns ± 0%    5.91ns ± 0%      ~     (p=0.095 n=5+4)
TrimSpace/ASCII           10.3ns ± 1%    10.2ns ± 0%      ~     (p=0.095 n=5+5)
TrimSpace/SomeNonASCII     120ns ± 1%     121ns ± 0%    +1.13%  (p=0.008 n=5+5)
TrimSpace/JustNonASCII     194ns ± 1%     195ns ± 0%      ~     (p=0.143 n=5+5)
TrimASCII/1:1             6.28ns ± 0%    5.95ns ± 0%    -5.26%  (p=0.008 n=5+5)
TrimASCII/1:2             95.8ns ± 1%    18.6ns ± 0%   -80.63%  (p=0.008 n=5+5)
TrimASCII/1:4             98.8ns ± 0%    22.1ns ± 0%   -77.62%  (p=0.008 n=5+5)
TrimASCII/1:8              107ns ± 0%      29ns ± 0%   -72.72%  (p=0.008 n=5+5)
TrimASCII/1:16             123ns ± 0%      44ns ± 1%   -64.30%  (p=0.008 n=5+5)
TrimASCII/16:1            13.2ns ± 0%    12.8ns ± 1%    -2.75%  (p=0.008 n=5+5)
TrimASCII/16:2             169ns ± 0%      33ns ± 0%   -80.33%  (p=0.008 n=5+5)
TrimASCII/16:4             173ns ± 0%      36ns ± 0%   -79.31%  (p=0.008 n=5+5)
TrimASCII/16:8             180ns ± 0%      43ns ± 0%   -76.02%  (p=0.008 n=5+5)
TrimASCII/16:16            197ns ± 2%      58ns ± 0%   -70.73%  (p=0.008 n=5+5)
TrimASCII/256:1            137ns ± 1%     136ns ± 0%    -0.82%  (p=0.016 n=5+5)
TrimASCII/256:2           1.40µs ± 0%    0.26µs ± 0%   -81.02%  (p=0.008 n=5+5)
TrimASCII/256:4           1.40µs ± 0%    0.27µs ± 0%   -80.83%  (p=0.008 n=5+5)
TrimASCII/256:8           1.41µs ± 0%    0.28µs ± 0%   -80.36%  (p=0.008 n=5+5)
TrimASCII/256:16          1.42µs ± 0%    0.29µs ± 0%   -79.48%  (p=0.008 n=5+5)
TrimASCII/4096:1          1.75µs ± 0%    1.75µs ± 0%      ~     (p=0.595 n=5+5)
TrimASCII/4096:2          20.9µs ± 0%     3.9µs ± 0%   -81.29%  (p=0.008 n=5+5)
TrimASCII/4096:4          20.9µs ± 0%     3.9µs ± 0%   -81.27%  (p=0.008 n=5+5)
TrimASCII/4096:8          20.9µs ± 0%     3.9µs ± 0%   -81.22%  (p=0.008 n=5+5)
TrimASCII/4096:16         20.9µs ± 0%     3.9µs ± 0%   -81.21%  (p=0.008 n=5+5)
TrimByte                  9.21ns ± 0%    9.30ns ± 0%    +0.91%  (p=0.008 n=5+5)

name                    old alloc/op   new alloc/op   delta
TrimSpace/NoTrim           0.00B          0.00B           ~     (all equal)
TrimSpace/ASCII            0.00B          0.00B           ~     (all equal)
TrimSpace/SomeNonASCII     0.00B          0.00B           ~     (all equal)
TrimSpace/JustNonASCII     0.00B          0.00B           ~     (all equal)
TrimASCII/1:1              0.00B          0.00B           ~     (all equal)
TrimASCII/1:2              48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:4              48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:8              48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:16             48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:1             0.00B          0.00B           ~     (all equal)
TrimASCII/16:2             48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:4             48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:8             48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:16            48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:1            0.00B          0.00B           ~     (all equal)
TrimASCII/256:2            48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:4            48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:8            48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:16           48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:1           0.00B          0.00B           ~     (all equal)
TrimASCII/4096:2           48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:4           48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:8           48.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:16          49.0B ± 0%      0.0B       -100.00%  (p=0.008 n=5+5)
TrimByte                   0.00B          0.00B           ~     (all equal)

name                    old allocs/op  new allocs/op  delta
TrimSpace/NoTrim            0.00           0.00           ~     (all equal)
TrimSpace/ASCII             0.00           0.00           ~     (all equal)
TrimSpace/SomeNonASCII      0.00           0.00           ~     (all equal)
TrimSpace/JustNonASCII      0.00           0.00           ~     (all equal)
TrimASCII/1:1               0.00           0.00           ~     (all equal)
TrimASCII/1:2               2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:4               2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:8               2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/1:16              2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:1              0.00           0.00           ~     (all equal)
TrimASCII/16:2              2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:4              2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:8              2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/16:16             2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:1             0.00           0.00           ~     (all equal)
TrimASCII/256:2             2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:4             2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:8             2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/256:16            2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:1            0.00           0.00           ~     (all equal)
TrimASCII/4096:2            2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:4            2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:8            2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimASCII/4096:16           2.00 ± 0%      0.00       -100.00%  (p=0.008 n=5+5)
TrimByte                    0.00           0.00           ~     (all equal)

Fixes #46446

Change-Id: I9537c86f888af6285027f67bda4a97aeedb41d4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/332771
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>
Trust: Joe Tsai <joetsai@digital-static.net>
Trust: Than McIntosh <thanm@google.com>

cmd/compile: simplify code in walkPrint

Use typecheck.Conv; it does the same thing.

Change-Id: I6bf27b8e929f8016ffc8350931c8320e36584a3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/354350
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

go/build: ignore package main files in TestDependencies

The tree has package main files scattered around
in it for the purposes of running go generate.

They're all marked "// +build ignore",
which gets special handling in TestDependencies.
It would be nice to be able to use other build tags,
such as "generate", as suggested by the go generate
design doc. Plus the build tag syntax is changing.

This change skips all "package main" files.
By definition these aren't importable,
so they can't contribute to the dependency tree.

We can't quite eliminate the "// +build ignore"
check, as it is used by packages runtime and syscall.
But it's still a step in the right direction.

Change-Id: Ib9449acfdba75f570b87a4200afe944910d76222
Reviewed-on: https://go-review.googlesource.com/c/go/+/339592
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

cmd/compile: add runtime.funcspdelta to intended inlining test

Follow-up to CL 354133.

Suggested-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I0d0895dfa8c2deae0dbda6e683fbe41469849145
Reviewed-on: https://go-review.googlesource.com/c/go/+/354392
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

runtime: streamline moduledata.textAddr

Accept a uint32 instead of a uintptr to make call sites simpler.

Do less work in the common case in which len(textsectmap) == 1.

Change-Id: Idd6cdc3fdad7a9356864c83790463b5d3000171b
Reviewed-on: https://go-review.googlesource.com/c/go/+/354132
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>

all: update go.mod for golang.org/x/net

Somehow CL 353390 managed to update the vendored code to d2e5035098b3,
but not the go.mod and other version references. Fix.

Change-Id: Ic265c10f7bd7ec982671b46c5d9ae50636a13309
Reviewed-on: https://go-review.googlesource.com/c/go/+/354391
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

cmd/compile: make encoding/binary loads/stores cheaper to inline

The encoding/binary little- and big-endian load and store routines are
frequently used in performance sensitive code. They look fairly complex
to the inliner. Though the routines themselves can be inlined,
code using them typically cannot be.
Yet they typically compile down to an instruction or two
on architectures that support merging such loads.

This change teaches the inliner to treat calls to these methods as cheap,
so that code using them will be more inlineable.

It'd be better to teach the inliner that this pattern of code is cheap,
rather than these particular methods. However, that is difficult to do
robustly when working with the IR representation. And the broader project
of which that would be a part, namely to model the rest of the compiler
in the inliner, is probably a non-starter. By way of contrast, imperfect
though it is, this change is an easy, cheap, and useful heuristic.
If/when we base inlining decisions on more accurate information obtained
later in the compilation process, or on PGO/FGO, we can remove this
and other such heuristics.

Newly inlineable functions in the standard library:

crypto/cipher.gcmInc32
crypto/sha512.appendUint64
crypto/md5.appendUint64
crypto/sha1.appendUint64
crypto/sha256.appendUint64
vendor/golang.org/x/crypto/poly1305.initialize
encoding/gob.(*encoderState).encodeUint
vendor/golang.org/x/text/unicode/norm.buildRecompMap
net/http.(*http2SettingsFrame).Setting
net/http.http2parseGoAwayFrame
net/http.http2parseWindowUpdateFrame

Benchmark impact for encoding/gob (the only package I measured):

name                       old time/op  new time/op  delta
EndToEndPipe-8             2.25µs ± 1%  2.21µs ± 3%   -1.79%  (p=0.000 n=28+27)
EndToEndByteBuffer-8       93.3ns ± 5%  94.2ns ± 5%     ~     (p=0.174 n=30+30)
EndToEndSliceByteBuffer-8  10.5µs ± 1%  10.6µs ± 1%   +0.87%  (p=0.000 n=30+30)
EncodeComplex128Slice-8    1.81µs ± 0%  1.75µs ± 1%   -3.23%  (p=0.000 n=28+30)
EncodeFloat64Slice-8        900ns ± 1%   847ns ± 0%   -5.91%  (p=0.000 n=29+28)
EncodeInt32Slice-8         1.02µs ± 0%  0.90µs ± 0%  -11.82%  (p=0.000 n=28+26)
EncodeStringSlice-8        1.16µs ± 1%  1.04µs ± 1%  -10.20%  (p=0.000 n=29+26)
EncodeInterfaceSlice-8     28.7µs ± 3%  29.2µs ± 6%     ~     (p=0.067 n=29+30)
DecodeComplex128Slice-8    7.98µs ± 1%  7.96µs ± 1%   -0.27%  (p=0.017 n=30+30)
DecodeFloat64Slice-8       4.33µs ± 1%  4.34µs ± 1%   +0.24%  (p=0.022 n=30+29)
DecodeInt32Slice-8         4.18µs ± 1%  4.18µs ± 0%     ~     (p=0.074 n=30+28)
DecodeStringSlice-8        13.2µs ± 1%  13.1µs ± 1%   -0.64%  (p=0.000 n=28+28)
DecodeStringsSlice-8       31.9µs ± 1%  31.8µs ± 1%   -0.34%  (p=0.001 n=30+30)
DecodeBytesSlice-8         8.88µs ± 1%  8.84µs ± 1%   -0.48%  (p=0.000 n=30+30)
DecodeInterfaceSlice-8     64.1µs ± 1%  64.2µs ± 1%     ~     (p=0.173 n=30+28)
DecodeMap-8                74.3µs ± 0%  74.2µs ± 0%     ~     (p=0.131 n=29+30)

Fixes #42958

Change-Id: Ie048b8976fb403d8bcc72ac6bde4b33e133e2a47
Reviewed-on: https://go-review.googlesource.com/c/go/+/349931
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

cmd/link,runtime: make textsectmap fields more convenient for runtime

They're only used in a single place.
Instead of calculating the end every time,
calculate it in the linker.

It'd be nice to recalculate baseaddr-vaddr,
but that generates relocations that are too large.

While we're here, remove some pointless uintptr -> uintptr conversions.

Change-Id: I91758f9bff11b365bc3a63fee172dbdc3d90b966
Reviewed-on: https://go-review.googlesource.com/c/go/+/354089
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/go/testdata/script: move test from test_fuzz to test_fuzz_cache

Tests that require instrumentation must be in
a test script which only runs for architectures
where coverage is supported.

Change-Id: Ia56b1cef1071f848c9dce8c87597207937fdb6c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/354372
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

time: truncate fractional seconds longer than 9 digits

Fixes #48685

Change-Id: Id246708878c2902b407ab759537f6b545a1f459f
GitHub-Last-Rev: 4d985192c5a66ae8891539f166ef88b53cd1cbea
GitHub-Pull-Request: golang/go#48750
Reviewed-on: https://go-review.googlesource.com/c/go/+/353713
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>

go/types: break cycles in invalid types

This is a clean port of CL 354329 from types2 to go/types.

For #48819.

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

cmd/compile/internal/types2: break cycles in invalid types

This CL reverses the change in CL 284254 (which was ported
to types2) which originated in CL 240901 to address a crash
in a test created by a fuzzer (that crash appears to be
avoided in other ways, now).

This exposed another bug in typeset.go where we don't look
for the underlying type when testing if a type is an interface
or not. Fixed that as well.

Adjusted a test case that now doesn't report an error anymore
(which is good).

Fixes #48819.

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

cmd/compile/internal/syntax, types2: remove ability to handle type lists

The type set notation has been accepted a while ago.
We're not going back to supporting the original
type list notation. Remove support for it in the
parser and type checker.

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

cmd/link: remove unnecessary int conversions

By making off an int64 at the beginning,
the code gets a lot simpler. Cleanup only.

Change-Id: I4a2519f953e2f71081a4ff3032f8fd6da06c7e24
Reviewed-on: https://go-review.googlesource.com/c/go/+/354138
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>

cmd/internal/obj: allow more gcbits content addressability

Follow-up to feedback on CL 352189.

Change-Id: I3d9fa87878a74a5a725812c7852050c02c433fa3
Reviewed-on: https://go-review.googlesource.com/c/go/+/354137
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>

internal/cpu: remove option to mark cpu features required

With the removal of SSE2 runtime detection made in
golang.org/cl/344350 we can remove this mechanism as there
are no required features anymore.

For making sure CPUs running a go program support all
the minimal hardware requirements the go runtime should
do feature checks early in the runtime initialization
before it is likely any compiler emitted but unsupported
instructions are used. This is already the case for e.g.
checking MMX support on 386 arch targets.

Change-Id: If7b1cb6f43233841e917d37a18314d06a334a734
Reviewed-on: https://go-review.googlesource.com/c/go/+/354209
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Martin Möhrmann <martin@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>

cmd/link: keep go.buildid alive on AIX external linking

As we use relative addressing for text symbols in functab, it is
important that the offsets we computed stay unchanged by the
external linker, i.e. all symbols in Textp should not be removed
by the external linker. Most of them are actually referenced (our
deadcode pass ensures that), except go.buildid which is generated
late and not used by the program. Keep it alive.

Should fix AIX builder.

Change-Id: Ibc4a8951be997b9d8d870d75c54754977d9b8333
Reviewed-on: https://go-review.googlesource.com/c/go/+/354369
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/go: do not pass a local prefix to the compiler in module mode

In GOPATH mode, source files may import other packages using relative
(“local”) paths. In module mode, relative imports are never allowed:
import paths must always be fully specified.

When local imports are allowed, we pass a local-import prefix to the
compiler using the '-D' flag. That could theoretically change the
compiler's output, so it must be included in the cache key even when
-trimpath is set. (TODO: when -trimpath is set, the local-import
prefix ought to be trimmed anyway, so it still shouldn't matter.)

However, when local imports are disallowed, we should not pass the
local-import prefix and it should not affect cmd/go's cache key or the
final build ID of any artifact.

For #48557

Change-Id: I2d627d67d13e5da2cac6d411cd4e2d87e510876c
Reviewed-on: https://go-review.googlesource.com/c/go/+/352810
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

all: update golang.org/x/net to pull in CL 353390

Fixes #48564.
Fixes #23559.

Change-Id: I8e0b646c4791d3a6fb17df1af0a7175b68ce8983
Reviewed-on: https://go-review.googlesource.com/c/go/+/353870
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

internal/fuzz: log average execs/sec since last log

This change also fixes a bug with calculating the
total interesting count. When fuzzing with an empty
corpus, the fuzzing engine adds an starting corpus
value in that run in order to start fuzzing. That
meant that the interesting total count was off by one:
it would start at 1, even though the cache was empty.
Added some tests for this as well.

Fixes #48787

Change-Id: I47acf96f0a0797214ebb24a95366d8460bf303bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/354150
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>

all: use bytes.Cut, strings.Cut

Many uses of Index/IndexByte/IndexRune/Split/SplitN
can be written more clearly using the new Cut functions.
Do that. Also rewrite to other functions if that's clearer.

For #46336.

Change-Id: I68d024716ace41a57a8bf74455c62279bde0f448
Reviewed-on: https://go-review.googlesource.com/c/go/+/351711
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>

bytes, strings: add Cut

Using Cut is a clearer way to write the vast majority (>70%)
of existing code that calls Index, IndexByte, IndexRune, and SplitN.
There is more discussion on https://golang.org/issue/46336.

Fixes #46336.

Change-Id: Ia418ed7c3706c65bf61e1b2c5baf534cb783e4d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/351710
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>

cmd/compile: inline memequal(x, const, sz) for small sizes

This CL adds late expanded memequal(x, const, sz) inlining for 2, 4, 8
bytes size. This PoC is using the same method as CL 248404.
This optimization fires about 100 times in Go compiler (1675 occurrences
reduced to 1574, so -6%).
Also, added unit-tests to codegen/comparisions.go file.

Updates #37275

Change-Id: Ia52808d573cb706d1da8166c5746ede26f46c5da
Reviewed-on: https://go-review.googlesource.com/c/go/+/328291
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Trust: David Chase <drchase@google.com>

cmd/compile: improve PPC64 rules for AtomicLoad{8,32}

This adds a rule to avoid the zero extension after an AtomicLoad8
or AtomicLoad32 since the atomic load has already filled it with
zeros. This eliminates an instruction in a high use block in findObject
and the AtomicLoad8 appears many times within runtime.

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