Remove the Interface.IsConstraint, Signature.SetTypeParams, and
Signature.SetRecvTypeParams methods, as they have been replaced and
usage removed from x/tools.
Change-Id: I8786c3cf34e96ab5211cd8e7e6348e9ee792b843
Reviewed-on: https://go-review.googlesource.com/c/go/+/353570
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 changes a rule in PPC64.rules to fix a failure in
test/issue45344.go when regabi is enabled.
Change-Id: I98baf2ae92c766b7276b0f3167b2e6fef37dfe84
Reviewed-on: https://go-review.googlesource.com/c/go/+/353789
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
CALL and JMP on riscv64 are currently implemented as an AUIPC+JALR pair. This means
that every call requires two instructions and makes use of the REG_TMP register,
even when the symbol would be directly reachable via a single JAL instruction.
Add support for call trampolines - CALL and JMP are now implemented as a single JAL
instruction, with the linker generating trampolines in the case where the symbol is
not reachable (more than +/-1MiB from the JAL instruction), is an unknown symbol or
does not yet have an address assigned. Each trampoline contains an AUIPC+JALR pair,
which the relocation is applied to.
Due to the limited reachability of the JAL instruction, combined with the way that
the Go linker currently assigns symbol addresses, there are cases where a call is to
a symbol that has no address currently assigned. In this situation we have to assume
that a trampoline will be required, however we can patch this up during relocation,
potentially calling directly instead. This means that we will end up with trampolines
that are unused. In the case of the Go binary, there are around 3,500 trampolines of
which approximately 2,300 are unused (around 9200 bytes of machine instructions).
Overall, this removes over 72,000 AUIPC instructions from the Go binary.
Change-Id: I2d9ecfb85dfc285c7729a3cd0b3a77b6f6c98be0
Reviewed-on: https://go-review.googlesource.com/c/go/+/345051
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The golang.org/x/net/route package can't parse the RIB returned
by NET_RT_IFLISTL. Use the route.RIBTypeInterface constant
instead, leaving the choice of syscall up to the route package.
Fixes#48553.
Change-Id: Ida4bd6e332c0dc6dc871d3a93cfb56c0fbc93e1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/353611
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: Icabef5cf75770ffde012b1fc785a72f53f9b2c46
Reviewed-on: https://go-review.googlesource.com/c/go/+/353669
Trust: Robert Griesemer <gri@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Now that gofmt knows how to format many files in parallel,
there's no need for "go fmt" to have its own parallelism.
Instead of running "gofmt -l -w $file" in parallel with GOMAXPROCS,
simply collect a large list of files and hand it to "gofmt -l -w $files".
The benchmark below was obtained via:
benchcmd -n 10 FmtGorootCmd go fmt cmd
We can see a drastic improvement in system time per call.
This makes sense, as we used to fork+exec one gofmt program per file,
and now we only do that for every thousand or so files.
We also see an increase in peak memory usage and user CPU time.
This seems to be because each gofmt process was very short lived before.
This meant that there was a limit to the total amount of allocations
produced by go/parser and go/printer before the process stopped,
and thus the GC probably didn't kick in most of the time.
Now that each gofmt process formats hundreds or thousands of files,
a lot of those allocations pile up in the same process,
making peak-RSS go higher and piling on garbage for the GC to clean up.
Finally, note that time/op seems largely unchanged.
I did many benchmark runs; some ended up in noise like the one below,
and others gave small wall time speed-ups of 3-4%.
It seems like we get very little wall time benefit,
possibly due to the factors mentioned earlier cancelling each other out.
Overall, it seems worthwhile to not let "go fmt" do its own parallelism,
to keep the tool simpler to understand and maintain going forward.
Plus, the sys-time savings do seem to be the biggest change here.
name old time/op new time/op delta
FmtGorootCmd 850ms ± 4% 842ms ± 6% ~ (p=0.529 n=10+10)
name old user-time/op new user-time/op delta
FmtGorootCmd 7.30s ± 4% 7.67s ± 3% +5.07% (p=0.000 n=10+10)
name old sys-time/op new sys-time/op delta
FmtGorootCmd 1.66s ± 7% 0.43s ±24% -74.08% (p=0.000 n=10+10)
name old peak-RSS-bytes new peak-RSS-bytes delta
FmtGorootCmd 30.1MB ± 4% 199.4MB ±21% +563.03% (p=0.000 n=10+10)
To make use of the already-present "maximum exec arg length limit"
constant in cmd/go/internal, move it to cmd/internal.
Fixes#43566.
Change-Id: If864151d0c851a40bf7138f9864640f15a066d48
Reviewed-on: https://go-review.googlesource.com/c/go/+/353309
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The "curl" binary is already used at several other places inside
the code base, whereas this was the only occurrence of "wget".
Change-Id: I2b9c5c353d08b3ba8289819b4a602c51f1ebd593
GitHub-Last-Rev: abf9485522
GitHub-Pull-Request: golang/go#48718
Reviewed-on: https://go-review.googlesource.com/c/go/+/353401
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Previously if we failed because the context timed out or was canceled,
we returned errCanceled or errTimeout.
Fixes#39178
Change-Id: I11bd7ebfaa7e5775fb05dfbb6b67f8307c8d8697
Reviewed-on: https://go-review.googlesource.com/c/go/+/353400
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
For #31103
Change-Id: I9c0aa64f95f564de31a4c178e3930584d41316bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/353610
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In types1 and for the export format, we were using type param subscripts
coming from types2 (originally for debugging) to provide unique names.
We need unique full-names for type params in types1 to ensure consistent
references to type params in function/method bodies and type params
derived from translation from types2. We also currently need unique
names for type params in importer/iimport.go and gcimporter/iimport.go,
because there are no levels of scoping in the package symbol lookup and
pkgIndex table.
As a step to eliminate the typeparam subscripts (which have no
relation to the source code), we change so that the typeparams' unique
name is just prefixing the type param name with the name of the
enclosing generic function, type, or method.
We now no longer use types2.TypeString in types2-to-types1 translation,
so Typestring can be changed to eliminate the subscript, as needed.
Also, types2.TypeParam.SetId() is no longer needed and is eliminated.
We can decide later if we want to do the further step of adding scoping
to the importer/iimport.go and gcimporter/iimport.go, which could be
used to eliminate the type param "path" prefix from the export format.
Change-Id: I0e37795664be2c2e1869b8f9e93393b83fc56409
Reviewed-on: https://go-review.googlesource.com/c/go/+/353135
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Discard is not really a read operation, and in theory it could
Seek the underlying Reader without actually reading anything,
so an UnreadByte following a Discard is disallowed.
Similarly, although WriteTo usually does end up calling Read on the
underlying buffer, if the underlying Reader implements io.WriterTo it
may instead terminate in a call to WriteTo, without ever buffering or
even seeing the last byte written. (It is conceptually read-like, but
not strictly “a read operation”.)
Fixes#48446
Change-Id: Ide6f2b157332b423486810399f66140c914144e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/351810
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>
Provide an accessor for clients, and don't print the interface
around implicitly wrapped embedded types.
For #48424.
Change-Id: Ib2c76315508fc749ea4337d52e13d17de80e04da
Reviewed-on: https://go-review.googlesource.com/c/go/+/353396
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>
This change enables the relaxed syntax for constraint literals
as proposed in issue #48424 and adds a simple smoke test for
the compiler. (Most of the relevant changes are in the syntax
and types2 package which have more extensive tests for this.)
This makes it possible to experiment with the new syntax while
we contemplate the fate of #48424.
If #48424 is accepted, this change can remain. If #48424 is
not accepted, reverting this CL will remove this feature in
the compiler.
For #48424.
Change-Id: I624fbb37c2f616ee9ad692e17e4fc75c9d5b06e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353389
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
When collecting type parameters, wrap constraint literals of the
form ~T or A|B into interfaces so the type checker doesn't have
to deal with these type set expressions syntactically anywhere
else but in interfaces (i.e., union types continue to appear
only as embedded elements in interfaces).
Since a type constraint doesn't need to be an interface anymore,
we can remove the respective restriction. Instead, when accessing
the constraint interface via TypeParam.iface, wrap non-interface
constraints at that point and update the constraint so it happens
only once. By computing the types sets of all type parameters at
before the end of type-checking, we ensure that type constraints
are in their final form when accessed through the API.
For #48424.
Change-Id: I3a47a644ad4ab20f91d93ee39fcf3214bb5a81f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/353139
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>
This CL permits an arbitrary type as well as the type sets ~T and A|B
in constraint position, without the need of a surrrounding interface.
For instance, the type parameter list
[P interface{ ~map[K]V }, K comparable, V interface{ ~string }]
may be written as
[P ~map[K]V, K comparable, V ~string]
The feature must be enabled explicitly with the AllowTypeSets mode
and is only available if AllowGenerics is set as well.
For #48424.
Change-Id: Ic70bb97a49ff75e67e040853eac10e6aed0fef1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/353133
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>
Change-Id: Id53633477d1c07bce0c5fcbcab079da51076cdf2
Reviewed-on: https://go-review.googlesource.com/c/go/+/353351
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The linker specially handles go.importpath symbols. But the
compiler doesn't actually generate such symbols. Instead, it
generates type..importpath symbols. It is already in the type
section as the name starts with "type.". Also set its alignment
to 1, as it is string data.
Change-Id: I771f5529a0ff41a5bb476b3a02c8cc75729792de
Reviewed-on: https://go-review.googlesource.com/c/go/+/353489
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Set alignment for string symbols in symtab pass, so we don't need
to look at symbol name in symalign in dodata pass. (Ideally we
should not use symbol name like this in symtab pass either, but
we already use the names there anyway.)
Change-Id: I9fd61e0dd0824c50e3d0d7c07f75b967c8654796
Reviewed-on: https://go-review.googlesource.com/c/go/+/353470
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Funcdata like opendefer info and traceback arginfo are varints or
bytes. There is no need to align them.
GC liveness map and inline tree have 32-bit fields, so continue
align them to 4 bytes.
Change-Id: I9d5dd750a926c65a910efe5817f9f5c473019bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/353469
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
We don't need to keep them around in types2.
Switched a couple of uses of NewSignature to NewSignatureType.
Change-Id: I62880c2b49ec82caa9362ed8a798cfc3bcea300e
Reviewed-on: https://go-review.googlesource.com/c/go/+/353397
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Avoid problems with distro scanning by not using files that look like
object files.
For #48548
Change-Id: I4a06d5690d0870d6253f176e510faa5eebf2d057
Reviewed-on: https://go-review.googlesource.com/c/go/+/352450
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
For #33598
Change-Id: If0de906ffa2fcc83bb2a90f9e80a5b29d7667398
Reviewed-on: https://go-review.googlesource.com/c/go/+/353449
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #46281
Change-Id: I1c70ad72a155a39138f120df5b71de61bb01e20c
Reviewed-on: https://go-review.googlesource.com/c/go/+/336931
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
When building for macOS with external linking, we currently use
"xcrun" to invoke "dsymutil" and "strip" tools. That doesn't work
well for cross compilation. Use "CC --print-prog-name" to find the
tool path instead.
Fixes#47316.
Change-Id: Ib30c6494c48bfb6a505dc26fe644ef543d777076
Reviewed-on: https://go-review.googlesource.com/c/go/+/336769
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
On Darwin/ARM64 when external linking, for very large text we
split it into multiple sections. For each section (other than the
first) we create runtime.text.N marker symbols. In CL 316050 I
forgot to add those symbols to the symbol table. This CL does it.
It doesn't actually matter for program execution. But we add them
on ELF when splitting text sections, so we do it here as well.
Also, this makes it easier to tell if we split text sections.
Change-Id: Ida7f8e9431867881e5ee2bc1a2129eeaf83cb878
Reviewed-on: https://go-review.googlesource.com/c/go/+/353209
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently TestPCLine is skipped in short mode. The test builds a
Linux/AMD64 binary, so it makes sense to skip it if we're cross
compiling, as building the runtime takes a while. But if we are
on Linux/AMD64, it will only build a small amount of code, which
isn't really slow. The test runs in 0.14 second on my machine.
I think it is acceptable to run in short mode. Then we'll have
trybot coverage for this test.
Change-Id: If682f88c28050f7daafde35b4f9e59c03b764a35
Reviewed-on: https://go-review.googlesource.com/c/go/+/353330
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>
Go 1.16 and 1.18 table are the same for that part. Accept 1.18
version number in that code.
Fixes#48699.
Change-Id: I44eafa279a94bd06444f61518aedd541b25390fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/353329
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Add doc comment about the time/tzdata package to the time.LoadLocation
function. The time.LoadLocation function was changed in Go 1.15 to add an extra
source that it considers for the time zone database. That location is the
time/tzdata package. It is not easy to discover this behavior because the
documentation for the time package doesn't mention it in the discussion on the
time.LoadLocation function when discussing the different sources. It would be helpful to
describe all possible sources that time.LoadLocation considers when loading the
time zone database, and so I think it would be worthwhile to mention
time/tzdata.
Change-Id: I408fbe188bf9d4ba797e59ec17eb677136d6a9c2
GitHub-Last-Rev: 3dac204326
GitHub-Pull-Request: golang/go#48673
Reviewed-on: https://go-review.googlesource.com/c/go/+/352830
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
/doc/contribute.html now redirects to /doc/contribute.
Change-Id: Ib342d515bf6e74bb5807ce21f8df3d985bc7e490
GitHub-Last-Rev: c491a060da
GitHub-Pull-Request: golang/go#48005
Reviewed-on: https://go-review.googlesource.com/c/go/+/345590
Trust: Cherry Mui <cherryyz@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
The current Go assembler encodes "MOVK $(0<<16|32|48), Rd" as the
same binary with "MOVK $0, Rd", but for arm64 move constant instructions
MOVK, MOVN and MOVZ, "op $0, Rd" and "op $(0<<16|32|48), Rd" have
different semantics. In order not to change the way the assembler
frontend parses constants, this patch adds a check for the zero shifts.
Change-Id: Ia844c419ce49f63605b549e3a2e98d9075dd1cf1
Reviewed-on: https://go-review.googlesource.com/c/go/+/275812
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Now that it no longer depends on the size of a pointer,
we can make it a constant, which simplifies a bit of code.
Change-Id: I1b7c3b1b648da5c8960378a02b9263e2cc902441
Reviewed-on: https://go-review.googlesource.com/c/go/+/352952
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>
The first field of the func data stored by the linker is the
entry PC for the function. Prior to this change, this was stored
as a relocation to the function. Change this to be an offset
relative to runtime.text.
This reduces the number of relocations on darwin/arm64 by about 10%.
It also slightly shrinks binaries:
file before after Δ %
addr2line 3803058 3791298 -11760 -0.309%
api 5140114 5104242 -35872 -0.698%
asm 4886850 4840626 -46224 -0.946%
buildid 2512466 2503042 -9424 -0.375%
cgo 4374770 4342274 -32496 -0.743%
compile 22920530 22769202 -151328 -0.660%
cover 4624626 4588242 -36384 -0.787%
dist 3217570 3205522 -12048 -0.374%
doc 3715026 3684498 -30528 -0.822%
fix 3148226 3119266 -28960 -0.920%
link 6350226 6313362 -36864 -0.581%
nm 3768850 3757106 -11744 -0.312%
objdump 4140594 4127618 -12976 -0.313%
pack 2227474 2218818 -8656 -0.389%
pprof 13598706 13506786 -91920 -0.676%
test2json 2497234 2487426 -9808 -0.393%
trace 10198066 10118498 -79568 -0.780%
vet 6930658 6889074 -41584 -0.600%
total 108055044 107366900 -688144 -0.637%
It should also incrementally speed up binary launching.
This is the first step towards removing enough relocations
that pages that were previously dirtied by the loader may remain clean,
which will offer memory savings useful in constrained environments.
Change-Id: Icfba55e696ba2f9c99c4f179125ba5a3ba4369c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/351463
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>
Use a Go 1.15 executable for the benchmark, because it is handy.
Most of the code paths are shared for Go 1.2+.
Change-Id: Id7ddc76a05d76335108c58ff9f1ab2ff837b7227
Reviewed-on: https://go-review.googlesource.com/c/go/+/353131
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This was useful for debugging while we were developing
the feature, but is now causing extraneous prints that
make the command output difficult to read.
This change also prevents the go command from printing
an extraneous "FAIL" when fuzzing is enabled.
Fixes#48633Fixes#46631
Change-Id: I636e65f305a20f6dcd843e62090ae228741a3725
Reviewed-on: https://go-review.googlesource.com/c/go/+/352892
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
There was a bug in the short-circuit code for and/or added in CL 321490:
it ignored the value passed in by an earlier pipeline.
For #31103
Change-Id: Ic31f4d7cedfe563ef968cbb712ecfb2413c42eb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353130
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Rename some variables in the compiler that were missed in CL 353089.
Change-Id: Ie748fe9b64e584a841d08ff60c439c93aae412d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/353149
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This updates the codegen tests in noextend.go so they are not
dependent on the ABI.
Change-Id: I8433bea9dc78830c143290a7e0cf901b2397d38a
Reviewed-on: https://go-review.googlesource.com/c/go/+/353070
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
There are special flags that must be passed to the
compiler at build time in order to instrument the
testing binary for fuzzing.
One potential option would be to add these flags to
p.Internal.Gcflags inside cmd/go/internal/test. However,
future calls to setToolFlags can cause these flags to
get cleared about before the build starts, removing
virtually all coverage guidance. This change moves the
logic to add the flag deeper down the call stack,
preventing it from being cleared.
Change-Id: I40eadb0cacc18f29cee75379cd9380f9e73bb8da
Reviewed-on: https://go-review.googlesource.com/c/go/+/352511
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Replace the name Environment with Context, as discussed in #47916. Along
the way, fix some stale or inaccurate comments.
The Environment type remains temporarily as an alias for Context, to
allow the x/tools Trybot to pass until dependency on types.Environment
can be removed.
Updates #47916
Change-Id: Iffd069ab0e8adebf4207c8f8891468a64d32b7cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/353089
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Add rule to PPC64.rules to inline runtime.memmove in more cases, as is
done for other target architectures
Updated tests in codegen/copy.go to verify changes are done on
ppc64/ppc64le
Updates #41662
Change-Id: Id937ce21f9b4f4047b3e66dfa3c960128ee16a2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/352054
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>
