Clean up and consolidate on a single consistent definition of fcntl,
which takes three int32 arguments and returns either a positive result
or a negative errno value.
Change-Id: Id9505492712db4b0aab469c6bd15e4fce3c9ff6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/495075
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
At least when we're inserting/replacing near the end of a slice, when
we have to grow it use the same multiplicative growth factor that the
runtime uses for append.
Before this CL, we would grow the slice one page (8192 bytes) at a time
for large slices. This would cause O(n^2) work when appending near the
end should only take O(n) work.
This doesn't fix the problem if you insert/replace near the start of the
array, but maybe that doesn't need fixing because it is O(n^2) anyway.
Fixes#60134
Change-Id: If05376bc512ab839769180e5ce4cb929f47363b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/495296
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Handle cases where the inserted slice is actually part of the slice
that is being inserted into.
Requires a bit more work, but no more allocations. (Compare to #494536.)
Not entirely sure this is worth the complication.
Fixes#60138
Change-Id: Ia72c872b04309b99025e6ca5a4a326ebed2abb69
Reviewed-on: https://go-review.googlesource.com/c/go/+/494817
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL changes Checker.genericExprList such that it collects partially
instantiated generic functions together with their (partial) type
argument (and corresponding) expression lists, instead of trying to
infer the missing type arguments in place or to report an error.
Special care is being taken to explictly record expression types where
needed (because we can't use one of the usual expr evaluators which
takes care of that), or to track the correct instance expression for
later recording with Checker.arguments.
The resulting generic expression list is passed to Checker.arguments
which is changed to accept explicit partial type argument (and
corresponding) expression lists. The provided type arguments are fed
into type inference, matching up with their respective type parameters
(which were collected already, before this CL). If type inference is
successful, the instantiated functions are recorded as needed.
For now, the type argument expression lists are collected and passed
along but not yet used. We may use them eventually for better error
reporting.
Fixes#59958.
For #59338.
Change-Id: I26db47ef3546e64553da49d62b23cd3ef9e2b549
Reviewed-on: https://go-review.googlesource.com/c/go/+/494116
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
There's only two places which call Checker.arguments: Checker.callExpr
and Checker.builtin. Both ensure that the passed argument list doesn't
contain type expressions, so we don't need that extra check at the start
of Checker.arguments.
The remaining check causes Checker.arguments to exit early if any of
the passed arguments is invalid. This reduces the number of reported
errors in rare cases but is executed all the time.
If the extra errors are a problem, it would be better to not call
Checker.arguments in the first place, or only do the extra check
before Checker.arguments reports an error.
Removing this code for now. Removes a long-standing TODO.
Change-Id: Ief654b680eb6b6a768bb1b4c621d3c8169953f17
Reviewed-on: https://go-review.googlesource.com/c/go/+/495395
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
With the exception of the shortcircuit pass, removePhiArg is always unconditionally followed by phiElimValue.
Move the phiElimValue inside removePhiArg.
Resolves a TODO.
See CL 357964 for more info.
Change-Id: I8460b35864f4cd7301ba86fc3dce08ec8041da7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/465435
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Jakub Ciolek <jakub@ciolek.dev>
With CL 408826, CL 413474, etc. reflect.ValueOf no longer
unconditionally escapes its argument, allowing a Value's content
to be allocated on the stack.
Change-Id: I3a0af85c11e2fd0df42b056095565f0ce5548886
Reviewed-on: https://go-review.googlesource.com/c/go/+/494657
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
In the types1 universe, we only need to represent value types. For
interfaces, this means we only need to worry about pure interfaces. A
pure interface can embed a union type, but the overall union must be
equivalent to "any".
In go.dev/cl/458619, we changed the types1 reader to return "any", but
to incorporate a consistency check to make sure this is valid.
Unfortunately, a pure interface can actually still reference impure
interfaces, and in general this is hard to check precisely without
reimplementing a lot of types2 data structures and logic into types1.
We haven't had any other reports of this check failing since 1.20, so
it seems simplest to just suppress for now.
Fixes#60117.
Change-Id: I5053faafe2d1068c6d438b2193347546bf5330cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/495455
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
running on cmd/compile/internal/testdata/inlines now shows:
```
--- change set #1 (enabling changes causes failure)
b/b.go:16:6: loop variable i now per-iteration (loop inlined into b/b.go:10)
b/b.go:16:6: loop variable i now per-iteration
./b/b.go:16:6: loop variable b.i now per-iteration (loop inlined into a/a.go:18)
./b/b.go:16:6: loop variable b.i now per-iteration (loop inlined into ./main.go:37)
./b/b.go:16:6: loop variable b.i now per-iteration (loop inlined into ./main.go:38)
---
```
and
```
--- change set #2 (enabling changes causes failure)
./main.go:27:6: loop variable i now per-iteration
./main.go:27:6: loop variable i now per-iteration (loop inlined into ./main.go:35)
---
```
Still unsure about the utility of mentioning the inlined occurrence, but better
than mysteriously repeating the line over and over again.
Change-Id: I357f5d419ab4928fa316f4612eec3b75e7f8ac34
Reviewed-on: https://go-review.googlesource.com/c/go/+/494296
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: David Chase <drchase@google.com>
Specifically, objects built via cgo using CGO_CFLAGS="-O2 -g -mcpu=power10".
These use new relocations defined by ELFv2 1.5, and the R_PPC64_REL24_NOTOC
relocation. These objects contain functions which may not use a TOC
pointer requiring the insertion of trampolines to use correctly.
The relocation targets of these ELFv2 objects may also contain non-zero
values. Clear the relocated bits before setting them.
Extra care is taken if GOPPC64 < power10. The R_PPC64_REL24_NOTOC reloc
existed prior to ELFv2 1.5. The presence of this relocation itself does
not imply a power10 target. Generate power8 compatible stubs if
GOPPC64 < power10.
Updates #44549
Change-Id: I06ff8c4e47ed9af835a7dcfbafcfa4c538f75544
Reviewed-on: https://go-review.googlesource.com/c/go/+/492617
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Be more liberal about expanding the OR tree. Handle any tree shape
instead of a fully left or right associative tree.
Also remove tail feature, it isn't ever needed.
Change-Id: If16bebef94b952a604d6069e9be3d9129994cb6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/494056
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ryan Berger <ryanbberger@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
It's possible that the replacement for a built-in attribute is a Group.
That would cause a nil pointer exception because the handleState.prefix
field isn't set until later, in appendNonBuiltIns.
So create the prefix field earlier, at the start of commonHandler.handle.
Once we do this, we can simplify the code by creating and freeing the
prefix in newHandleState.
Along the way I discovered a line that wasn't being tested:
state.prefix.WriteString(h.groupPrefix)
so I modified an existing test case to cover it.
Change-Id: Ib385e3c13451017cb093389fd5a1647d53e610bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/494037
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This improves memclr for the last few bytes when
compiling for power9 or earlier.
Change-Id: I46940ebc7e98e27a2e48d4b319acb7d2106a6f29
Reviewed-on: https://go-review.googlesource.com/c/go/+/495035
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This introduces the concept of test variants in dist, which are
different configurations of the same package. The variant of a test is
a short string summarizing the configuration.
The "variant name" of a test is either the package name if the variant
is empty, or package:variant if not. Currently this isn't used for
anything, but soon we'll use this as the Package field of the test
JSON output so that we can disambiguate output from differently
configured runs of the same test package, and naturally flow this
through to any test result viewer.
The long-term plan is to use variant names as dist's own test names
and eliminate the ad hoc names it has right now. Unfortunately, the
build coordinator is aware of many of the ad hoc dist test names, so
some more work is needed to get to that point. This CL keeps almost
all test names the same, with the exception of tests registered by
registerCgoTests, where we regularize test names a bit using variants
to avoid some unnecessary complexity (I believe nothing depends on the
names of these tests).
For #37486.
Change-Id: I119fec2872e40b12c1973cf2cddc7f413d62a48c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495016
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently the cgo tests mostly use their package name as a heading,
which means we get a large number of test sections that each have a
single test package in them.
Unify them all under "Testing cgo" to reduce output noise.
This leaves just the cmd/api test without a heading, so we give it a
heading and require that all tests have a heading.
Change-Id: I24cd9a96eb35bbc3ff9335ca8a382ec2426306c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/494497
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Currently, there are four places that add distTests to the
tester.tests list. That means we're already missing a few name
uniqueness checks, and we're about to start enforcing some more
requirements on tests that would be nice to have in one place. Hence,
to prepare for this, this CL refactors the process of adding to the
tester.tests list into a method. That also means we can trivially use
a map to check name uniqueness rather than an n^2 slice search.
For #37486.
Change-Id: Ib7b64c7bbf65e5e870c4f4bfaca8c7f70983605c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495015
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
[This is a roll-forward of CL 458755, which was reverted due to make.bash
being broken on GOAMD64=v3. But it turned out that the problem was caused
by wrong bswap/load rewrite rules, and it was fixed in CL 492616.]
This CL enhances the tighten pass. Previously if a value has memory arg,
then the tighten pass won't move it, actually if the memory state is
consistent among definition and use block, we can move the value. This
CL optimizes this case. This is useful for the following situation:
b1:
x = load(...mem)
if(...) goto b2 else b3
b2:
use(x)
b3:
some_op_not_use_x
For the micro-benchmark mentioned in #56620, the performance improvement
is about 15%.
There's no noticeable performance change in the go1 benchmark.
Fixes#56620
Change-Id: I36ea68bed384986cd3ae81cb9e6efe84bb213adc
Reviewed-on: https://go-review.googlesource.com/c/go/+/492895
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
This edge case was accidentally broken by CL 219638.
Change-Id: I673b3b580fbe379a04f8650cf5969fe9bce83691
Reviewed-on: https://go-review.googlesource.com/c/go/+/495036
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This modifies some existing rules to allow more prefixed instructions
to be generated when using GOPPC64=power10. Some rules also check
if PCRel is available, which is currently supported for linux/ppc64le
and linux/ppc64 (internal linking only).
Prior to p10, DS-offset loads and stores had a 16 bit size limit for
the offset field. If the offset of the data for load or store was
beyond this range then an indexed load or store would be selected by
the rules.
In p10 the assembler can generate prefixed instructions in this case,
but does not if an indexed instruction was selected during the lowering
pass.
This allows many more cases to use prefixed loads or stores, reducing
function sizes and improving performance in some cases where the code
change happens in key loops.
For example in strconv BenchmarkAppendQuoteRune before:
12c5e4: 15 00 10 06 pla r10,1425660
12c5e8: fc c0 40 39
12c5ec: 00 00 6a e8 ld r3,0(r10)
12c5f0: 10 00 aa e8 ld r5,16(r10)
After this change:
12a828: 15 00 10 04 pld r3,1433272
12a82c: b8 de 60 e4
12a830: 15 00 10 04 pld r5,1433280
12a834: c0 de a0 e4
Performs better in the second case.
A testcase was added to verify that the rules correctly select a load or
store based on the offset and whether power10 or earlier.
Change-Id: I4335fed0bd9b8aba8a4f84d69b89f819cc464846
Reviewed-on: https://go-review.googlesource.com/c/go/+/477398
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
Prior to Go 1.19 adding support for sending 1xx informational headers
with ResponseWriter.WriteHeader, WriteHeader(101) would send a 101
status and disable further writes to the response. This behavior
was not documented, but is intentional: Writing to the response
body explicitly checks to see if a 101 status has been sent before
writing.
Restore the pre-1.19 behavior when writing a 101 Switching Protocols
header: The header is sent, no subsequent headers are sent, and
subsequent writes to the response body fail.
For #59564
Change-Id: I72c116f88405b1ef5067b510f8c7cff0b36951ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/485775
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
According to the ResponseWriter documentation:
To suppress automatic response headers (such as "Date"), set
their value to nil.
In some cases, this documentation is incorrect: chunkWriter writes
a Content-Length header even if the value was set to nil. Meaning
there is no way to suppress this header.
This patch replaces the empty string comparison with a call to
`header.has` which takes into account nil values as expected.
This is similar to the way we handle the "Date" header.
Change-Id: Ie10d54ab0bb7d41270bc944ff867e035fe2bd0c5
GitHub-Last-Rev: e0616dd463
GitHub-Pull-Request: golang/go#58578
Reviewed-on: https://go-review.googlesource.com/c/go/+/469095
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Run-TryBot: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
When importing a package that does not exist, it would show goroot error
message and path. We would like to replace goroot with std instead.
Fixes#56965.
Change-Id: I86f8a7fab6555b68f792a3a4686de20d51eced8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/453895
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This appears to be a very old wrapper around adb for testing on
Android before we had the go_android_exec wrapper.
Change-Id: I847bb15c98febbcffc063f00719a084e5c99a18b
Reviewed-on: https://go-review.googlesource.com/c/go/+/493604
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The build tag on this file is currently unsatisfiable. It was clearly
supposed to be "linux || freebsd || openbsd", but the test doesn't
actually compile on FreeBSD or OpenBSD because they don't define
SYS_gettid. Change the build tag to just "linux".
Change-Id: Ifaffac5438e1b94a8588b5a00435461aa171a6fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/493603
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Windows UTF-16 strings can contain unpaired surrogates, which can't be
decoded into a valid UTF-8 string. This file defines a set of functions
that can be used to encode and decode potentially ill-formed UTF-16
strings by using the
[the WTF-8 encoding](https://simonsapin.github.io/wtf-8/).
WTF-8 is a strict superset of UTF-8, i.e. any string that is
well-formed in UTF-8 is also well-formed in WTF-8 and the content
is unchanged. Also, the conversion never fails and is lossless.
The benefit of using WTF-8 instead of UTF-8 when decoding a UTF-16
string is that the conversion is lossless even for ill-formed
UTF-16 strings. This property allows to read an ill-formed UTF-16
string, convert it to a Go string, and convert it back to the same
original UTF-16 string.
Fixes#59971
Change-Id: Id6007f6e537844913402b233e73d698688cd5ba6
Reviewed-on: https://go-review.googlesource.com/c/go/+/493036
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Paul Hampson <Paul.Hampson@Pobox.com>
This incorporates the changes from CL 453603 and CL 416178.
Please review carefully: I did my best to read through the CLs, but
I'm not entirely confident I haven't made a mistake.
Fixes#59770.
Change-Id: Ib8937e55dcd11e3f75c16b28519d3d91df1d4da3
Reviewed-on: https://go-review.googlesource.com/c/go/+/492596
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
The existing way of checking for supported linker flags causes false negatives
when there are relative paths passed to go tool link. This fixes the issue by
calling the external linker in the current working directory, instead of
in a temporary directory.
Fixes#59952
Change-Id: I173bb8b44902f30dacefde1c202586f87667ab70
Reviewed-on: https://go-review.googlesource.com/c/go/+/491796
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
It was my oversight in CL 463276 to skip registerStdTestSpecially
packages in the race bench test registration loop. Package testdir
has no benchmarks and doesn't need to be skipped. (And if it had
benchmarks, it's very unlikely they'd need any special handling.)
By now there are more cmd/cgo/internal/... packages that are registered
specially, and there isn't a need for their few benchmarks not to be
used for the purpose of race bench tests. If the 3 benchmarks in
cmd/cgo/internal/test were to require something special, then we can
add it to a new registerRaceBenchTestSpecially map with a comment, and
do register them specially in registerTests instead of forgetting to.
This restores the automatic 'go_test_bench:cmd/cgo/internal/test'
registration and reduces prevalence of registerStdTestSpecially a bit.
For #37486.
For #56844.
Change-Id: I1791fe5bf94cb4b4e0859c5fff4e7a3d5a23723e
Reviewed-on: https://go-review.googlesource.com/c/go/+/494656
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
With CL 408826 reflect.Value does not always escape. We need to
make sure Value operations does (or does not) escape the Value
correctly. This CL adds a test.
There are still a few unfortunate cases, where some Value
operations escape more than necessary (comparing to a non-reflect
version of the code), but hard to fix. These are mostly that a
Value would escape conditionally (mostly on the type of the Value),
but currently we don't have a good way to express that.
Change-Id: I9fdfc7584670aa09c5a01f6b2803f2043aaddb65
Reviewed-on: https://go-review.googlesource.com/c/go/+/441938
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Clean up instances that are unused since CL 6450058.
Change-Id: I0e9ae28cfa83fcc8abda8f5eca9c7dfc2c1c4ad1
Reviewed-on: https://go-review.googlesource.com/c/go/+/477396
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Bypass: Ian Lance Taylor <iant@golang.org>
With CL 408826 reflect.Value not always escape. IsZero still
escapes the Value because in some cases it passes the Value
pointer to the equal function, which is function pointer. Equal
functions are compiler generated and never escapes, but the escape
analysis doesn't know. Add noescape to help.
Change-Id: Ica397c2be77cac9e8a46d03d70bac385b0aa9e82
Reviewed-on: https://go-review.googlesource.com/c/go/+/441937
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Types are either static (for compiler-created types) or heap
allocated and always reachable (for reflection-created types, held
in the central map). So there is no need to escape types.
With CL 408826 reflect.Value does not always escape. Some functions
that escapes Value.typ would make the Value escape without this CL.
Had to add a special case for the inliner to keep (*Value).Type
still inlineable.
Change-Id: I7c14d35fd26328347b509a06eb5bd1534d40775f
Reviewed-on: https://go-review.googlesource.com/c/go/+/413474
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, reflect.ValueOf forces the referenced object to be heap
allocated. This CL makes it possible to be stack allocated. We
need to be careful to make sure the compiler's escape analysis can
do the right thing, e.g. channel send, map assignment, unsafe
pointer conversions.
Tests will be added in a later CL.
CL 408827 might help ensure the correctness.
Change-Id: I8663651370c7c8108584902235062dd2b3f65954
Reviewed-on: https://go-review.googlesource.com/c/go/+/408826
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The RedirectEdges logic is fragile and not quite complete (doesn't
update in-edges), which adds overhead to maintaining this package.
In my opinion, the post-inlining graph doesn't provide as much value as
the pre-inlining graph. Even the latter I am not convinced should be in
the compiler rather than an external tool, but it is comparatively
easier to maintain.
Drop it for now. Perhaps we'll want it back in the future for tracking
follow-up optimizations, but for now keep things simple.
Change-Id: I3133a2eb97893a14a6770547f96a3f1796798d17
Reviewed-on: https://go-review.googlesource.com/c/go/+/494655
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Actual PGO operation doesn't use these weights at all. They are
theoretically used when printing a dot graph for debugging, but that
doesn't actually work because these weights are always zero.
These fields are initialized by looking for a NodeMap entry with key
{CallerName: sym, CalleeName: "", CallSiteOffset: 0}. These entries will
never exist, as we never put entries in NodeMap without CalleeName.
Since they aren't really used and don't work, just remove them entirely,
which offers nice simplification.
This leaves IRNode with just a single field. I keep the type around as a
future CL will make the *ir.Func optional, allowing nodes with a name
but no IR.
Change-Id: I1646654cad1d0779ce071042768ffad2a7e6ff49
Reviewed-on: https://go-review.googlesource.com/c/go/+/494616
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
The primary branch of the github.com/unicode-org/cldr repository
has changed to main instead of master. This changes the branch used
to download the Windows zone file.
Ran:
go generate time
For #58113
Change-Id: Idb3dcaf44fc52d4b6abfed5a3ca6cd6f745dc3f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/493477
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
This test package uses syscall.SIGSEGV and syscall.SIGPIPE, which are
defined on most, but not all platforms. Normally this test runs as
part of dist test, which only registers this test on platforms that
support c-archive build mode, which includes all platforms that define
these signals. But this doesn't help if you're just trying to type
check everything in cmd.
Add build constraints so that this package type checks on all
platforms.
Fixes#60164.
Updates #37486.
Change-Id: Id3f9ad4cc9f80146de16aedcf85d108a77215ae6
Reviewed-on: https://go-review.googlesource.com/c/go/+/494659
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test package uses the Pdeathsig field of syscall.SysProcAttr,
which is only available on a few platforms. Currently, dist test
checks for compatible platforms and only registers it as part of
all.bash on platforms where it can build. But this doesn't help if
you're just trying to type check everything in cmd.
Make this package pass type checking by moving the condition from dist
into build tags on the test package itself.
For #60164.
Updates #37486.
Change-Id: I58b12d547c323cec895320baa5fca1b82e99d1b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/494658
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
There was a bug in forceCgoDNS (CL 479416), it was fixed by CL 487196, so
add a test case for it.
Change-Id: I2010374451ef236dc2898d9e9ea006eb8b40d02e
GitHub-Last-Rev: 34a84fad33
GitHub-Pull-Request: golang/go#59922
Reviewed-on: https://go-review.googlesource.com/c/go/+/491255
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This test is configured to run only when explicitly requested due to
being costly. Apply two updates so it can run on the toolchain today:
- overlay GOROOT/lib for zoneinfo.zip (similarly to CL 462279)
- stop expecting framepointer to be listed in the GOEXPERIMENT
section of the compiler version (see CL 49252 and CL 249857)
I checked if by now there's another test that would report a problem
if the fix made in CL 186200 had regressed. Running all.bash locally
with GO_TEST_SHORT=0 GO_BUILDER_NAME=darwin-arm64-longtest passed ok,
while this manual test did catch the problem.
Also simplify the test implementation while here so it's less different
from TestRepeatBootstrap.
For #33091.
Change-Id: I14eea18c19c2e8996bcba31c80e03dcf679f56ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/493475
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Currently, in workspace mode, the -modfile flag affects all the modules
listed in the go.work file. This is not desirable most of the time. And
when it results in an error, the error message does not help.
For example, when there are more than one modules listed in the go.work
file, running "go list -m -modfile=path/to/go.mod" gives this error:
go: module example.com/foo appears multiple times in workspace
This change reject -modfile flag explicitly with this error message:
go: -modfile cannot be used in workspace mode
While at here, correct some typos in the modload package.
Fixes#59996.
Change-Id: Iff4cd9f3974ea359889dd713a747b6932cf42dfd
GitHub-Last-Rev: 7dbc9c3f2f
GitHub-Pull-Request: golang/go#60033
Reviewed-on: https://go-review.googlesource.com/c/go/+/493315
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
