golang / go Public

Go back to allowing spaces in types.(*Type).LinkSring().

Delve folks prefer that there are spaces in type names, if needed, since
DWARF expects type names to be "a string representing the name as it
appears in the source program". At this point, it doesn't necessarily
seem worth having a separate function that removes spaces, only for use
when printing the type names in a function/method instantiation.

Most names of function/method instantiations will still not have spaces,
since they most type args are named or builtin types. I confirmed that
we are back to the original definition of LinkString(), except for some
comment changes.

Change-Id: Iab7143f659ddea4f099c6230cb134edf8aaef868
Reviewed-on: https://go-review.googlesource.com/c/go/+/355354
Run-TryBot: Dan Scales <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Trust: Dan Scales <[email protected]>
Reviewed-by: Keith Randall <[email protected]>

Changing type parameter names is not a breaking API change, so we should
not include these names in the output of cmd/api. Instead print a
placeholder '$<index>' wherever type parameters are referenced.

This is valid for cmd/api as there is at most one type parameter list in
scope for any exported declaration. If we ever support method type
parameters, we'll need to revisit this syntax.

Change-Id: I7e677b1dab6ffeb0b79afefdb8d2580bef93891c
Reviewed-on: https://go-review.googlesource.com/c/go/+/355389
Trust: Robert Findley <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>

We can rewrite ANDQ with an immediate fitting in 32bit with an ANDL, which is shorter to encode.

Looking at Go binary itself, before the change there was:

ANDL: 2337
ANDQ: 4476

After the change:

ANDL: 3790
ANDQ: 3024

So we got rid of 1452 ANDQs

This makes the Linux x86_64 binary 0.03% smaller.

There seems to be an impact on performance.

Intel Cascade Lake benchmarks (with perflock):

name                     old time/op    new time/op    delta
BinaryTree17-8              1.91s ± 1%     1.89s ± 1%  -1.22%  (p=0.000 n=21+18)
Fannkuch11-8                2.34s ± 0%     2.34s ± 0%    ~     (p=0.052 n=20+20)
FmtFprintfEmpty-8          27.7ns ± 1%    27.4ns ± 3%    ~     (p=0.497 n=21+21)
FmtFprintfString-8         53.2ns ± 0%    51.5ns ± 0%  -3.21%  (p=0.000 n=20+19)
FmtFprintfInt-8            57.3ns ± 0%    55.7ns ± 0%  -2.89%  (p=0.000 n=19+19)
FmtFprintfIntInt-8         92.3ns ± 0%    88.4ns ± 1%  -4.23%  (p=0.000 n=20+21)
FmtFprintfPrefixedInt-8     103ns ± 0%     103ns ± 0%  +0.23%  (p=0.000 n=20+21)
FmtFprintfFloat-8           147ns ± 0%     148ns ± 0%  +0.75%  (p=0.000 n=20+21)
FmtManyArgs-8               384ns ± 0%     381ns ± 0%  -0.63%  (p=0.000 n=21+21)
GobDecode-8                3.86ms ± 1%    3.88ms ± 1%  +0.52%  (p=0.000 n=20+21)
GobEncode-8                2.77ms ± 1%    2.77ms ± 0%    ~     (p=0.078 n=21+21)
Gzip-8                      168ms ± 1%     168ms ± 0%  +0.24%  (p=0.000 n=20+20)
Gunzip-8                   25.1ms ± 0%    24.3ms ± 0%  -3.03%  (p=0.000 n=21+21)
HTTPClientServer-8         61.4µs ± 8%    59.1µs ±10%    ~     (p=0.088 n=20+21)
JSONEncode-8               6.86ms ± 0%    6.70ms ± 0%  -2.29%  (p=0.000 n=20+19)
JSONDecode-8               30.8ms ± 1%    30.6ms ± 1%  -0.82%  (p=0.000 n=20+20)
Mandelbrot200-8            3.85ms ± 0%    3.85ms ± 0%    ~     (p=0.191 n=16+17)
GoParse-8                  2.61ms ± 2%    2.60ms ± 1%    ~     (p=0.561 n=21+20)
RegexpMatchEasy0_32-8      48.5ns ± 2%    45.9ns ± 3%  -5.26%  (p=0.000 n=20+21)
RegexpMatchEasy0_1K-8       139ns ± 0%     139ns ± 0%  +0.27%  (p=0.000 n=18+20)
RegexpMatchEasy1_32-8      41.3ns ± 0%    42.1ns ± 4%  +1.95%  (p=0.000 n=17+21)
RegexpMatchEasy1_1K-8       216ns ± 2%     216ns ± 0%  +0.17%  (p=0.020 n=21+19)
RegexpMatchMedium_32-8      790ns ± 7%     803ns ± 8%    ~     (p=0.178 n=21+21)
RegexpMatchMedium_1K-8     23.5µs ± 5%    23.7µs ± 5%    ~     (p=0.421 n=21+21)
RegexpMatchHard_32-8       1.09µs ± 1%    1.09µs ± 1%  -0.53%  (p=0.000 n=19+18)
RegexpMatchHard_1K-8       33.0µs ± 0%    33.0µs ± 0%    ~     (p=0.610 n=21+20)
Revcomp-8                   348ms ± 0%     353ms ± 0%  +1.38%  (p=0.000 n=17+18)
Template-8                 42.0ms ± 1%    41.9ms ± 1%  -0.30%  (p=0.049 n=20+20)
TimeParse-8                 185ns ± 0%     185ns ± 0%    ~     (p=0.387 n=20+18)
TimeFormat-8                237ns ± 1%     241ns ± 1%  +1.57%  (p=0.000 n=21+21)
[Geo mean]                 35.4µs         35.2µs       -0.66%

name                     old speed      new speed      delta
GobDecode-8               199MB/s ± 1%   198MB/s ± 1%  -0.52%  (p=0.000 n=20+21)
GobEncode-8               277MB/s ± 1%   277MB/s ± 0%    ~     (p=0.075 n=21+21)
Gzip-8                    116MB/s ± 1%   115MB/s ± 0%  -0.25%  (p=0.000 n=20+20)
Gunzip-8                  773MB/s ± 0%   797MB/s ± 0%  +3.12%  (p=0.000 n=21+21)
JSONEncode-8              283MB/s ± 0%   290MB/s ± 0%  +2.35%  (p=0.000 n=20+19)
JSONDecode-8             63.0MB/s ± 1%  63.5MB/s ± 1%  +0.82%  (p=0.000 n=20+20)
GoParse-8                22.2MB/s ± 2%  22.3MB/s ± 1%    ~     (p=0.539 n=21+20)
RegexpMatchEasy0_32-8     660MB/s ± 2%   697MB/s ± 3%  +5.57%  (p=0.000 n=20+21)
RegexpMatchEasy0_1K-8    7.36GB/s ± 0%  7.34GB/s ± 0%  -0.26%  (p=0.000 n=18+20)
RegexpMatchEasy1_32-8     775MB/s ± 0%   761MB/s ± 4%  -1.88%  (p=0.000 n=17+21)
RegexpMatchEasy1_1K-8    4.74GB/s ± 2%  4.74GB/s ± 0%  -0.18%  (p=0.020 n=21+19)
RegexpMatchMedium_32-8   40.6MB/s ± 7%  39.9MB/s ± 9%    ~     (p=0.191 n=21+21)
RegexpMatchMedium_1K-8   43.7MB/s ± 5%  43.2MB/s ± 5%    ~     (p=0.435 n=21+21)
RegexpMatchHard_32-8     29.3MB/s ± 1%  29.4MB/s ± 1%  +0.53%  (p=0.000 n=19+18)
RegexpMatchHard_1K-8     31.0MB/s ± 0%  31.0MB/s ± 0%    ~     (p=0.572 n=21+20)
Revcomp-8                 730MB/s ± 0%   720MB/s ± 0%  -1.36%  (p=0.000 n=17+18)
Template-8               46.2MB/s ± 1%  46.3MB/s ± 1%  +0.30%  (p=0.041 n=20+20)
[Geo mean]                204MB/s        205MB/s       +0.30%

Change-Id: Iac75d0ec184a515ce0e65e19559d5fe2e9840514
Reviewed-on: https://go-review.googlesource.com/c/go/+/354970
Reviewed-by: Josh Bleecher Snyder <[email protected]>
Trust: Josh Bleecher Snyder <[email protected]>
Trust: Keith Randall <[email protected]>
Run-TryBot: Josh Bleecher Snyder <[email protected]>
TryBot-Result: Go Bot <[email protected]>

Change-Id: Ib7cc86643a3dcae788a94472e54de171e0d655fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/355449
Trust: Michael Pratt <[email protected]>
Trust: Keith Randall <[email protected]>
Run-TryBot: Michael Pratt <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Michael Pratt <[email protected]>

Fixes #48928

Change-Id: I3825ec615ab5fc19389ef4c10ad1042005a3761c
Reviewed-on: https://go-review.googlesource.com/c/go/+/355450
Trust: Katie Hockman <[email protected]>
Run-TryBot: Katie Hockman <[email protected]>
Reviewed-by: Jay Conrod <[email protected]>
TryBot-Result: Go Bot <[email protected]>

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 <[email protected]>
Run-TryBot: Bryan C. Mills <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>

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 <[email protected]>
Run-TryBot: Dan Scales <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Keith Randall <[email protected]>
Reviewed-by: Matthew Dempsky <[email protected]>

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 <[email protected]>
Trust: Katie Hockman <[email protected]>
Trust: Bryan C. Mills <[email protected]>
Run-TryBot: Jay Conrod <[email protected]>
Run-TryBot: Katie Hockman <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Katie Hockman <[email protected]>

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 <[email protected]>
Run-TryBot: Dan Scales <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Keith Randall <[email protected]>

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 <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>

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 <[email protected]>
Run-TryBot: Jay Conrod <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Bryan C. Mills <[email protected]>

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 <[email protected]>
Run-TryBot: Cherry Mui <[email protected]>
Reviewed-by: Cuong Manh Le <[email protected]>
Reviewed-by: David Chase <[email protected]>
TryBot-Result: Go Bot <[email protected]>

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 <[email protected]>
Run-TryBot: Katie Hockman <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Jay Conrod <[email protected]>

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 <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
Reviewed-by: Lynn Boger <[email protected]>

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 <[email protected]>
Run-TryBot: Nigel Tao <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Andrew Gerrand <[email protected]>

… 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 <[email protected]>
Run-TryBot: Tobias Klauser <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>

Fixes #48706

Change-Id: If0f8d0b49300027e3b2b46f6870302acf2e00f4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/354612
Trust: Ian Lance Taylor <[email protected]>
Run-TryBot: Ian Lance Taylor <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>
TryBot-Result: Go Bot <[email protected]>

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 <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>

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 <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>

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 <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>

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 <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>

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 <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>

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í <[email protected]>
Run-TryBot: Daniel Martí <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Rob Pike <[email protected]>

…/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 <[email protected]>
Run-TryBot: Dan Scales <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Keith Randall <[email protected]>

…clude 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 <[email protected]>
Run-TryBot: Bryan C. Mills <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Jay Conrod <[email protected]>

… 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 <[email protected]>
Reviewed-by: Keith Randall <[email protected]>

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 <[email protected]>
Run-TryBot: Dmitri Shuralyov <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
TryBot-Result: Go Bot <[email protected]>

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 <[email protected]>
Reviewed-by: Lynn Boger <[email protected]>

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 <[email protected]>
Trust: Josh Bleecher Snyder <[email protected]>
Reviewed-by: Josh Bleecher Snyder <[email protected]>

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 <[email protected]>
Trust: Josh Bleecher Snyder <[email protected]>
Run-TryBot: Cherry Mui <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Josh Bleecher Snyder <[email protected]>

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 <[email protected]>
Reviewed-by: Tobias Klauser <[email protected]>

…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 <[email protected]>
Run-TryBot: Russ Cox <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Rob Pike <[email protected]>

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 <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>

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 <[email protected]>
Run-TryBot: Cherry Mui <[email protected]>
Run-TryBot: Lynn Boger <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Trust: Lynn Boger <[email protected]>

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 <[email protected]>
Trust: Josh Bleecher Snyder <[email protected]>
Run-TryBot: Keith Randall <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Josh Bleecher Snyder <[email protected]>