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 <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
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>
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>
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>
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>
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#48716Fixes#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>
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>
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>
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>
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>
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>
The TestStartsWithClearCode test is new, but if it existed beforehand,
the want strings would be "\x81" and "Hi\x81" without a starting "\x80".
Fixes#26108Fixes#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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
