CL 507975 resulted in new data races (as reported in #61212), because
the pkg argument to NewChecker was mutated.
Fix this by deferring the recording of the goVersion in pkg until type
checking is actually initiated via a call to Checker.Files.
Additionally, modify types2/check.go to bring it in sync with the
changes in go/types/check.go, and generate the new version_test.go from
the types2 file.
Also move parsing the version into checkFiles, for simplicity.
Fixes#61212
Change-Id: I15edb6c2cff3085622fe7c6a3b0dab531d27bd04
Reviewed-on: https://go-review.googlesource.com/c/go/+/508439
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Handlers should not display empty groups.
A group with no attributes is certainly empty. But we also want to
consider a group to be empty if all its attributes are empty groups.
The built-in handlers did not handle this second case properly.
This CL fixes that.
There are two places in the implementation that we need to consider.
For Values of KindGroup, we change the GroupValue constructor to omit
Attrs that are empty groups. A Group is then empty if and only if it
has no Attrs. This avoids a recursive check for emptiness.
It does require allocation, but that doesn't worry us because Group
values should be relatively rare.
For groups established by WithGroup, we avoid opening such groups
unless the Record contains non-empty groups. As we did for values, we
avoid adding empty groups to records in the first place, so we only
need to check that the record has at least one Attr.
We are doing extra work, so we need to make sure we aren't slowing
things down unduly. Benchmarks before and after this change show
minimal differences.
Fixes#61067.
Change-Id: I684c7ca834bbf69210516faecae04ee548846fb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/508436
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When building programs to GOOS=wasip1, the program does not have the
guarantees that the underlying directories will come from a file system
where a zero inode value indicates that the entry was deleted but not
yet removed from the directory. The host runtime may be running on
windows or may be exposing virtual user-space file systems that do not
have the concept of inodes. In those setup, we assume that the host
runtime is in charge of dealing with edge cases such as skipping
directory entries with zero inodes when needed, and the guest
application should trust the list of entries that it sees;
therefore, we disable skipping over zero inodes on wasip1.
Change-Id: I99aa562441cdb4182965f270af054cf3cf7f8f20
Reviewed-on: https://go-review.googlesource.com/c/go/+/507915
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
When invoking a vet tool with -vettool (or vet itself),
we need to pass the package's GoVersion to use when
analyzing the package.
The test of this behavior is in the x/tools/go/analysis CL 507880.
For #61176.
Change-Id: I3b5a90fcd19a0adc7fb29366e106e18f722fc061
Reviewed-on: https://go-review.googlesource.com/c/go/+/507976
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Clients of go/types, such as analyzers, may need to know which
specific Go version a package is written for. Record that information
in the Package and expose it using the new GoVersion method.
Update parseGoVersion to handle the new Go versions that may
be passed around starting in Go 1.21.0: versions like "go1.21.0"
and "go1.21rc2". This is not strictly necessary today, but it adds some
valuable future-proofing.
While we are here, change NewChecker from panicking on invalid
version to saving an error for returning later from Files.
Go versions are now likely to be coming from a variety of sources,
not just hard-coded in calls to NewChecker, making a panic
inappropriate.
For #61174.
Fixes#61175.
Change-Id: Ibe41fe207c1b6e71064b1fe448ac55776089c541
Reviewed-on: https://go-review.googlesource.com/c/go/+/507975
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Adds an optional close quote in the expected log message regex for TestConnections to prevent failing when the source filepath is surrounded in quotes due to it containing one or more spaces.
Fixes#61161
Change-Id: I0dd71fb4389bff963bbfdc668ef4e4dfe787eafc
Reviewed-on: https://go-review.googlesource.com/c/go/+/508055
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
According to RISCV manual 11.6:
FMADD x,y,z computes x*y+z and
FNMADD x,y,z => -x*y-z
FMSUB x,y,z => x*y-z
FNMSUB x,y,z => -x*y+z respectively
However our implement of SSA convert FMADD -x,y,z to FNMADD x,y,z which
is wrong and should be convert to FNMSUB according to manual.
Change-Id: Ib297bc83824e121fd7dda171ed56ea9694a4e575
Reviewed-on: https://go-review.googlesource.com/c/go/+/506575
Run-TryBot: M Zhuo <mzh@golangcn.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
Reviewed-by: Michael Munday <mike.munday@lowrisc.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 497675 modified Rows such that context errors are propagated through
Rows.Err(). This caused an issue where calling Close meant that an
internal cancellation error would (eventually) be returned from Err:
1. A caller makes a query using a cancellable context.
2. initContextClose sees that either the query context or the
transaction context can be canceled, so will need to spawn a
goroutine to capture their errors.
3. initContextClose derives a context from the query context via
WithCancel and sets rs.cancel.
4. When a user calls Close, rs.cancel is called. awaitDone's ctx is
cancelled, which is good, since we don't want it to hang forever.
5. This internal cancellation (after CL 497675) has its error saved on
contextDone.
6. Later, calling Err will return the error in contextDone if present.
This leads to a race condition depending on how quickly Err is called
after Close.
The docs for Close and Err state that calling Close should have no
affect on the return result for Err. So, a potential fix is to ensure
that awaitDone does not save the error when the cancellation comes from
a Close via rs.cancel.
This CL does that, using a new context not derived from the query
context, whose error is ignored as the query context's error used to be
before the original bugfix.
The included test fails before the CL, and passes afterward.
Fixes#60932
Change-Id: I2bf4c549efd83d62b86e298c9c45ebd06a3ad89a
Reviewed-on: https://go-review.googlesource.com/c/go/+/505397
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There are some subtle details here about measuring OS stacks in cgo
programs. There's also an expectation about magnitude in the MemStats
docs that isn't in the runtime/metrics docs. Fix both.
Fixes#54396.
Change-Id: I6b60a62a4a304e6688e7ab4d511d66193fc25321
Reviewed-on: https://go-review.googlesource.com/c/go/+/502156
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Top-level functions in the net package that only read files,
for example LookupPort(...), or LookupIP(host) where host resides
in /etc/hosts, now work on wasip1.
If the application has the ability to create sockets (for example,
when using a sockets extension to WASI preview 1), it's now
possible to do name resolution by passing a custom Dial function
to a Resolver instance.
Change-Id: I923886f67e336820bc89f09ea1855387c8dac61a
Reviewed-on: https://go-review.googlesource.com/c/go/+/500579
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Randy Reddig <ydnar@shaderlab.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Replace the (flaky) types2.TestIssue43124 with the code of the
(stable) go/types version of this test.
While at it, replace a handful of syntax.Pos{} with the equivalent
nopos, to further reduce differences between the two versions of
the issues_test.go file.
For #61064.
Change-Id: I69f3e4627a48c9928e335d67736cb875ba3835fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/507215
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Verify that the Host header we send is valid.
Avoids surprising behavior such as a Host of "go.dev\r\nX-Evil:oops"
adding an X-Evil header to HTTP/1 requests.
Add a test, skip the test for HTTP/2. HTTP/2 is not vulnerable to
header injection in the way HTTP/1 is, but x/net/http2 doesn't validate
the header and will go into a retry loop when the server rejects it.
CL 506995 adds the necessary validation to x/net/http2.
For #60374
Change-Id: I05cb6866a9bead043101954dfded199258c6dd04
Reviewed-on: https://go-review.googlesource.com/c/go/+/506996
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
There are currently no examples in the new slices and maps package, so
add some. This adds examples for most functions in the slices package
except the very obvious ones, and adds examples for the DeleteFunc and
EqualFunc functions in the maps package.
Also clarify/correct a few doc comments:
* EqualFunc takes an "equality" function, not a "comparison" function
* It's confusing for Delete and DeleteFunc to say they "do not create a
new slice", as they do return a new slice. They already say they
"return the modified slice" which is enough.
* Similar for Compact, and mention that it returns the modified slice
(and say why)
* Note that CompactFunc keeps the first element in equal runs
* Say what cmp is in SortStableFunc and IsSortedFunc
* Say that MinFunc and MaxFunc return the first value
Change-Id: I59c7bb1c7cabc4986d81018a5aaf5b712d3310f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/505095
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 500575 changed mayCall to return "false" for min/max builtin.
However, with string or float, min/max requires runtime call, so mayCall
should return true instead. This's probably not a big problem, because
CL 506115 makes order pass handle min/max correctly. But it's still
better to do it the right way.
Updates #60582
Change-Id: I9779ca62bebd0f95e52ad5fa55b9160dc35b33aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/506855
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The large-function phi placement algorithm evidently doesn't like the
same pseudo-variable being used to represent expressions of varying
types.
Instead, use the same tactic as used for "valVar" (ssa.go:6585--6587),
which is to just generate a fresh marker node each time.
Maybe we could just use the OMIN/OMAX nodes themselves as the key
(like we do for OANDAND/OOROR), but that just seems needlessly risky
for negligible memory savings. Using fresh marker values each time
seems obviously safe by comparison.
Fixes#61041.
Change-Id: Ie2600c9c37b599c2e26ae01f5f8a433025d7fd08
Reviewed-on: https://go-review.googlesource.com/c/go/+/506679
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The slog check is new and no existing code uses slog (it's new too),
so there are no concerns about false positives in existing code.
Enable it by default.
Change-Id: I4fc1480eeb5a3acc9e5e095e9d5428f5ce04b121
Reviewed-on: https://go-review.googlesource.com/c/go/+/505915
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The required gc bootstrap compiler, 1.17, has an internal/lazyregexp
package. It permits that package to be imported by internal/profile
while bootstrapping. The gccgo compiler also has an internal/lazyregexp
package, but it does not permit the gc compiler to import it.
Permit bootstrapping with gccgo by adding internal/lazyregexp to the
list of bootstrap directories.
The gccgo compiler recognizes the magic functions internal/abi.FuncPCABI0
and FuncPCABIInternal, but only in the internal/abi package, not
in the bootstrapping internal/abi package.
Permit bootstrapping with gccgo by adding definitions of those functions
with build tags so that they are only used by gccgo.
Fixes#60913
Change-Id: I3a78848d545db13314409d170d63f4cc737ca12e
Reviewed-on: https://go-review.googlesource.com/c/go/+/505036
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
The invention of base32 and base64 predates the invention of UTF-8
and was never meant to output valid UTF-8.
By default, the output is always valid ASCII (and thus valid UTF-8)
except when the user specifies an alphabet or padding value
that is larger than '\x7f'. If that is done,
then the exact byte symbol is used rather than the UTF-8 encoding.
Fixes#60689
Change-Id: I4ec88d974ec0658ad1a578bbd65a809e27c73ea7
Reviewed-on: https://go-review.googlesource.com/c/go/+/505237
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
SysProcAttr.NoInheritHandles doc comment is not clear about which
handles are affected by it. This CL clarifies that it not only affects
the ones passed in AdditionalInheritedHandles, but also the ones
passed in ProcAttr.Files, which are required to be stderr, stdin and
stdout when calling syscall.StartProcess.
Updates #60942
Change-Id: I5bc5b3604b6db04b83f6764d5c5ffbdafeeb22fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/505515
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Try to set stdio to non-blocking mode before the os package
calls NewFile for each fd. NewFile queries the non-blocking flag
but doesn't change it, even if the runtime supports non-blocking
stdio. Since WebAssembly modules are single-threaded, blocking
system calls temporarily halt execution of the module. If the
runtime supports non-blocking stdio, the Go runtime is able to
use the WASI net poller to poll for read/write readiness and is
able to schedule goroutines while waiting.
Change-Id: I1e3ce68a414e3c5960ce6a27fbfd38556e59c3dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/498196
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Achille Roussel <achille.roussel@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
When unification of two types succeeds and at least one of them
is an interface, we must be more cautious about when to accept
the unification, to avoid order dependencies and unexpected
inference results.
The changes are localized and only affect matching against
interfaces; they further restrict what are valid unifications
(rather than allowing more code to pass). We may be able to
remove some of the restriotions in a future release.
See comments in code for a detailed description of the changes.
Also, factored out "asInterface" functionality into a function
to avoid needless repetition in the code.
Fixes#60933.
Fixes#60946.
Change-Id: I923f7a7c1a22e0f4fd29e441e016e7154429fc5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/505396
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Print the unification mode in human-readable form.
Use a tab and // instead of ()'s to show unification mode
and whether operands where swapped.
These changes only affect inference trace output, which is
disabled by default. For easier debugging.
For #60933.
Change-Id: I95299c6e09b90670fc45addc4f9196b6cdd3b59f
Reviewed-on: https://go-review.googlesource.com/c/go/+/505395
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Our large-function phi placement algorithm is incompatible with phi
opcodes already existing in the SSA representation. Instead, use simple
variable assignments and have the phi placement algorithm place the phis
we need for min/max.
Turns out the small-function phi placement algorithm doesn't have this
sensitivity, so this bug only occurs in large functions (>500 basic blocks).
Maybe we should document/check that no phis are present when we start
phi placement (regardless of size). Leaving for a potential separate CL.
We should probably also fix the placement algorithm to handle existing
phis correctly. But this CL is probably a lot smaller/safer than
messing with phi placement.
Fixes#60982
Change-Id: I59ba7f506c72b22bc1485099a335d96315ebef67
Reviewed-on: https://go-review.googlesource.com/c/go/+/505756
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
When reusing a g struct the runtime did not reset
g.raceignore. Initialize raceignore to zero when initially
setting racectx.
A goroutine can end with a non-zero raceignore if it exits
after calling runtime.RaceDisable without a matching
runtime.RaceEnable. If that goroutine's g is later reused
the race detector is in a weird state: the underlying
g.racectx is active, yet g.raceignore is non-zero, and
raceacquire/racerelease which check g.raceignore become
no-ops. This causes the race detector to report races when
there are none.
Fixes#60934
Change-Id: Ib8e412f11badbaf69a480f03740da70891f4093f
Reviewed-on: https://go-review.googlesource.com/c/go/+/505055
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
CL 410344 fixed missing method value wrapper, by visiting body of
wrapper function after applying inlining pass.
CL 492017 allow more inlining of functions that construct closures,
which ends up making the wrapper function now inlineable, but can
contain closure nodes that couldn't be inlined. These closures body may
contain OMETHVALUE nodes that we never seen, thus we need to scan
closures body for finding them.
Fixes#60945
Change-Id: Ia1e31420bb172ff87d7321d2da2989ef23e6ebb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/505255
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Change the cover command to accept arguments via response files, using
the same mechanism employed for the compiler and the assembler. This
is needed now that the cover tool accepts a list of all source files
in a package, as opposed to just a single source file, and as a result
can run into system-dependent command line length limits.
Fixes#60785.
Change-Id: I67dbc96ad9fc5c6f43d5c1e4e903e4b8589b154f
Reviewed-on: https://go-review.googlesource.com/c/go/+/503735
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Due to the semantics of roots, a root store may contain two valid roots
that have the same subject (but different SPKIs) at the asme time. As
such in testVerify it is possible that when we verify a certificate we
may get two chains that has the same stringified representation.
Rather than doing something fancy to include keys (which is just overly
complicated), tolerate multiple matches.
Fixes#60925
Change-Id: I5f51f7635801762865a536bcb20ec75f217a36ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/505035
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
We parse mail messages using net/textproto. For #53188, we tightened
up the bytes permitted by net/textproto to match RFC 7230.
However, this package uses RFC 5322 which is more permissive.
Restore the permisiveness we used to have, so that older code
continues to work.
Fixes#58862Fixes#60332
Change-Id: I5437f5e18a756f6ca61c13c4d8ba727be73eff9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/504416
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Running go test -parallel=1 -v, these are the top 10 tests:
PASS: TestScript/mod_invalid_version 40.14s
PASS: TestScript/build_cache_output 46.82s
PASS: TestScript/get_legacy 48.69s
PASS: TestTestCache 58.44s
PASS: TestScript/mod_get_direct 62.88s
PASS: TestScript/build_pgo_auto_multi 63.49s
PASS: TestScript/build_pgo_auto 70.69s
PASS: TestScript/gcflags_patterns 95.17s
PASS: TestScript/mod_list_compiled_concurrent 124.31s
PASS: TestScript/vet_flags 202.85s
Change the top 5 not to run builds at all, so they don't
have to use -a or clear the go build cache.
mod_get_direct should be replaced with a vcs-test test.
mod_invalid_version should be replaced with a vcs-test test.
get_legacy should be deleted eventually.
Change-Id: Id67c458b1a96c912d89cbece341372c2ef5ee082
Reviewed-on: https://go-review.googlesource.com/c/go/+/504536
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
We do not index std as a whole module ever.
When working in the main Go repo, files in package change often,
so we don't want to pay the cost of reindexing all of std when what
we really need is just to reindex strings. Per-package indexing
works better for that case.
When using a released Go toolchain, we don't have to worry about
the whole module changing, but if we switch to whole-module indexing
at that point, we have the potential for bugs that only happen in
released toolchains. Probably not worth the risk.
For similar reasons, we don't index the current work module as
a whole module (individual packages are changing), so we use the heuristic
that we only do whole-module indexing in the module cache.
The new toolchain modules live in the module cache, though, and
our heuristic was causing whole-module indexing for them.
As predicted, enabling whole-module indexing for std when it's
completely untested does in fact lead to bugs (a very minor one).
This CL turns off whole-module indexing for std even when it is
in the module cache, to bring toolchain module behavior back in
line with the other ways to run toolchains.
For #57001.
Change-Id: I5012dc713f566846eb4b2848facc7f75bc956eb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/504119
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Modules cannot contain go.mod files except at the root
(and we don't keep one at the root). Rename the other go.mod
files to _go.mod.
dl2mod, which we used to convert all the old releases,
did this renaming, but it was missed when porting that
code to distpack.
For #57001.
Fixes#60847.
Change-Id: I4d646b96b5be15df3b79193e254ddc9b11cc8734
Reviewed-on: https://go-review.googlesource.com/c/go/+/503979
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
There is a chicken and egg problem with always requiring
the checksum database for toolchain module downloads, since the
checksum database populates its entry by doing its own module
download.
Don't require the checksum database for GOPROXY=file:/// (for local testing)
and when running on the Go module mirror.
For #60847.
Change-Id: I5d67d585169ae0fa73109df233baae8ba5fe5dd3
Reviewed-on: https://go-review.googlesource.com/c/go/+/503978
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This is intended for the specific case of 'fmahash=qn' where someone
wants to disable fma without all the hash-search-handshake output.
There are cases where arm64, ppc64, and s390x users might want to do
this.
Change-Id: Iaf46c68a00d7c9f7f82fd98a4548b72610f84bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/503776
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
GOROOT/test is pruned out by cmd/distpack. It isn't really needed for
the test anyway; the test can instead use the "src/unicode" subdirectory,
which is even within the same module.
This test was previously adjusted in CL 13467045 and CL 31859.
Unlike in previous iterations of the test, the directories used in
this revision are covered by the Go 1 compatibility policy and thus
unlikely to disappear.
For #24904.
Change-Id: I156ae18354bcbc2ddd8d22b210f16ba1e97cd5d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/504116
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
RemoteAddr can return nil in some cases, this fix prevents a panic.
I chatted with @neild about this beforehand, but what's happening in our
case is that a connection comes in to the HTTP server which is then
immediately closed (we discovered this issue by accident using nmap).
The network implementation that we're using (it happens to be gVisor
via its gonet adaptor) is returning nil from RemoteAddr(), presumably
as there is no remote at that point.
But, ultimately, since RemoteAddr returns an interface it is always
possible for it to return nil, and indeed conn.RemoteAddr in this file
does exactly that if the conn is not ok.
Change-Id: Ibe67ae6e30b68e2776df5ee2911bf5f1dc539641
GitHub-Last-Rev: ff3505d1d0
GitHub-Pull-Request: golang/go#60823
Reviewed-on: https://go-review.googlesource.com/c/go/+/503656
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The main change here is fixing the panic where it was called even when
req.Body was nil. It might also work better to keep the req.Body.Close
calls closer after req.Body is read, so do that too.
Calling readableStreamPull.Release on a js.Func with a zero value
is currently a no-op, but it seems better to avoid it anyway.
Also remove readableStreamStart, readableStreamCancel while here.
They were used in the initial but not final patch set of CL 458395.
Fixes#60809.
Change-Id: I6ff2e3b6ec2cd4b0c9c67939903e32908312db8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/503676
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change adds a test highlighting an issue with the fstest.TestFS
test suite which occurred when the fs.FS implementation would expose
directories returning unordered directory entries from their ReadDir
method.
--- FAIL: TestShuffledFS (0.00s)
testfs_test.go:76: testing fs.Sub(fsys, tmp): TestFS found errors:
.: Glob(`*e*`): wrong output:
extra: one
missing: one
The issue came from having the wrong variable passed to the checkGlob
method. There are two variables named list and list2, the latter is
sorted, and the checkGlob method expects a sorted list but was passed
list instead of list2.
Change-Id: I5e49dccf14077e7d1fee51687eb6a5eeb0330c16
Reviewed-on: https://go-review.googlesource.com/c/go/+/503175
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Currently ArenaNew expects the type passed in to be a *T and it returns
a *T. This does not match the function's documentation.
Since this is an experiment, change ArenaNew to match the documentation.
This more closely aligns ArenaNew with arena.New. (Takes a type T,
returns a *T value.)
Note that this is a breaking change. However, as far as pkg.go.dev can
tell, there's exactly one package using it in the open source world.
Also, add smoke test for the exported API, which is just a wrapper
around the internal API. Clearly there's enough room for error here that
it should be tested, but we don't need thorough tests at this layer
because that already exists in the runtime. We just need to make sure it
basically works.
Fixes#60528.
Change-Id: I673cc4609378380ef80648b0c2eb2928e73f49c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/501860
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The go command recognizes when a program named go_$GOOS_$GOARCH_exec
is in PATH. There are two such programs living in GOROOT/misc/wasm.
Like GOROOT/bin/{go,gofmt} and GOROOT/pkg/tool/**, these programs
need to have the executable bit set to do their job, so set it.
Comparing a distpack produced before and after this change shows that
the pack.go file is modified, the two go_{js,wasip1}_wasm_exec programs
have the new file mode, and there are no other changes, as expected.
The mode change is relevant to the binary and source distributions only.
No change to the module zip since it doesn't include GOROOT/misc at all,
so no effect on previously created toolchain modules whose checksums
are already recorded in the Go checksum database and cannot be changed.
(Other than by changing their "v0.0.1" version, but that's expensive.)
Fixes#60843.
Change-Id: I799b6aacff59c0785cb7743cbd17dda5a9ef91be
Reviewed-on: https://go-review.googlesource.com/c/go/+/503975
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
In racecallatomic, we do a load before calling into TSAN, so if
the address is invalid we fault on the Go stack. We currently use
a 8-byte load instruction, regardless of the data size that the
atomic operation is performed on. So if, say, we are doing a
LoadUint32 at an address that is the last 4 bytes of a memory
mapping, we may fault unexpectedly. Do a 1-byte load instead.
(Ideally we should do a load with the right size, so we fault
correctly if we're given an unaligned address for a wide load
across a page boundary. Leave that for another CL.)
Fix AMD64, ARM64, and PPC64. The code already uses 1-byte load
on S390X.
Should fix#60825.
Change-Id: I3dee93eb08ba180c85e86a9d2e71b5b520e8dcf0
Reviewed-on: https://go-review.googlesource.com/c/go/+/503937
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
When 'go list -cover' is run in a way that triggers package builds
(for example, -export), ensure that the build step actually includes
coverage instrumentation as part of the config. Without this we will
wind up with incorrect build IDs.
Fixes#60755.
Change-Id: Ic84ab9e301d075bee5ff9d6828370a1708be0035
Reviewed-on: https://go-review.googlesource.com/c/go/+/502877
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
The Fetch API was meant to only be disabled in tests.
Since wasm_exec.js defines a global 'process' object,
it ended up being disabled anywhere that script is used.
Make the heuristic stricter so that it's less likely to
trigger anywhere but when testing js/wasm using Node.js.
For #57613.
Fixes#60808.
Change-Id: Ief8def802b466ef4faad16daccefcfd72e4398b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/503675
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
types2 have already errored about any spec-required overflows, and
division by zero. CL 469595 unintentionally fixed typecheck not to error
about overflows, but zero division is still be checked during tcArith.
This causes unsafe operations with variable size failed to compile,
instead of raising runtime error.
Fixes#60601
Change-Id: I7bea2821099556835c920713397f7c5d8a4025ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/501735
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Previously we used the highest Go build tag found in the build
configuration, which matches gover.Local for development toolchains
(it is always a bare language version), but is too low for releases.
Updates #57001.
Change-Id: I74c2f7ab06231858eee99ecd11ed3759853e01ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/503537
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rather than using the external network and real-world chains for testing
the integrations with platform verifiers, use a synthetic test root.
This changes adds a constrained root and key pair to the tree, and adds
a test suite that verifies certificates issued from that root. These
tests are only executed if the root is detected in the trust store. For
reference, the script used to generate the root and key is attached to
the bottom of this commit message.
This change leaves the existing windows/darwin TestPlatformVerifier
tests in place, since the trybots do not currently have the test root in
place, and as such cannot run the suite. Once the builder images have
the root integrated, we can remove the old flaky tests, and the trybots
will begin running the new suite automatically.
Updates #52108
-- gen.go --
package main
import (
"crypto/ecdsa"
"crypto/elliptic"
"crypto/rand"
"crypto/x509"
"crypto/x509/pkix"
"encoding/pem"
"flag"
"log"
"math/big"
"net"
"os"
"time"
)
func writePEM(pemType string, der []byte, path string) error {
enc := pem.EncodeToMemory(&pem.Block{
Type: pemType,
Bytes: der,
})
return os.WriteFile(path, enc, 0666)
}
func main() {
certPath := flag.String("cert-path", "platform_root_cert.pem", "Path to write certificate PEM")
keyPath := flag.String("key-path", "platform_root_key.pem", "Path to write key PEM")
flag.Parse()
key, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
if err != nil {
log.Fatalf("ecdsa.GenerateKey failed: %s", err)
}
now := time.Now()
tmpl := &x509.Certificate{
SerialNumber: big.NewInt(9009),
Subject: pkix.Name{
CommonName: "Go platform verifier testing root",
},
NotBefore: now.Add(-time.Hour),
NotAfter: now.Add(time.Hour * 24 * 365 * 5),
IsCA: true,
BasicConstraintsValid: true,
PermittedDNSDomainsCritical: true,
// PermittedDNSDomains restricts the names in certificates issued from this root to *.testing.golang.invalid.
// The .invalid TLD is, per RFC 2606, reserved for testing, and as such anything issued for this certificate
// should never be valid in the real world.
PermittedDNSDomains: []string{"testing.golang.invalid"},
// ExcludedIPRanges prevents any certificate issued from this root that contains an IP address in both the full
// IPv4 and IPv6 ranges from being considered valid.
ExcludedIPRanges: []*net.IPNet{{IP: make([]byte, 4), Mask: make([]byte, 4)}, {IP: make([]byte, 16), Mask: make([]byte, 16)}},
KeyUsage: x509.KeyUsageCertSign,
ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
}
certDER, err := x509.CreateCertificate(rand.Reader, tmpl, tmpl, key.Public(), key)
if err != nil {
log.Fatalf("x509.CreateCertificate failed: %s", err)
}
keyDER, err := x509.MarshalECPrivateKey(key)
if err != nil {
log.Fatalf("x509.MarshalECPrivateKey failed: %s", err)
}
if err := writePEM("CERTIFICATE", certDER, *certPath); err != nil {
log.Fatalf("failed to write certificate PEM: %s", err)
}
if err := writePEM("EC PRIVATE KEY", keyDER, *keyPath); err != nil {
log.Fatalf("failed to write key PEM: %s", err)
}
}
Change-Id: If7c4a9f18466662a60fea5443e603232a9260026
Reviewed-on: https://go-review.googlesource.com/c/go/+/488855
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Make all functions use a constraint S ~[]E even if they don't return
the slice type. This makes explicitly instantiating the functions more
consistent: you don't have to remember which take ~[]E and which do not.
It also permits inferring the type when passing one of these functions
to some other function that is using a named slice type.
Fixes#60546
Change-Id: Ib3435255d0177fdbf03455ae527d08599b1ce012
Reviewed-on: https://go-review.googlesource.com/c/go/+/502955
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Axel Wagner <axel.wagner.hh@googlemail.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Address a panic that was caused by net.Dial/net.Listen entering the fake
network stack and assuming that the addresses would be of type *TCPAddr,
where in fact they could have been *UDPAddr or *UnixAddr as well.
The fix consist in implementing the fake network facility for udp and
unix addresses, preventing the assumed type assertion to TCPAddr from
triggering a panic. New tests are added to verify that using the fake
network from the exported functions of the net package satisfies the
minimal requirement of being able to create a listener and establish a
connection for all the supported network types.
Fixes#60012Fixes#60739
Change-Id: I2688f1a0a7c6c9894ad3d137a5d311192c77a9b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/502315
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
net.FileListener returns values of type *net.TCPListener, which can be
asserted by the application. The (*net.TCPListener).Addr method
documents that the underlying type of its return value is *net.TCPAddr,
which is fixed by this change.
Change-Id: Ife9906716d1b512092024ba50797bf7831536b75
Reviewed-on: https://go-review.googlesource.com/c/go/+/502335
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
When run as a stand-alone test (without other tests running before),
the builtin function 'assert' (only available for testing) is missing.
Make sure it's declared.
This change only affects this test, when run stand-alone, as in:
go test -run Hilbert
Fixes#60774.
Change-Id: Ib07d97ba2670b839e8ad11ef50d0e6581bb3d79d
Reviewed-on: https://go-review.googlesource.com/c/go/+/502996
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Identify generated files by name prefix (z*) and content
(^// Code generated by go tool dist)
instead of having a fixed list. This will be more robust
against doing make.bash and then rewinding git and
then doing make.bash again.
Change-Id: If9b4d02f5ad65345623866176d96e9894a957dc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/501036
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
If the cancellation takes effect between Next and Scan,
then Scan returns context.Canceled, but the test wasn't
allowing this case.
The old flake reproduced easily with:
go test -c
stress ./sql.test -test.count=100 -test.run=TestContextCancelDuringRawBytesScan
The new test modes exercise that path directly instead of needing stress.
The new check for context.Canceled fixes the new test mode "top".
Fixes#60445.
Change-Id: I3870039a0fbe0a43c3e261b43b175ef83f818765
Reviewed-on: https://go-review.googlesource.com/c/go/+/502876
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
sort.Slice was being used to sort some newly added entries by name
to make the ctxt.Data slice reproducible, but some existing entries
have the same name, and the effect was to take the non-determinism
of the tail entries and scatter it into the earlier, deterministic section
when multiple entries had the same name.
The specific entries with the same name are type SDWARFVAR, which
all have an empty name but different relocations. If they are shuffled,
then the relocation symbols are visited in a different order, which
enters them into the string table in a different order, which results in
different object files, different object file hashes, and different build IDs
for the final executables.
Use sort.SliceStable to avoid reordering entries we don't mean to reorder.
Also add a simple test for scheduling-related non-determinism.
I debugged this originally using 'go install -race cmd/compile',
but that was slow and turned out not to be terribly reliable.
Using a few different GOMAXPROCS settings turns out to be a much more
effective (and faster) way to scramble scheduling decisions.
Fixes#60759.
Change-Id: Ia966b02b9fdaefa971f998a09319ca375bdf8604
Reviewed-on: https://go-review.googlesource.com/c/go/+/502755
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
We'd like to mention in a comment that users should prefer
slices.IsSorted over sort.IntsAreSorted and similar
functions. Create a benchmark that shows this.
goos: linux
goarch: amd64
pkg: slices
cpu: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
BenchmarkIntsAreSorted-8 6031 198315 ns/op
BenchmarkIsSorted-8 26580 45801 ns/op
Change-Id: I4f14fafd799ecec35c8a5215b74994e972103061
Reviewed-on: https://go-review.googlesource.com/c/go/+/502556
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Eli Bendersky <eliben@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
link contains many calls to log.Fatal, but it uses the default log output
format, which is configured for server programs, not command-line tools.
Set it up for command-line tools instead.
Changes errors like
2023/06/12 14:32:24 reference to undefined builtin "runtime.gcWriteBarrier" from package "internal/abi"
to
link: reference to undefined builtin "runtime.gcWriteBarrier" from package "internal/abi"
Change-Id: I3565960408c03f2f499a7517ec18c01870eb166c
Reviewed-on: https://go-review.googlesource.com/c/go/+/502698
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The WASI specification has file types for both stream and datagram
sockets. This change refactors the internal implementation of the
net.FileConn and net.FileListener functions to avoid returning a
misleading ENOTSOCK when calling net.FileConn with a file referencing
a datagram socket and instead properly construct net.UDPConn values
or return EOPNOTSUPP otherwise.
Change-Id: I594f700847254895cd6ce172979fd89c4b851940
Reviewed-on: https://go-review.googlesource.com/c/go/+/502316
Reviewed-by: Damien Neil <dneil@google.com>
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: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
There is no guarantee that the user build cache will have
correct data if we are using a versioned build (with a VERSION file),
because that overrides the use of tool build IDs for staleness.
An earlier build might have run with a buggy compiler, and we don't
want those files lying around.
Change-Id: I831956911162ccbd0b4d943c305b3537918fe119
Reviewed-on: https://go-review.googlesource.com/c/go/+/502699
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
The go parser previously checked for invalid import paths, go/build,
seeing the parse error would put files with invalid import paths into
InvalidGoFiles. golang.org/cl/424855 removed that check from the
parser, which meant files with invalid import paths not have any parse
errors on them and not be put into InvalidGoFiles. Do a check for
invalid import paths in go/build soon after parsing so we can make
sure files with invalid import paths go into InvalidGoFiles.
This fixes an issue where the Go command assumed that if a file wasn't
invalid it had non empty import paths, leading to a panic.
Fixes#60230Fixes#60686
Change-Id: I33c1dc9304649536834939cef7c689940236ee20
Reviewed-on: https://go-review.googlesource.com/c/go/+/502615
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
To infer type arguments in an assignment of the form
var target func(t1, t2, ...) = g
where g is a generic function
func g[P1, P2, ...](p1, p2, ...)
the type checker used the synthetic function call
g(t1, t2, ...)
But because each argument (of type) t1, t2, ... is assigned to its
corresponding parameter p1, p2, ..., type inference uses assignment
rules ("inexact match") for unification.
As a result, types such as mystring and string match even though
they should not (they are not identical), yet function parameter
types must be identical to match.
This CL fixes this by constructing the synthetic call
g'(func(t1, t2, ...))
where g' is the generic function
func g'[P1, P2, ...](func(p1, p2, ...))
This mimics the function assignment directly by representing it as
a single argument passing (of a function-typed argument). Function
parameter types must now be identical to unify.
As an added benefit, the implementation is simpler.
As a consequence, when such an assignment is invalid because the
function types cannot possibly match, we now correctly get an
inference error. Without this change, in some cases unification
would succeed, only to lead to an assignment error afterwards.
While at it, update the date in the copyright notice of
testdata/manual.go so we don't need to fix it each time we copy
code from a test case in manual.go into a issueXXXXX.go file.
Fixes#60688.
Change-Id: I716247f426ef33d76c7849b0c33c59124e55b859
Reviewed-on: https://go-review.googlesource.com/c/go/+/501938
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Follow-up on CL 498955 which introduced a unification mode, to be used
to control the precision of unification of element types (CL 498895):
When unifying against core types of unbound type parameters, we must
use inexact unification at the top (irrespective of the unification mode),
otherwise it may fail when unifying against a defined type (core types
are always underlying types).
No specific test case (I have not been able to create one yet).
Change-Id: Ie15e98f4b9e9fb60d6857d34b03d350ebbf0375e
Reviewed-on: https://go-review.googlesource.com/c/go/+/501302
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
This updates the logic from CL 489075 to avoid trying to save extra
sums if they aren't already expected to be present
and cfg.BuildMod != "mod" (as in the case of "go list -m -u all" with
a go.mod file that specifies go < 1.21).
Fixes#60667.
Updates #56222.
Change-Id: Ied6ed3e80a62f9cd9a328b43a415a42d14481056
Reviewed-on: https://go-review.googlesource.com/c/go/+/502015
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the ptrace system call, most of the newer architectures (e.g. arm64,riscv64,loong64)
do not provide support for the command PTRACE_{GET, SET}REGS.
The Linux kernel 2.6.33-rc7[1] introduces support for the command PTRACE_{GET,SET}REGSET,
which exports different types of register sets depending on the NT_* types, completely
overriding the functionality provided by PTRACE_{GET,SET}REGS.
[1] https://lore.kernel.org/all/20100211195614.886724710@sbs-t61.sc.intel.com/Fixes#60679.
Change-Id: I8c2671d64a7ecd654834740f4f1e1e50c00edcae
Reviewed-on: https://go-review.googlesource.com/c/go/+/501756
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
When determining DepsErrors for packages, we were trying to sort
errors by the top package on their ImportStack (which would likely be
the package the error was generated for) to get a deterministic
error order.
The problem is that some PackageErrors don't have ImportStacks set on
them. Fall back to sorting the errors by the error text (instead of
making things more complicated by tracking the packages that produced
the errors more closely).
Fixes#59905
Change-Id: Id305e1e70801f8909fd6463383b8eda193559787
Reviewed-on: https://go-review.googlesource.com/c/go/+/501978
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
In plugin mode, we mangle the type symbol name so it doesn't
contain characters that may confuse the external linker. With
generics, instantiated function name includes type names, so it
may also contain such characters and so also needs to be mangled.
Fixes#58800.
Change-Id: Ibb08c95b89b8a815ccef98193d3a025e9d4756cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/500095
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Some of the TestScript/gotoolchain* tests assume that go.env contains
GOTOOLCHAIN=auto, but that's not always the case, for example CI
environments may set it to `local` to avoid downloading a new toolchain.
This commit fixes the tests to work regardless of the value of
GOTOOLCHAIN in go.env.
Fixes#60685
Change-Id: Ieda22574f8a028893762274cf9db721c9d69bf7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/502035
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
/gc/heap/live:bytes may exceed MemStats.HeapAlloc, even when all data is
flushed, becuase the GC may double-count objects when marking them. This
is an intentional design choice that is largely inconsequential. The
runtime is already robust to it, and the condition is rare.
Fixes#60607.
Change-Id: I4da402efc24327328d2d8780e4e49961b189f0ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/501858
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Per the spec, methods cannot be associated with a named pointer type.
Exit early with an empty method set in this case.
This matches the corresponding check in LookupFieldOrMethod;
the check is not present in (lowercase) lookupFieldOrMethod
because it (the check) doesn't apply to struct fields.
Fixes#60634.
Change-Id: Ica6ca8be6b850ea0da6f0b441fbf5b99cb0b6b17
Reviewed-on: https://go-review.googlesource.com/c/go/+/501299
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
The section on type inference has not been updated yet for Go 1.21.
Add a temporary note so that readers referred to this section from
the release notes are not confused.
Change-Id: Idc4c74d6d700f891c625289e873ad5aa9c2c5213
Reviewed-on: https://go-review.googlesource.com/c/go/+/501308
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
cmd/cover uses '//line' directives to map instrumented source files
back to the original source file and line numbers.
Line directives have no way to escape newline characters, so cmd/cover
must not be used with source file paths that contain such characters.
Updates #60167.
Change-Id: I6dc039392d59fc3a5a6121ef6ca97b0ab0da5288
Reviewed-on: https://go-review.googlesource.com/c/go/+/501577
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
cmd/cgo uses '//line' directives to map generated source
files back to the original source file and line nmubers.
The line directives have no way to escape newline characters,
so cmd/cgo must not be used if the line directives would contain
such characters.
Updates #60167.
Change-Id: I8581cea74d6c08f82e86ed87127e81252e1bf78c
Reviewed-on: https://go-review.googlesource.com/c/go/+/501576
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Toolchain2 is only used for building toolchain3. We don't need to
build it with PGO. And building with PGO causes packages to be
built twice (one with PGO for the compiler, one without for other
programs). Disable PGO for toolchain2.
Also, I thought cmd/dist requires toolchain2 and toolchain3
compilers are identical binaries, so they need to be built in the
same way. But it doesn't.
Change-Id: Iaf49816da3dd06db79b48482c0e2435e09b512d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/501335
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
This only affects tests, typically manual tests, but when using trace
we're debugging and we don't want to crash because of trace itself.
No test because a test would cause trace output. Manually verified.
Fixes#60649.
Change-Id: I97abdb94db05774801ec5da56171f4a1aff35615
Reviewed-on: https://go-review.googlesource.com/c/go/+/501415
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
GODEBUG=dontfreezetheworld=1 allows goroutines to continue execution
during fatal panic. This increases the chance that tracebackothers will
encounter running goroutines that it must skip, which is expected and
fine. However, it also introduces the risk that a goroutine transitions
from stopped to running in the middle of traceback, which is unsafe and
may cause traceback crashes.
Mitigate this by halting M execution if it naturally enters the
scheduler. This ensures that goroutines cannot transition from stopped
to running after freezetheworld. We simply deadlock rather than using
gcstopm to continue keeping disturbance to scheduler state to a minimum.
Change-Id: I9aa8d84abf038ae17142f34f4384e920b1490e81
Reviewed-on: https://go-review.googlesource.com/c/go/+/501255
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Directory or file paths containing newlines may cause tools (such as
cmd/cgo) that emit "//line" or "#line" -directives to write part of
the path into non-comment lines in generated source code. If those
lines contain valid Go code, it may be injected into the resulting
binary.
(Note that Go import paths and file paths within module zip files
already could not contain newlines.)
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Fixes#60167.
Fixes CVE-2023-29402.
Change-Id: I64572e9f454bce7b685d00e2e6a1c96cd33d53df
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1882606
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501226
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Enforce that linker flags which expect arguments get them, otherwise it
may be possible to smuggle unexpected flags through as the linker can
consume what looks like a flag as an argument to a preceding flag (i.e.
"-Wl,-O -Wl,-R,-bad-flag" is interpreted as "-O=-R -bad-flag"). Also be
somewhat more restrictive in the general format of some flags.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Fixes#60305
Fixes CVE-2023-29404
Change-Id: I913df78a692cee390deefc3cd7d8f5b031524fc9
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1876275
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501225
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The flags that we recorded in _cgo_flags did not use any quoting,
so a flag containing embedded spaces was mishandled.
Change the _cgo_flags format to put each flag on a separate line.
That is a simple format that does not require any quoting.
As far as I can tell only cmd/go uses _cgo_flags, and it is only
used for gccgo. If this patch doesn't cause any trouble, then
in the next release we can change to only using _cgo_flags for gccgo.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Fixes#60306
Fixes CVE-2023-29405
Change-Id: I81fb5337db8a22e1f4daca22ceff4b79b96d0b4f
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1875094
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501224
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The -C dir flag was added in Go 1.20.
This CL adds a new restriction: the -C must appear as the first flag on the command line.
This restriction makes finding the -C flag robust and matches the general way
people tend to think about and use the -C flag anyway.
It may break a few scripts that have been written since Go 1.20
but hopefully they will not be hard to find and fix.
(There is no strict compatibility guarantee for the command line.)
For #57001.
Change-Id: Ice2e5982c58d41eabdaef42a80d3624cde2c9873
Reviewed-on: https://go-review.googlesource.com/c/go/+/500915
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Move NewerToolchain and related code from select.go to switch.go
because it is only used for the Switch operation, not for Select.
This is a separate CL containing only the code move, separate
from any other changes.
For #57001.
Change-Id: I41cf0629b41fd55c30a1e799d857c06039ee99b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/500798
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Additional tests and bug fixes realized while writing go.dev/doc/gotoolchain (CL 500775).
- Handle go get toolchain@go1.22 (resolve to latest patch release, same as go get go@1.22).
(See modload/query.go and gover/mod.go.)
- Handle go get go@patch toolchain@patch.
(See modload/query.go and gover/mod.go.)
- Remove prefix-goVERSION-suffix form for toolchain name,
standardizing on goVERSION-suffix.
I have no good explanation for having two forms, so simplify to one.
(See vendor and gover.)
- Fail toolchain downloads when GOSUMDB=off.
Because toolchain downloads cannot always be predicted
(especially during switching rather than selection),
they cannot be listed in go.sum.
We rely on the checksum database for integrity of the download,
especially if proxied. If the checksum database is disabled,
this integrity check won't happen, so fail toolchain downloads.
(See modfetch/sumdb.go and script/gotoolchain_net.txt)
- Use names from documentation in package toolchain
(Select, Switch; SwitchTo renamed to Exec to avoid both names;
reqs.go renamed to switch.go; toolchain.go renamed to select.go.)
- Make "go env GOTOOLCHAIN" and "go env -w GOTOOLCHAIN"
work even when GOTOOLCHAIN is misconfigured.
(See special case at top of Select in select.go.)
- Clarify what goInstallVersion does
(report whether this is go install or go run pkg@version)
and explain the potential version switch more clearly.
Use the Switcher directly instead of reimplementing it.
(See select.go.)
- Document go@ and toolchain@ forms in go help get,
linking to go.dev/doc/toolchain.
(See modget/get.go.)
- Update URL of documentation in $GOROOT/go.env.
For #57001.
Change-Id: I895ef3519ff95db8710ed23b36ebaf4f648120cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/500797
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Incorporate CL 501035 for toolchain syntax changes
and a fix to a race (harmless outside tests) in sumdb client.
go get golang.org/x/mod@62c7e578 # CL 501035
go mod tidy
go mod vendor
This CL will break the cmd/go tests. The next CL fixes them.
For #57001.
Change-Id: I1fcb9799417595ecff870367f256cbc0a488934c
Reviewed-on: https://go-review.googlesource.com/c/go/+/500796
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
On Unix platforms, the runtime previously did nothing special when a
program was run with either the SUID or SGID bits set. This can be
dangerous in certain cases, such as when dumping memory state, or
assuming the status of standard i/o file descriptors.
Taking cues from glibc, this change implements a set of protections when
a binary is run with SUID or SGID bits set (or is SUID/SGID-like). On
Linux, whether to enable these protections is determined by whether the
AT_SECURE flag is passed in the auxiliary vector. On platforms which
have the issetugid syscall (the BSDs, darwin, and Solaris/Illumos), that
is used. On the remaining platforms (currently only AIX) we check
!(getuid() == geteuid() && getgid == getegid()).
Currently when we determine a binary is "tainted" (using the glibc
terminology), we implement two specific protections:
1. we check if the file descriptors 0, 1, and 2 are open, and if they
are not, we open them, pointing at /dev/null (or fail).
2. we force GOTRACKBACK=none, and generally prevent dumping of
trackbacks and registers when a program panics/aborts.
In the future we may add additional protections.
This change requires implementing issetugid on the platforms which
support it, and implementing getuid, geteuid, getgid, and getegid on
AIX.
Thanks to Vincent Dehors from Synacktiv for reporting this issue.
Fixes#60272
Fixes CVE-2023-29403
Change-Id: I73fc93f2b7a8933c192ce3eabbf1db359db7d5fa
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1878434
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501223
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test is flaky with in mayMoreStackPreempt mode. This is probably
revealing a real bug in the scheduler, but since it seems to only
affect TestCrashDumpsAllThreads, which is itself testing a debug mode,
I don't think this is high priority.
Updates #55160.
Change-Id: Iac558c098930ad8d4392b1e82b34f55eaec77c48
Reviewed-on: https://go-review.googlesource.com/c/go/+/501229
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Right now, every code generator in dist has a copy of the
// Code generated by go tool dist; DO NOT EDIT.
string. Put it in one place to make sure it doesn't diverge.
Change-Id: I8b2a1904031599d7fc128b6a5d74480dee05fc89
Reviewed-on: https://go-review.googlesource.com/c/go/+/501138
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
dist's deptab is a list of changes to the automatically derived set of
package dependencies. It's as old as dist itself, and the first
version of deptab in CL 5620045 was quite complex. From the beginning,
some of the entries in deptab have been for generated files that need
to be added to the dependency set because they can't be discovered if
they don't exist. gentab is also as old as dist itself, and lists the
generated dependency files.
The interaction between deptab and gentab is rather odd. gentab
contains only base file names, not whole paths. To figure out what
files to generate, dist takes a Cartesian product of deptab and gentab
and calls the generator wherever the basename of a path in deptab
matches an entry in gentab. This perhaps made sense at the time
because some of the generated files appeared in more than one package
in deptab.
These days, deptab consists exclusively of generated files because
dist can correctly derive all other dependencies, and all of the
generated files have unique paths. This makes the Cartesian product
approach needlessly complex (and so confusing!), and means that the
only purpose served by deptab is to provide full paths for generated
files.
Furthermore, in the dist clean command, it also needed to expand the
file names in gentab to complete paths, but it did so using a
different list, cleanlist, and the same Cartesian product algorithm.
This CL drops all of this complexity by putting full paths into
gentab, which lets us delete deptab and cleanlist.
Change-Id: Ie3993983734f6da3be453bb4c17a64e22dcf3e8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/501137
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
dist clean has logic to delete command binaries from the cmd
directories in cleanlist. However, these days the only binary it could
possibly remove is "$GOROOT/src/cmd/cgo/cgo". This is clearly no
longer necessary, so remove this stale code.
When this logic was originally introduced in CL 5622058, it was driven
by cleantab (not cleanlist), which contained all of the cmd
directories, which were legion at the time because this was the era of
the [568][acgl] toolchain. CL 9154 deleted cleantab, and did the same
clean walk over the "cmd/" directories listed in buildorder. However,
buildorder was a list of packages necessary to build cmd/go, so the
only "cmd/" directory in buildorder at the time was "cmd/go". Hence,
at that CL, dist started deleting only a "$GOROOT/src/cmd/go/go"
binary. The modern cleanlist was introduced in CL 76021, as a list of
packages containing "generated files and commands". The only "cmd/"
directory in cleanlist the whole time has been "cmd/cgo" (and I'm
honestly not sure why cmd/cgo is in there), so since that CL dist has
only deleted "$GOROOT/src/cmd/cgo/cgo".
Change-Id: I1915eb938d1a0e22ae6a64e7648a21894d3e6502
Reviewed-on: https://go-review.googlesource.com/c/go/+/501136
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
There are several files in gentab that have a nil generator, which
means they used to be generated, but aren't any more, so dist should
delete them if it encounters them. However, cleaning only look for
these file names in the small number of directories listed in
cleanlist, and none of these files were originally generated into any
of the directories in cleanlist. Specifically, enam.c was generated
into $GOROOT/src/cmd/[568]l starting with CL 5620045 until CL 35740044
and the anames[5689].c files were generated into $GOROOT/src/liblink
starting with CL 35740044 and CL 120690043 until CL 6110. None of
these directories even exist any more, and if these files did somehow
exist, dist wouldn't delete them anyway.
Hence, we can safely remove these files from gentab.
Change-Id: Ifed322d64a7a81a76537fcd9fc7020c7aca48050
Reviewed-on: https://go-review.googlesource.com/c/go/+/501135
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
If we don't have exact unification, we must consider interface
unification whether one of the types is a defined (named) interface
or not. Otherwise, if one of them is named, and the other one isn't,
the code selects interface-vs-non-interface unification and possibly
uses the wrong method set as the "required" method set, leading to
(incorrect) unification failure as was the case in #60564.
We can also not simply rely on getting this right in the subsequent
switch, through the handling of *Named types.
This CL fixes this simple logic error. If there's inexact unification,
now all (non-type parameter) interface cases are handled in one place,
before the switch. After handling interfaces, we are guaranteed that
we have either no interfaces, or we have exact unification where both
types must be of the same structure.
As a consequence, we don't need special handling for named interfaces
in the *Named case of the switch anymore.
Also, move the (unbound) type parameter swap from before interface
handling to after interface handling, just before the switch which
is the code that relies on a type parameter being in x, if any.
Fixes#60564.
Change-Id: Ibf7328bece25808b8dbdb714867048b93689f219
Reviewed-on: https://go-review.googlesource.com/c/go/+/500195
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Currently, we devirtualize an interface call if the profile
indicates a concrete callee is hot on the same line, and the
concrete receiver implements the interface. But it is possible
that (likely due to another call on the same line, or possibly a
stale profile) the concrete call is to a different method.
With the current AST construction we generate correct code, as we
extract the method name from the interface call and use that to
create the concrete call. But the devirtualization decision is
based on an unrelated call in the profile.
Check the method name when finding the hottest callee, so we won't
use unrelated calls to different methods.
Change-Id: I75c026997926f21bd6cc5266d3ffe99649a9b2d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/500961
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
When = is used instead of == as part of a conditional expression,
the parser message emphasizes the LHS and RHS of = by always
parenthesizing the two sides. For example, for:
if x = y {}
the error is:
cannot use assignment (x) = (y) as value
This is done to highlight the LHS and RHS in case of more complex
cases such as
if x || y = z {}
which one may incorrectly read as (x) || (y == z) rather than the
correct (x || y) = z.
This CL fine-tunes the error message a bit by only adding the
parentheses if the LHS and RHS are binary expressions.
Fixes#60599.
For #23385.
Change-Id: Ida4c8d12464cc2ac15c934f24858eb6f43cf9950
Reviewed-on: https://go-review.googlesource.com/c/go/+/500975
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The most important parts of almost any release notes are the
language and tool changes. Those should be the first two sections.
Instead Ports interrupts the flow with information that usually
matters only to very few users.
Move Ports to the end of the release notes.
Change-Id: I78492e91e368184fb5f8e8d44d63f35b8f14eeae
Reviewed-on: https://go-review.googlesource.com/c/go/+/500957
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
On Go <= 1.20 signals that caused the program to exit would eventually
call runtime.fatal. After the changes made in go.dev/cl/462437 but it
would still be nice if debuggers (eg. Delve) had a function they could
hook to intercept fatal signals.
Change-Id: Icf2b65187f95d52e60825c84f386806a75b38f6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/495736
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The non-cgo test points Segv and TgkillSegv are currently in
testprogcgo. Although the test points don't explicitly use cgo,
being a cgo program, there is still some C code that runs when
the test point is invoked, such as thread creation code.
For the cgo test points, sometimes we fail to unwind the stack if
C code is involved. For the non-cgo ones, we want to always be
able to unwind the stack, so we check for stack unwinding failures.
But if a signal is landed in the small piece of C code mentioned
above, we may still fail to unwind. Move the non-cgo test points
to a pure-Go program to avoid this problem.
May fix#52963.
Updates #59029, #59443, #59492.
Change-Id: I35d99a0dd4c7cdb627e2083d2414887a24a2822d
Reviewed-on: https://go-review.googlesource.com/c/go/+/500535
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
The workaround in CL 69970044 introduced a panic when StartProcess is
called with empty argv. Check the length before trying to access it.
Change-Id: Ic948d86c7067a21c484ba24e100d1f1f80179730
Reviewed-on: https://go-review.googlesource.com/c/go/+/500415
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
go work init / sync / use need to maintain the invariant that the
go version and toolchain in go.work are up-to-date with respect
to the modules in the workspace.
go get also preserves the invariant when running in a module.
go work use (including with no arguments) reestablishes the invariant.
Replaces the ToolchainTrySwitch func in PackageOpts with a new
gover.Switcher interface implemented by toolchain.Switcher.
Until now, the basic sketch of a particular phase of the go command
has been to call base.Error repeatedly, to report as many problems
as possible, and then call base.ExitIfErrors at strategic places where
continuing in the presence of errors is no longer possible.
A Switcher is similar: you call sw.Error repeatedly and then, when
all the errors from a given phase have been identified, call sw.Switch
to potentially switch toolchains, typically before calling base.ExitIfErrors.
One effect of the regularization of errors reported by the modload.loader
is to add a "go: " prefix to errors showing import stacks. That seems fine.
For #57001.
Change-Id: Id49ff7a28a969d3475c70e6a09d40d7aa529afa8
Reviewed-on: https://go-review.googlesource.com/c/go/+/499984
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The new PGO-driven indirect call specialization from CL 492436
in theory should allow for devirtualization on methods
in another package when those methods are directly referenced
in the current package.
However, inline.InlineImpossible was checking for a zero-length
fn.Body and would cause devirtualization to fail
with a debug log message like:
"should not PGO devirtualize (*Speaker1).Speak: no function body"
Previously, the logic in inline.InlineImpossible was only
called on local functions, but with PGO-based devirtualization,
it can now be called on imported functions, where inlinable
imported functions will have a zero-length fn.Body but a
non-nil fn.Inl.
We update inline.InlineImpossible to handle imported functions
by adding a call to typecheck.HaveInlineBody in the check
that was previously failing.
For the test, we need to have a hopefully temporary workaround
of adding explicit references to the callees in another package
for devirtualization to work. CL 497175 or similar should
enable removing this workaround.
Fixes#60561
Updates #59959
Change-Id: I48449b7d8b329d84151bd3b506b8093c262eb2a3
GitHub-Last-Rev: 2d53c55fd8
GitHub-Pull-Request: golang/go#60565
Reviewed-on: https://go-review.googlesource.com/c/go/+/500155
Run-TryBot: thepudds <thepudds1460@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
'go mod tidy' may resolve an imported package by added a dependency
that requires a higher 'go' version, which may activate graph pruning
(if the version goes from below go 1.16 to above it), and may even
require switching to a newer toolchain (if the version is not
supported by the current one).
For #57001.
Change-Id: Ic8e9b87d5979b3a6d1ee70f1f2bf2eea46b1bb0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/499676
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
When we do 'go get', the Go version can change now.
That means we need to do the pruning conversions that
until now have only been necessary in go mod tidy -go=version.
We may also need to upgrade the toolchain in order to load enough o
the module graph to finish the edit, so we should let a TooNewError
bubble up to the caller instead of trying to downgrade the affected
module to avoid the error.
Revised from CL 498120.
For #57001.
Change-Id: Ic8994737eca4ed61ccc093a69e46f5a6caa8be87
Reviewed-on: https://go-review.googlesource.com/c/go/+/498267
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
'go mod tidy -go=1.20' should tidy as Go 1.20 did, without writing a
toolchain line implicitly. (We don't need it to stabilize toolchain
version switching anyway: because Go 1.20 predates toolchain
switching, any toolchain that supports switching toolchains also
supports Go 1.20 modules directly.)
For #57001.
Change-Id: I415abac75d8d6de9f8ed470aab0d1ed4c225b08d
Reviewed-on: https://go-review.googlesource.com/c/go/+/499987
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Interface inference must only be used if we don't require exact
unification, otherwise we may infer types (that are reasonable)
but then fail with an assignment error.
Only checking if exact is set for defined (named) types is not
sufficient, we must also check outside. Oversight.
Fixes#60562.
Change-Id: I208a74bf7ed80bcb976ba9cc172715c83f9e3d0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/499996
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
As spotted in CL 499981, 3 out of 51 of the api/next/*.txt files
ended up with a blank line at the end. It's possible it would've
been more if human reviewers didn't catch them.
Since there's no formatter for these files, the only way to help
catch things is to make the check pickier (as done in CL 431335).
It can be loosened to let in useful blank lines if needed in the
future.
Change-Id: Iae7ee8e782b32707c576150914539ac4cc0faec4
Reviewed-on: https://go-review.googlesource.com/c/go/+/500115
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The "To" prefix was a relic of the first draft
that I failed to make consistent with the unprefixed
name used in the proposal. Fortunately iant spotted
it during the API audit.
Updates #56984
Updates #60560
Change-Id: Ifa6eeddf6dd5f0637c0568e383f9a4bef88b10f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/500116
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Alan Donovan <adonovan@google.com>
Many many places in the go command use
base.Errorf("go: %v", err)
or
base.Fatalf("go: %v", err)
Introduce Error(error) and Fatal(error) to do this
and update all call sites (global search and replace).
The new Error gives us the opportunity to unwrap
a multierror and add the go prefix to each line,
which is the motivation for this change.
(We want to start returning a multierror from LoadModFile
and LoadModGraph.)
For #57001.
Change-Id: I9613653b94808224146077c30d22f814d4e19eed
Reviewed-on: https://go-review.googlesource.com/c/go/+/499980
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
The tests in this package are meant to check cgocheck and cgocheck2
mode, so they're of course sensitive to whether they're set.
Currently, the test will set GOEXPERIMENT=cgocheck2 for tests of
cgocheck2 mode, but won't *unset* cgocheck2 mode if it's already in
the environment for tests that expect it to be off. This means
GOEXPERIMENT=cgocheck2 go test cmd/cgo/internal/testerrors
fails.
Fix this by removing cgocheck2 from GOEXPERIMENT if it's set and the
test case expects it to be unset.
Change-Id: If663e41b791fb89df9940bc5356a566e2a54a77a
Reviewed-on: https://go-review.googlesource.com/c/go/+/499557
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Previously, codesign.Sign was called with Segtext.Fileoff and
Segtext.Filelen. However, both variables do not contain the
complete __TEXT segment, as it excludes padding and header.
Therefore, we now store a reference to the complete segment
in mstext when it is created and pass its offset (which should
always be 0) and filesize to codesign.Sign.
Fixes#59555
Change-Id: Iad88f142705949dcc0b192b811337df9b4be08cf
GitHub-Last-Rev: 37a048d58e
GitHub-Pull-Request: golang/go#59581
Reviewed-on: https://go-review.googlesource.com/c/go/+/484015
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
modcmd is a high-level command, but toolchain is a low-level building
block. A dependency from toolchain on modcmd makes it very difficult
to call from other lower-level packages without creating an import
cycle.
Instead, use modfetch.Download in place of modcmd.DownloadModule.
For #57001.
Change-Id: I9694706d7225b269f26dc68814894613a3329abb
Reviewed-on: https://go-review.googlesource.com/c/go/+/499316
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Currently lockextra always increments extraMInUse, even if the M won't
be used (or doesn't even exist), such as in addExtraM. addExtraM fails
to decrement extraMInUse, so it stays elevated forever.
Fix this bug and simplify the model by moving extraMInUse out of
lockextra to getExtraM, where we know the M will actually be used.
While we're here, remove the nilokay argument from getExtraM, which is
always false.
Fixes#60540.
Change-Id: I7a5d97456b3bc6ea1baeb06b5b2975e3b8dd96a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/499677
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Some files already use "slices", others use "cmd/go/internal/slices".
(Some files are using more than slices.Clip and must use "slices".)
Use "slices" consistently and delete cmd/go/internal/slices.
Change-Id: I69ec680106ad2924276f7473e6547a3a907efc96
Reviewed-on: https://go-review.googlesource.com/c/go/+/499715
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
We were using the omission of toolchain from the MVS graph
as a signal that toolchain was not mentioned on the go get line,
but not including it in the graph causes various problems,
and it may be reintroduced to the graph during operations like
pruning conversion, after which its presence is not a good signal
about whether it was mentioned on the go get command line.
Fix all this irregularity by explicitly telling WriteGoMod whether
the command line mentioned toolchain instead.
For #57001.
Change-Id: I74084637c177c30918fdb114a0d9030cdee7324e
Reviewed-on: https://go-review.googlesource.com/c/go/+/499575
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
For a unification failure involving a constraint, rather than just
reporting (for instance)
S does not match []E
now report the inferred type for the type parameter, use spec
terminology when referring to the constraint, and print the
constraint in full:
S (type func()) does not satisfy ~[]E
There's more we can do, but this is better than what we had.
For #60542.
Change-Id: I033369fa0dfc475f0ec0da0582e8cbefb109f3cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/499639
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Currently the BenchmarkSetType* benchmarks are racy: they call
heapBitsSetType on an allocation that might be in a span in-use for
allocation on another P. Because heap bits are bits but are written
byte-wise non-atomically (because a P assumes it has total ownership of
a span's bits), two threads can race writing the same heap bitmap byte
creating incorrect metadata.
Fix this by forcing every value we're writing heap bits for into a large
object. Large object spans will never be written to concurrently unless
they're freed first.
Also, while we're here, refactor the benchmarks a bit. Use generics to
eliminate the reflect nastiness in gc_test.go, and pass b.ResetTimer
down into the test to get slightly more accurate results.
Fixes#60050.
Change-Id: Ib7d6249b321963367c8c8ca88385386c8ae9af1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/497215
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL is a no-op, just adding the new options and plumbing it through.
'go get' will use this option to let commitRequirements know whether
toolchain was mentioned explicitly on the command line.
For #57001.
Change-Id: Iee7145f3335e899704df3e98fb840f1aa4063b0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/499555
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This happens mainly during testing because the virtual
toolchain switch is not terribly robust, and if you accidentally
try to exec "1.23" instead of "go1.23" it will let you, but it
won't work right.
Of course, although we feel pretty good about the non-test
implementation, perhaps it has a toolchain switch loop lurking too,
or perhaps one will be introduced in the future.
To handle the test bug, and just in case we have a real bug later,
add detection of toolchain switch loops with clear messages.
Also fixes a bug in setting the -lang flag properly when invoking
the Go compiler: this is the first test using 'go 1.21.x' lines
during a build.
For #57001.
Change-Id: I0ece3dd718596689a23b677cf08ddf32ea97bc57
Reviewed-on: https://go-review.googlesource.com/c/go/+/498436
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test was introduced as a regression test for #60276. However, it
was quite flaky on a number of different platforms because there are
myriad ways the runtime can eat into time one might expect is completely
idle.
This change re-enables the test, but makes it much more resilient.
Because the issue we're testing for is persistent, we now require 10
consecutive failures to count. Any single success counts as a test
success. This change also makes the test's idle time bound more lenient,
allowing for a little bit of time to be eaten up. The regression we're
testing for results in nearly zero idle time being accounted for.
If this is still not good enough to eliminate flakes, this test should
just be deleted.
For #60276.
Fixes#60376.
Change-Id: Icd81f0c9970821b7f386f6d27c8a566fee4d0ff7
Reviewed-on: https://go-review.googlesource.com/c/go/+/498274
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
NewerToolchain needs a list of candidate toolchains.
Currently it always consults the module version list, using the network.
When GOTOOLCHAIN=path, it should probably not do this,
both because =path implies we don't want to use the network
and because not every released version will be in $PATH.
Instead, scan $PATH to find the available versions.
For #57001.
Change-Id: I478612c88d1504704a3f53fcfc73d8d4eedae493
Reviewed-on: https://go-review.googlesource.com/c/go/+/499296
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
This patch fixes a problem with the way pods (clumps of related
coverage meta+counter data files) are collected, which was causing
problems for "go tool covdata subtract".
A subtract operation such as "go tool covdata subtract -i=dir1,dir2
-o=out" works by loading in all the counter data files from "dir1"
before any of the data files from "dir2" are loaded. The sorting
function in the pods code was sorting counter files for a given pod
based purely on name, which meant that differences in process ID
assignment could result in some files from "dir2" being presented
before "dir1". The fix is to change the sorting compare function to
prefer origin directory over filename.
Fixes#60526.
Change-Id: I2226ea675fc99666a9a28e6550d823bcdf2d6977
Reviewed-on: https://go-review.googlesource.com/c/go/+/499317
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change defines two unification modes used to control unification:
- assign set when unifying types involved in an assignment
- exact if set, types unify if they can be made identical
Currently, unification is inexact: when a defined type is compared
against a type literal, the underlying type of the defined type is
considered. When channel types are compared, the channel direction
is ignored. And when defined types are compared where one (or both)
are interfaces, interface unification is used.
By contrast, exact unification requires types to match exactly:
if they can be unified, the types must be identical (with suitable
type arguments).
Exact unification is required when comparing component types.
For instance, when unifying func(x P) with func(x Q), the two
signatures unify only if P is identical to Q per Go's assignment
rules.
Until now we have ignored exact unification and made due with inexact
unification everywhere, even for component types. In some cases this
led to infinite recursions in the unifier, which we guarded against
with a depth limit (and unification failure).
Go's assignmemt rules allow inexact matching at the top-level but
require exact matching for element types.
This change passes 'assign' to the unifier when unifying parameter
against argument types because those follow assignment rules.
When comparing constraints, inexact unification is used as before.
In 'assign' mode, when comparing element types, the unifyier is
called recursively, this time with the 'exact' mode set, causing
element types to be compared exactly. If unification succeeds for
element types, they are identical (with suitable type arguments).
This change fixes#60460. It also fixes a bug in the test for
issue #60377. We also don't need to rely anymore on the recursion
depth limit (a temporary fix) for #59740. Finally, because we use
exact unification when comparing element types which are channels,
errors caused by assignment failures (due to inexact inference which
succeeded when it shouldn't have) now produce the correct inference
error.
Fixes#60460.
For #60377.
For #59740.
Change-Id: Icb6a9b4dbd34294f99328a06d52135cb499cab85
Reviewed-on: https://go-review.googlesource.com/c/go/+/498895
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Pass a mode parameter through all unifier calls but make no use of it.
When unifying type elements (components of composite types), use emode,
which currently is set to mode.
Preparatory step to fix#60460. Factoring out this mechanical change
will make the actual fix smaller and easier to review and understand.
Because this change doesn't affect the behavior of the unifier, it is
safe.
For #60460.
Change-Id: I5b67499d93025be2128c14cc00bcc3b8cc9f44b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/498955
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
With the introduction of runtime.Pinner, we need to update the cgo
pointer passing rules to accomodate the new functionality. These rule
changes are easier to describe if the rest of the pointer passing rules
are described in terms of pinning as well (Go memory is implicitly
pinned when a pointer to it is passed to a C function, and implicitly
unpinned when that function returns).
For #46787.
Change-Id: I263f03412bc9165f19c9ada72fb005ed0483a8ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/498116
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
The design doc says 'toolchain' lines apply even if the default
toolchain is older than the one specified in the toolchain line.
However, that leads to various confusing behavior and security issues.
Instead, treat toolchain as a min go version that only applies
in the current module (not in dependencies).
As an example of confusing behavior / security issue, if I install
Go 1.30 and then run 'go build' in a module I've checked out,
I expect to use Go 1.30 or newer, not to silently use an older toolchain
that may have security problems fixed in Go 1.30.
Making toolchain a min establishes that guarantee.
Also clean up the tests quite a bit.
Finally drop + from the acceptable version suffixes; we use + for +auto and +path.
For #57001.
Change-Id: Ia92c66be75d6d0e31cb4e2c0aa936fa4ec5c0a8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/498260
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
If we run 'go get go@1.40' or 'go get m@v' where m has a go.mod
that says 'go 1.40', we need to write a new go.mod that says 'go 1.40'.
But we can't be sure we know how to write a Go 1.40-compatible go.mod.
Instead, download the latest point release of Go 1.40 and invoke it to
finish the get command.
For #57001.
Change-Id: I4133fc3c2ecf91226a6c09a3086275ecc517e223
Reviewed-on: https://go-review.googlesource.com/c/go/+/498118
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
This patch reverts a portion of the changes in CL 443715, specifically
the code in initorder that treats coverage counter variables as special
with respect to init order. The special casing is no longer needed
now after a change to the way coverage instrumention is done (the go and
cover cmds now make sure that coverage variables appear first in
the compilation order).
Updates #56293.
Change-Id: Idf803ff4c1a095e88d455a6adcd63991687eb288
Reviewed-on: https://go-review.googlesource.com/c/go/+/499216
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This patch contains a revised fix for issue #56293, switching to a
scheme in which coverage counter variables and meta-data variables are
written to a separate output file as opposed to being tacked onto the
end of an existing rewritten source file.
The advantage of writing counter vars to a separate file is that the
Go command can then present that file as the first source file to the
compiler when the package is built; this will ensure that counter
variable are treated as lexically "before" any other variable that
might call an instrumented function as part of its initializer.
Updates #56293.
Change-Id: Iccb8a6532b976d36ccbd5a2a339882d1f5d19477
Reviewed-on: https://go-review.googlesource.com/c/go/+/499215
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Before CL 471595, modload.readModGraph in module with graph pruning
enabled only ever chased down transitive dependencies of unpruned
roots, so pruned dependencies couldn't cause cycles and we didn't
need to dedup them in the loading queue.
However, in 'go get' we are now passing in a set of upgraded modules
to unprune, and those upgraded modules can potentially contain cycles,
leading to an infinite loop during loading.
We have two options for a fix: we could either drop the 'unprune'
check in the enqueue operation (and instead expand the 'unprune'
requirements in a separate pass, as we do in workspace mode), or we
could check for cycles for all modules (not just the ones that are
naturally unpruned). The latter option makes it clearer that this
process must terminate, so we choose that.
(It may be possible to clean up and simplify the workspace-mode case
now that we are passing in the 'unprune' map, but for now we're
looking for a minimal fix for the Go 1.21 release.)
Fixes#60490.
Change-Id: I701f5d43a35e357f6c0c0c9d10b7aa088f917311
Reviewed-on: https://go-review.googlesource.com/c/go/+/499195
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Currently we only track visited (copied) packages when a copy is
required. When a copy is not required, we will rewalk each package's
entire dependency graph every time we see it, which is terribly
inefficient.
Pull the visited package check up a level so that we visit packages only
once regardless of how many times they are visited.
Fixes#60455.
Fixes#60428.
Change-Id: I4e9b31eeeaa170db650c461a5de2ca984b9aba0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/498735
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
The go command already places $GOROOT/bin at the beginning of $PATH in
the test's environment as of Go 1.19¹, so there's no need for the test
to do it anymore. Start enjoying yet another benefit of using 'go test'.
¹ See go.dev/issue/57050.
For #56844.
Change-Id: If7732cd8b8979eabf185485d3c73858a4e546d69
Reviewed-on: https://go-review.googlesource.com/c/go/+/498271
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>
This comment claims mark termination re-scans stacks and uses the
write barrier to determine how much of the stack needs to be
rescanned. This hasn't been true since we introduced the hybrid write
barrier and deleted stack rescanning with CL 31766 in Go 1.8.
Updates #17503 I suppose.
Change-Id: I5e90f25020c9fa6f146ec6ed0642ba2b4884c2a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/498435
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
A reference to a function in a "var _ = ..." init-time
initialization keeps the symbol live. Move references to
Config.EncryptTicket and Config.DecryptTicket into tests.
These references increase the size of an unused import of
crypto/tls by about 1MiB.
Change-Id: I6d62a6dcbd73e22972a217afcda7395e909b52cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/498595
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The earlier CL 497675 for #60304 introduced a behavior change
that, while not strictly a bug, caused a bunch of test failures
in a large codebase. Rather than add behavior changes in a 10 year
old package, revert to the old behavior: a context cancelation
between Rows.Next reporting false and a call to Rows.Err should
not result in Rows.Err returning the context error.
That behavior was accidentally added in CL 497675 as part of changing
how contexts and Rows iteration worked.
Updates #60304
Updates #53970
Change-Id: I22f8a6a6b0b5a94b430576cf50e015efd01ec652
Reviewed-on: https://go-review.googlesource.com/c/go/+/498398
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Showing the full path (relative to the current directory)
instead of just foo.txt lets editors that understand file:line
jump straight to the file without having to edit it to say
testdata/script/ first.
Change-Id: I44177b687249f3c7c724b45d02f5167607369e1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/498119
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Two interface types that are assignable don't have to be identical;
specifically, if they are defined types, they can be different
defined types. If those defined types specify type parameters which
are never used, do not infer a type argument based on the instantiation
of a matching defined type.
Adjusted three existing tests where we inferred type arguments incorrectly.
Fixes#60377.
Change-Id: I91fb207235424b3cbc42b5fd93eee619e7541cb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/498315
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
A var is problematic because the zero value is already false,
so if it goes away, it will appear to be false.
I'm also not sure about go:linkname on vars,
so switch to func for both reasons.
Also add a test.
Change-Id: I2318a5390d98577aec025152e65543491489defb
Reviewed-on: https://go-review.googlesource.com/c/go/+/498261
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
go get go@version and toolchain@version updates the
go and toolchain lines in go.mod. If toolchain ends up <= go,
it is dropped.
When the go version crosses certain version boundaries,
it may be necessary to run 'go mod tidy -go=version'.
That's left for a followup CL.
When the go or toolchain version ends up higher than the
current toolchain version, we cannot be sure we know how
to write the file out, so we fail with an error message.
In GOTOOLCHAIN auto mode, the newer toolchain should
be downloaded and reinvoked; that's left for a followup CL too.
For #57001.
Change-Id: Ibfdcc549b40555a53bdb2d019816d18f1bd16be6
Reviewed-on: https://go-review.googlesource.com/c/go/+/497081
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
In general an older version of Go does not know how to construct
a module written against a newer version of Go: the details may
change over time, such as for issues like #42965 (an ignore mechanism).
For #57001.
Change-Id: Id43fcfb71497375ad2eb5dfd292bad0adca0652e
Reviewed-on: https://go-review.googlesource.com/c/go/+/497795
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 498255 made runtime/internal/wasitest compatible with all platforms
so that "go test std" works again. This means it no longer has to be
in the special dist test list.
While we're here explain the purpose of this list better and implore
people to please not expand it, since almost any addition is a sign
that "go test std cmd" no longer works.
Change-Id: I31c7fb767787fa587f65c2697aed9ed43e95fb18
Reviewed-on: https://go-review.googlesource.com/c/go/+/498256
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Austin Clements <austin@google.com>
Disable the android and ios builds since cross-compiling fails there.
Also make runtime/internal/wasitest not build on systems that don't
have syscall.Mkfifo for it to use (including, ironically, wasm itself).
Change-Id: I28eb1f216f9952f81a107056e97ee38e350f9287
Reviewed-on: https://go-review.googlesource.com/c/go/+/498255
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
heapObjectsCanMove is always false in the current garbage collector.
It exists for go4.org/unsafe/assume-no-moving-gc, which is an
unfortunate idea that had an even more unfortunate implementation.
Every time a new Go release happened, the package stopped building,
and the authors had to add a new file with a new //go:build line, and
then the entire ecosystem of packages with that as a dependency had to
explicitly update to the new version. Many packages depend on
assume-no-moving-gc transitively, through paths like
inet.af/netaddr -> go4.org/intern -> assume-no-moving-gc.
This was causing a significant amount of friction around each new
release, so we added this bool for the package to //go:linkname
instead. The bool is still unfortunate, but it's not as bad as
breaking the ecosystem on every new release.
If the Go garbage collector ever does move heap objects, we can set
this to true to break all the programs using assume-no-moving-gc.
Change-Id: I06c32bf6ccc4601c8eef741d7382b678aada3508
Reviewed-on: https://go-review.googlesource.com/c/go/+/498121
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Invoking 'hg' in a nonexistant HOME can break extensions the user
may have installed; clear HGRCPATH in the script test to keep tests
working in that environment.
Change-Id: I4d21d024c6229ead38e5f24186883863511fd483
Reviewed-on: https://go-review.googlesource.com/c/go/+/497878
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
We used to inconsistently run certificate verification on the server on
resumption, but not on the client. This made TLS 1.3 resumption pretty
much useless, as it didn't save bytes, CPU, or round-trips.
This requires serializing the verified chains into the session ticket,
so it's a tradeoff making the ticket bigger to save computation (and for
consistency).
The previous behavior also had a "stickyness" issue: if a ticket
contained invalid certificates, they would be used even if the client
had in the meantime configured valid certificates for a full handshake.
We also didn't check expiration on the client side on resumption if
InsecureSkipVerify was set. Again for consistency, we do that now.
Also, we used to run VerifyPeerCertificates on resumption even if
NoClientCerts was set.
Fixes#31641
Change-Id: Icc88269ea4adb544fa81158114aae76f3c91a15f
Reviewed-on: https://go-review.googlesource.com/c/go/+/497895
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
All OpenSSL tests now test operation with EMS. To test a handshake
*without* EMS we need to pass -Options=-ExtendedMasterSecret which is
only available in OpenSSL 3.1, which breaks a number of other tests.
Updates #43922
Change-Id: Ib9ac79a1d03fab6bfba5fe9cd66689cff661cda7
Reviewed-on: https://go-review.googlesource.com/c/go/+/497376
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Implements net.FileListener and net.FileConn for wasip1.
net.FileListener can be used with a pre-opened socket. If the WASM
module knows the file descriptor, a listener can be constructed with:
l, err := net.FileListener(os.NewFile(fd, ""))
If the WASM module does not know the file descriptor, but knows that at
least one of the preopens is a socket, it can find the file descriptor
and construct a listener like so:
func findListener() (net.Listener, error) {
// We start looking for pre-opened sockets at fd=3 because 0, 1,
// and 2 are reserved for stdio. Pre-opened directories also
// start at fd=3, so we skip fds that aren't sockets. Once we
// reach EBADF we know there are no more pre-opens.
for preopenFd := uintptr(3); ; preopenFd++ {
l, err := net.FileListener(os.NewFile(preopenFd, ""))
var se syscall.Errno
switch errors.As(err, &se); se {
case syscall.ENOTSOCK:
continue
case syscall.EBADF:
err = nil
}
return l, err
}
}
A similar strategy can be used with net.FileConn and pre-opened
connection sockets.
The wasmtime runtime supports pre-opening listener sockets:
$ wasmtime --tcplisten 127.0.0.1:8080 module.wasm
Change-Id: Iec6ae4ffa84b3753cce4f56a2817e150445db643
Reviewed-on: https://go-review.googlesource.com/c/go/+/493358
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
There was a bug in TestResumption: the first ExpiredSessionTicket was
inserting a ticket far in the future, so the second ExpiredSessionTicket
wasn't actually supposed to fail. However, there was a bug in
checkForResumption->sendSessionTicket, too: if a session was not resumed
because it was too old, its createdAt was still persisted in the next
ticket. The two bugs used to cancel each other out.
For #60105Fixes#19199
Change-Id: Ic9b2aab943dcbf0de62b8758a6195319dc286e2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/496821
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Ever since session ticket key rotation was introduced in CL 9072, we've
been including a prefix in every ticket to identify what key it's
encrypted with. It's a small privacy gain, but the cost of trial
decryptions is also small, especially since the first key is probably
the most frequently used.
Also reissue tickets on every resumption so that the next connection
can't be linked to all the previous ones. Again the privacy gain is
small but the performance cost is small and it comes with a reduction in
complexity.
For #60105
Change-Id: I852f297162d2b79a3d9bf61f6171e8ce94b2537a
Reviewed-on: https://go-review.googlesource.com/c/go/+/496817
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The existing implementation allocates a new 4KB buffer each time it opens flate-encoded file in a zip archive. This commit allows the flate reader to reuse the buffer on call Reset instead of allocating a new one.
It is noticeable when a zip archive contains a huge amount of files, e.g. zip archive has 50_000 files, for each file 4KB buffer is allocated, so it is 200MB memory allocations. If files are read sequentially only one buffer is needed.
Fixes#59774
Change-Id: Ib16336b101ba58e8f0f30a45dc5fd4eeebc801a1
GitHub-Last-Rev: f3f395b2ad
GitHub-Pull-Request: golang/go#59775
Reviewed-on: https://go-review.googlesource.com/c/go/+/487675
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Previously, the field Var for T created for struct{p.T}
would use the Pos of the ast.Field, which coincides with p.
This change makes it use the Pos of T.
Errors about the field type are still reported at the
position of the ast.Field (e.g. *p.T) not the field T.
Fixes#60372
Change-Id: I06000874f2018d47159493626da3d16e6716f4c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497882
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
I came across similar issue in CL 455275.
Without rooting this, the search domains might affect
the query, so the test might not prove the right thing.
The search domain will cause a change from no data
to NXDOMAIN error.
Change-Id: I59f4de2635f03c69adf29b74e25e4ebd71e7413b
GitHub-Last-Rev: 3a086c74f1
GitHub-Pull-Request: golang/go#60197
Reviewed-on: https://go-review.googlesource.com/c/go/+/494896
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
RSA encryption and verification performs an exponentiation by a value
usually just a few bits long. The current strategy with table
precomputation is not efficient.
Add an ExpShort bigmod method, and use it in RSA public key operations.
After this, almost all CPU time in encryption/verification is spent
preparing the constants for the modulus, because PublicKey doesn't have
a Precompute function.
This speeds up signing a bit too, because it performs a verification to
protect against faults.
name old time/op new time/op delta
DecryptPKCS1v15/2048-4 1.13ms ± 0% 1.13ms ± 0% -0.43% (p=0.000 n=8+9)
DecryptPKCS1v15/3072-4 3.20ms ± 0% 3.15ms ± 0% -1.59% (p=0.000 n=10+8)
DecryptPKCS1v15/4096-4 6.45ms ± 0% 6.42ms ± 0% -0.49% (p=0.000 n=10+10)
EncryptPKCS1v15/2048-4 132µs ± 0% 108µs ± 0% -17.99% (p=0.000 n=10+10)
DecryptOAEP/2048-4 1.13ms ± 0% 1.14ms ± 0% +0.91% (p=0.000 n=10+10)
EncryptOAEP/2048-4 132µs ± 0% 108µs ± 0% -18.09% (p=0.000 n=10+10)
SignPKCS1v15/2048-4 1.18ms ± 0% 1.14ms ± 1% -3.30% (p=0.000 n=10+10)
VerifyPKCS1v15/2048-4 131µs ± 0% 107µs ± 0% -18.30% (p=0.000 n=9+10)
SignPSS/2048-4 1.18ms ± 0% 1.15ms ± 1% -1.87% (p=0.000 n=10+10)
VerifyPSS/2048-4 132µs ± 0% 108µs ± 0% -18.30% (p=0.000 n=10+9)
Updates #57752
Change-Id: Ic89273a58002b32b1c5c3185a35262694ceef409
Reviewed-on: https://go-review.googlesource.com/c/go/+/492935
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Put the sections for the various built-ins into alphabetical order
based on the built-in name, while keeping built-ins that belong
together together.
The order is now (captialized letter determines order):
- Append
- Clear
- Close
- Complex, real, imag
- Delete
- Len, cap
- Make
- Min, max (to be inserted here)
- New
- Panic, recover
- Print, println
There are some white space adjustments but no changes to the prose
of the moved sections.
Change-Id: Iaec509918c6bc965df3f28656374de03279bdc9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/498135
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
When 'go env' without an argument prints environment variables as
a script which can be executed by the shell, variables with a
list value in Plan 9 (such as GOPATH) need to be printed with each
element enclosed in single quotes in case it contains characters
significant to the Plan 9 shell (such as ' ' or '=').
For #58508
Change-Id: Ia30f51307cc6d07a7e3ada6bf9d60bf9951982ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/493535
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
CL 497075 refactored NewFile to unconditionally dereference the file
returned by newFile. However, newFile can return nil if passed a
negative FD, which now causes a crash.
Resolve this by moving the invalid check earlier in NewFile, which also
lets us avoid a useless fcntl syscall on a negative FD.
Since we convert to int to check sign, adjust newFile to take an int
rather than uintptr, which cleans up a lot of conversions.
Fixes#60406
Change-Id: I382a74e22f1cc01f7a2dcf1ff4efca6a79c4dd57
Reviewed-on: https://go-review.googlesource.com/c/go/+/497877
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The actual selection code already worked
(except for the x/mod parser not reading the file),
so all that is necessary is a test.
For the test, move the version check up before
the module line presence check.
For #57001.
Change-Id: Iaa4f9b92d38fcfd99dc1665ec8d3eb0e52007bb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/497555
TryBot-Bypass: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Before this CL, the documentation for Formatter suggested that
implementers of Format(f State, verb rune) could use Fprint(f) or
Sprint(f) to generate output. The Sprint(f) suggestion however is
invalid.
Fix that by simply suggesting Sprint() alongside Fprint(f).
Fixes#60358
Change-Id: I024e996f6360b812968ef2cd5073cb4c223459e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/497379
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently /gc/scan/total:bytes is computed as a separate sum. Compute it
using the same inputs so it's always consistent with the sum of
everything else in /gc/scan/*.
For #56857.
Change-Id: I43d9148a23b1d2eb948ae990193dca1da85df8a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/497880
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Use io.Copy¹ that matches the comment more closely, avoids the
possibility of needing a bigger array, and is slightly shorter.
Its downside is that it takes two w.Write calls instead of one.
¹ Admittedly, it was temping to use io.CopyBuffer since the 'data'
byte slice becomes a viable buffer after its contents are written.
I resisted that temptation for two reasons.
One, it would need the io.Reader returned by dec.Buffered() (currently
a *bytes.Reader) to not implement the io.WriterTo interface for any
chance of making a positive difference. This seems not very likely.
Two, to avoid burdening anyone with determining that io.CopyBuffer
won't panic without 'if len(data) == 0 && data != nil { data = nil }'
because json.Marshal never returns an empty but non-nil byte slice.
Change-Id: I33c53d9d990f6ee79cd3ab90f12e3b575b9ebe72
Reviewed-on: https://go-review.googlesource.com/c/go/+/497736
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
In contrast to the HasSuffix argument, there's no need or benefit in
having a ":" before the "racebench" variant mentioned in the message.
(The variant comes after the colon separator—it doesn't include it.)
Change-Id: Ie9948104de9449422037bf39245944255b98f1b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/497735
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
build_pgo.txt hard-coded a check for / rather than using ${/}, causing a
failure on Windows
The failure in build_pgo_auto_multi.txt is more interesting. If the
first argument to stdout starts with `-` the script engine expects it to
be a flag to grep, and thus doesn't regexp-escape `\` in the expansion
of `${/}`.
The script engine doesn't _require_ that these are flags to grep, so it
is still possible to use them for matching, but this ideally will change
in the future, so change all patterns to avoid starting with `-`.
Fixes#60408.
Change-Id: Ie4041a730d22ce40a4436abae7713f211dcb42e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/497881
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In theory by allocating new objects every time, the benchmark is
including the performance of allocating new pinner bits for a span. In
practice however, most of the time each span already does have pinner
bits allocated (it's still a rare operation).
We can get a better sense of the raw cost of pinning an object (minus
pinner bits allocation) by moving the object allocation out of the inner
loop.
Change-Id: I2869fa6c3f353b726fe8440d2e6b7f89902f9364
Reviewed-on: https://go-review.googlesource.com/c/go/+/497620
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Name constraints are checked during path building. When a new
certificate is considered for inclusion in a chain we check if it has
name constraints, and if it does, check that they apply to the certs
already in the chain, discarding it if the current chain violates any
of the constraints the candidate introduces.
This check was not acting as intended in two ways. The first was that
we only checked that the constraints on the candidate certificate
applied to the leaf certificate, and not the rest of the certiifcates in
the chain. This was the intended behavior pre-1.19, but in 1.19 we
intended for the constraints to be applied to the entire chain (although
obviously they were not).
The second was that we checked that the candidates constraints applied
to the candidate itself. This is not conformant with RFC 5280, which
says that during path building the constraint should only be applied to
the certificates which follow the certificate which introduces the
constraint (e.g. in the chain A -> B -> C, if certificate Bcontains a
name constraint, the constraint should only apply to certificate C).
The intended behavior introduced in 1.19 was mainly intended to reject
dubious chains which the WebPKI disallows, and are relatively rare, but
don't have significant security impact. Since the constraints were
properly applied to the leaf certificate, there should be no real impact
to the majority of users.
Fixes#59171
Change-Id: Ie6def55b8ab7f14d6ed2c09351f664e148a4160d
Reviewed-on: https://go-review.googlesource.com/c/go/+/478216
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test is fundamentally flaky because of a mismatch between how
internal idle time is calculated and how the test expects it to be
calculated. It's unclear how to resolve this mismatch, given that it's
perfectly valid for a goroutine to remain asleep while background
goroutines (e.g. the scavenger) run. In practice, we might be able to
set some generous lower-bound, but until we can confirm that on the
affected platforms, skip the test as flaky unconditionally.
For #60276.
For #60376.
Change-Id: Iffd5c4be10cf8ae8a6c285b61fcc9173235fbb2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/497876
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
setPGOProfilePath sets Package.Internal.PGOProfile very late in package
loading (because it may split/copy packages). Build info was computed
long before this, causing PGO packages to miss -pgo from their build
settings.
Adjust BuildInfo to be stored as *debug.BuildInfo rather than eagerly
converting to a string. This enables setPGOProfilePath to update the
BuildInfo at the same point that it sets PGOProfile.
Change-Id: Ic12266309bfd0f8ec440b0dc94d4df813b27cb04
Reviewed-on: https://go-review.googlesource.com/c/go/+/496958
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
name old time/op new time/op delta
Values-10 8.67ms ± 0% 7.19ms ± 2% -17.05% (p=0.000 n=9+10)
name old alloc/op new alloc/op delta
Values-10 58.2kB ± 2% 48.3kB ± 2% -17.14% (p=0.000 n=9+10)
name old allocs/op new allocs/op delta
Values-10 0.00 0.00 ~ (all equal)
Change-Id: Idd35ea37514a21d97bdd6191c8fb8a478c00e414
Reviewed-on: https://go-review.googlesource.com/c/go/+/481436
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: xie cui <523516579@qq.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Before this CL the code would record the number of race detector
errors seen before starting a test, and then report an error
if there were more race detector errors after the test completed.
That approach did not work well for subtests or parallel tests.
Race detector errors could be reported multiple times at each
level of subtest, and parallel tests could accidentally drop
race detector errors.
Instead, report each race detector error at most once, associated
with whatever test noticed the new error. This is still imperfect,
as it may report race detector errors for the wrong parallel test.
But it shouldn't drop any errors entirely, and it shouldn't report
any errors more than once.
Fixes#60083
Change-Id: Ic9afea5c692b6553896757766f631cd0e86192ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/494057
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
sql.RawBytes was added the very first Go release, Go 1. Its docs
say:
> RawBytes is a byte slice that holds a reference to memory owned by
> the database itself. After a Scan into a RawBytes, the slice is only
> valid until the next call to Next, Scan, or Close.
That "only valid until the next call" bit was true at the time,
until contexts were added to database/sql in Go 1.8.
In the past ~dozen releases it's been unsafe to use QueryContext with
a context that might become Done to get an *sql.Rows that's scanning
into a RawBytes. The Scan can succeed, but then while the caller's
reading the memory, a database/sql-managed goroutine can see the
context becoming done and call Close on the database/sql/driver and
make the caller's view of the RawBytes memory no longer valid,
introducing races, crashes, or database corruption. See #60304
and #53970 for details.
This change does the minimal surgery on database/sql to make it safe
again: Rows.Scan was already acquiring a mutex to check whether the
rows had been closed, so this change make Rows.Scan notice whether
*RawBytes was used and, if so, doesn't release the mutex on exit
before returning. That mean it's still locked while the user code
operates on the RawBytes memory and the concurrent context-watching
goroutine to close the database still runs, but if it fires, it then
gets blocked on the mutex until the next call to a Rows method (Next,
NextResultSet, Err, Close).
Updates #60304
Updates #53970 (earlier one I'd missed)
Change-Id: Ie41c0c6f32c24887b2f53ec3686c2aab73a1bfff
Reviewed-on: https://go-review.googlesource.com/c/go/+/497675
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
This change adds a generator which creates a Markdown file for each
compiler error code which includes its associated documentation. The
Markdown files will be added to the x/website repository and used
to generate short error links on the Go website.
Change-Id: Ibabc3388d6ecc7f19151f3931554f72561e30b22
Reviewed-on: https://go-review.googlesource.com/c/go/+/495858
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
sparse conditional constant propagation can discover optimization opportunities that cannot be found by just combining constant folding and constant propagation and dead code elimination separately.
Updates #59399
Change-Id: Ia954e906480654a6f0cc065d75b5912f96f36b2e
GitHub-Last-Rev: 90fc02db99
GitHub-Pull-Request: golang/go#59575
Reviewed-on: https://go-review.googlesource.com/c/go/+/483875
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Before this CL, we use GetFrom3&SetFrom3 to get or set a source operand
which not fit into Prog.Reg. Those APIs operate the first element in
Prog.RestArgs without checking the type so they're fragile to break if
we have more than one different type of operands in the slice, which
will be a common case in Arm64.
This CL deprecates & renames some APIs related to Prog.RestArgs to make
those APIs more reasonable and robust than before.
Change-Id: I70d56edc1f23ccfffbcd6df34844e2cef2288432
Reviewed-on: https://go-review.googlesource.com/c/go/+/493355
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
With the Garbage collector (GC), we observed a false-sharing between
work.full and work.empty. (referenced most from runtime.gcDrain and
runtime.getempty)
This false-sharing becomes worse and impact performance on multi core
system. On Intel Xeon 8480+ and default GC setting(GC=100), we can
observed top HITM>4% (by perf c2c)caused by it.
After resolveed this false-sharing issue, we can get performance 8%~9.7%
improved. Verify workloads:
DeathStarBench/hotelReservation: 9.7% of RPS improved
https://github.com/delimitrou/DeathStarBench/tree/master/hotelReservation
gRPC-go/benchmark: 8% of RPS improved
https://github.com/grpc/grpc-go/tree/master/benchmark
gRPC-go/benchmark 9 iterations' data with master branch:
master w/ fs opt.
208862.4 246390.9
221680.0 266019.3
223886.9 248789.7
212169.3 257837.8
219922.4 234331.8
197401.7 261627.7
214562.4 255429.7
214328.5 237087.8
229443.2 230591.3
max 229443.2 266019.3 116%
med 214562.4 248789.7 116%
avg 215806.3 248678.5 115%
Change-Id: Ib386de021cd2dbb802a107f487556d848ba9212d
Reviewed-on: https://go-review.googlesource.com/c/go/+/496915
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
This test is meant to detect the effect of Chdir not being
observed in other concurrent goroutines, possible in Plan 9
because each M runs in a separate OS process with its own
working directory. The test depends on Getwd to report the
correct working directory, but if Chdir fails then Getwd
may fail for the same reasons. We add a consistency check
that Stat(Getwd()) and Stat(".") refer to the same file.
Also change channel usage and add a sync.WaitGroup to
ensure test goroutines are not left blocked or running
when the main test function exits.
For #58802
Change-Id: I80d554fcf3617427c28bbe16e5e396367dcfe673
Reviewed-on: https://go-review.googlesource.com/c/go/+/472555
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
In the type checkers, add Config.ErrorURL (or Config._ErrorURL for
go/types) to configure whether and how an error message should report
a URL for errors that have an error code.
In the compiler, configure types2 to report an error URL of the form
" [go.dev/e/XXX]", where XXX stands for the error code, with the URL
appended to the first line of an error.
Rename the compiler flag -url to -errorurl. At the moment this flag
is disabled by default.
Example for a one-line error message:
<pos>: undefined: f [go.dev/e/UndeclaredName]
Example for a multi-line error message:
<pos>: not enough arguments in call to min [go.dev/e/WrongArgCount]
have ()
want (P, P)
Change-Id: I26651ce2c92ad32fddd641f003db37fe12fdb1cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/497715
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
When unifying two types A and B where one or both of them are
interfaces, consider the shared method signatures in unification.
1) If a defined interface (an interface with a type name) is unified
with another (defined) interface, currently they must originate
in the same type declaration (same origin) for unification to
succeed. This is more restrictive than necessary for assignments:
when interfaces are assigned to each other, corresponding methods
must match, but the interfaces don't have to be identical.
In unification, we don't know which direction the assignment is
happening (or if we have an assignment in the first place), but
in any case one interface must implement the other. Thus, we
check that one interface has a subset of the methods of the other
and that corresponding method signatures unify.
The assignment or instantiation may still not be possible but that
will be checked when instantiation and parameter passing is checked.
If two interfaces are compared as part of another type during
unification, the types must be equal. If they are not, unifying
a method subset may still succeed (and possibly produce more type
arguments), but that is ok: again, subsequent instantiation and
assignment will fail if the types are indeed not identical.
2) In a non-interface type is unified with an interface, currently
unification fails. If this unification is a consequence of an
assignment (parameter passing), this is again too restrictive:
the non-interface type must only implement the interface (possibly
among other type set requirements). In any case, all methods of the
interface type must be present in the non-interface type and unify
with the corresponding interface methods. If they don't, unification
will fail either way. If they do, we may infer additional type
arguments. Again, the resulting types may still not be correct but
that will be determined by the instantiation and parameter passing
or assignment checks. If the non-interface type and the interface
type appear as component of another type, unification may now
produce additional type arguments. But that is again ok because the
respective types won't pass instantiation or assignment checks since
they are different types.
This CL introduces a new unifier flag, enableInterfaceInference, to
enable this new behavior. It is currently disabled.
For #60353.
For #41176.
For #57192.
Change-Id: I983d0ad5f043c7fe9d377dbb95f6b9342f36f45f
Reviewed-on: https://go-review.googlesource.com/c/go/+/497656
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This relocation is not (yet?) defined in ELFv2, but has been added to
gnu gas a couple years ago. It is the same reloc as
R_PPC64_REL24_NOTOC, but hints power10 instructions should not be
emitted.
See binutils commit 7aba54da426b9999085d8f84e7896b8afdbb9ca6.
Fixes#60348
Change-Id: Ie953cd7bf1ffc621b498d4dbebb5de1231833c8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/496918
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently the pinner is created outside of the benchmarking loop.
However, this means that we get to reuse the same pinner for each loop;
in general, users are expected to create a pinner for a e.g. a cgo
call and then that variable will expire with the frame it lives in. (If
they can reuse the variable, great! However, I don't expect that to be
common.)
In essence, this benchmarks a harder case. It's not more right or wrong
than the previous version, but the fact that it's a slightly harder case
(that still mostly captures what the original version was capturing) is
useful.
Change-Id: I94987127f54d7bfecd7b8e6a5e632631ea57ad24
Reviewed-on: https://go-review.googlesource.com/c/go/+/497616
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
When unifying two types A and B where one or both of them are
interfaces, consider the shared method signatures in unification.
1) If a defined interface (an interface with a type name) is unified
with another (defined) interface, currently they must originate
in the same type declaration (same origin) for unification to
succeed. This is more restrictive than necessary for assignments:
when interfaces are assigned to each other, corresponding methods
must match, but the interfaces don't have to be identical.
In unification, we don't know which direction the assignment is
happening (or if we have an assignment in the first place), but
in any case one interface must implement the other. Thus, we
check that one interface has a subset of the methods of the other
and that corresponding method signatures unify.
The assignment or instantiation may still not be possible but that
will be checked when instantiation and parameter passing is checked.
If two interfaces are compared as part of another type during
unification, the types must be equal. If they are not, unifying
a method subset may still succeed (and possibly produce more type
arguments), but that is ok: again, subsequent instantiation and
assignment will fail if the types are indeed not identical.
2) In a non-interface type is unified with an interface, currently
unification fails. If this unification is a consequence of an
assignment (parameter passing), this is again too restrictive:
the non-interface type must only implement the interface (possibly
among other type set requirements). In any case, all methods of the
interface type must be present in the non-interface type and unify
with the corresponding interface methods. If they don't, unification
will fail either way. If they do, we may infer additional type
arguments. Again, the resulting types may still not be correct but
that will be determined by the instantiation and parameter passing
or assignment checks. If the non-interface type and the interface
type appear as component of another type, unification may now
produce additional type arguments. But that is again ok because the
respective types won't pass instantiation or assignment checks since
they are different types.
This CL introduces a new Config flag, EnableInterfaceInference, to
enable this new behavior. If not set, unification remains unchanged.
To be able to test the flag durign unification, a *Checker is passed
and stored with the unifier.
For #60353.
Fixes#41176.
Fixes#57192.
Change-Id: I6b167a9afa378d0682e9b101d9d86f5777308af7
Reviewed-on: https://go-review.googlesource.com/c/go/+/497015
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
b.ResetTimer used to also stop the timer, however it does not anymore.
These benchmarks hadn't been fixed and as a result ended up measuring
some additional things.
Also, make some for loops more conventional.
Change-Id: I76ca68456d85eec51722a80587e5b2c9f5d836a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/496996
Run-TryBot: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
CL 494915 introduced an additional fcntl(F_GETFL) syscall to determine
whether the file is in append-only mode. The existing unix.IsNonblock
call also issues an fcntl(F_GETFL) syscall. The two can be combined and
both the append-only mode and the non-blocking flags can be determined
from that syscall's result.
Change-Id: I915589ed94e079f6abaa2fd0032ef01f78698f7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/497075
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
In order to have some test coverage of concurrent use of the go/types
APIs, update the Stdlib test to type-check concurrently. In combination
with non-deterministic ordering, this should hopefully provide moderate
test coverage of concurrent use.
Also, remove the arbitrary 10ms timeout in short mode, in favor of
simply not running.
After this change, TestStdlib went from taking 16s on my laptop to 2s,
in part because of the parallelism and in part because we are no longer
type-checking twice (once for the import er, once for the test).
Fixesgolang/go#47729
Change-Id: Ie49743947ab2d5aec051c3d09ce045acf5b94ad4
Reviewed-on: https://go-review.googlesource.com/c/go/+/484540
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Currently the CPU stats are only updated once every mark termination,
but for writing robust tests, it's often useful to force this update.
Refactor the CPU stats accumulation out of gcMarkTermination and into
its own function. This is also a step toward real-time CPU stats.
While we're here, fix some incorrect documentation about dedicated GC
CPU time.
For #59749.
For #60276.
Change-Id: I8c1a9aca45fcce6ce7999702ae4e082853a69711
Reviewed-on: https://go-review.googlesource.com/c/go/+/487215
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently pidleget gets passed "now" from before the M goes into
netpoll, resulting in incorrect accounting of idle CPU time.
lastpoll is also stored with a stale "now": the mistake was added in the
same CL it was added for pidleget.
Recompute "now" after returning from netpoll.
Also, start tracking idle time on js/wasm at all.
Credit to Rhys Hiltner for the test case.
Fixes#60276.
Change-Id: I5dd677471f74c915dfcf3d01621430876c3ff307
Reviewed-on: https://go-review.googlesource.com/c/go/+/496183
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 466099 rewrote stack symbolization in race reports. Prior to this
CL, physical frames consisting entirely of wrapper logical frame would
print the wrapper, even though in other cases we try to avoid
printing wrappers. CL 466099 unintentionally changed this behavior and
now physical frames consisting entirely of wrapper frames instead fail
to symbolize and print "??()".
Fix this by taking the outermost wrapper frame if the entire logical
frame expansion consists of wrappers.
Fixes#60245.
Change-Id: I13de8857e508b757ea10d1fc7a47258d7fddbfdb
Reviewed-on: https://go-review.googlesource.com/c/go/+/497235
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
As part of the work for #57179 we moved configurable defaults
to GOROOT/go.env, so that packagers don't have to modify
source code to change those defaults. Since packagers may want
to modify GOTOOLCHAIN's default, move it to go.env too.
This CL modifies 'go env' to print GOTOOLCHAIN by default.
It also refines CL 496957 from yesterday to recognize any env
var in either go.env or the user go/env, not just the user go/env.
When I put GOTOOLCHAIN in go.env, but before I added it to
the default printing list, 'go env GOTOOLCHAIN' was printing
an empty string, and it was incredibly confusing.
For #57001.
Fixes#60361 while we're here.
Also includes a fix for a review comment on CL 497079 that I forgot to mail.
Change-Id: I7b904d9202f05af789aaa33aed93f903b515aa28
Reviewed-on: https://go-review.googlesource.com/c/go/+/497437
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
CL 493275 started using gcBits for pinner bits. This means gcBits can be
allocated while holding the mspanSpecial lock. This is safe because
these were just parallel in the partial order, but now they need an
explicit edge between them.
For #58277.
Change-Id: I37917730e12d59cf0580f198d732198413a56424
Reviewed-on: https://go-review.googlesource.com/c/go/+/497475
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reapples CL 495596, which was reverted at CL 496185. The x/tools
failure, #60263, has been resolved. The ppc64 failures, #60368, have
_not_ been resolved, but are believed to be specific to that port. This
CL will make ppc64 flaky while the issue is investigated, but give more
soak time on primary ports.
Build the compiler with PGO. As go build -pgo=auto is enabled by
default, we just need to store a profile in the compiler's
directory.
The profile is collected from building all std and cmd packages on
Linux/AMD64 machine, using profile.sh.
This improves the compiler speed. On Linux/AMD64,
name old time/op new time/op delta
Template 138ms ± 5% 136ms ± 4% -1.44% (p=0.005 n=36+39)
Unicode 147ms ± 4% 140ms ± 4% -4.99% (p=0.000 n=40+39)
GoTypes 780ms ± 3% 778ms ± 4% ~ (p=0.172 n=39+39)
Compiler 105ms ± 5% 99ms ± 7% -5.64% (p=0.000 n=40+40)
SSA 5.83s ± 6% 5.80s ± 6% ~ (p=0.556 n=40+40)
Flate 89.0ms ± 5% 87.0ms ± 6% -2.18% (p=0.000 n=40+40)
GoParser 172ms ± 4% 167ms ± 4% -2.72% (p=0.000 n=39+40)
Reflect 333ms ± 4% 333ms ± 3% ~ (p=0.426 n=40+39)
Tar 128ms ± 4% 126ms ± 4% -1.82% (p=0.000 n=39+39)
XML 173ms ± 4% 170ms ± 4% -1.39% (p=0.000 n=39+40)
[Geo mean] 253ms 248ms -2.13%
The profile is pretty transferable. Using the same profile, we
see a bigger win on Darwin/ARM64,
name old time/op new time/op delta
Template 71.0ms ± 2% 68.3ms ± 2% -3.90% (p=0.000 n=20+20)
Unicode 71.8ms ± 2% 66.8ms ± 2% -6.90% (p=0.000 n=20+20)
GoTypes 444ms ± 1% 428ms ± 1% -3.53% (p=0.000 n=19+20)
Compiler 48.9ms ± 3% 45.6ms ± 3% -6.81% (p=0.000 n=20+20)
SSA 3.25s ± 2% 3.09s ± 1% -5.03% (p=0.000 n=19+20)
Flate 44.0ms ± 2% 42.3ms ± 2% -3.72% (p=0.000 n=19+20)
GoParser 76.7ms ± 1% 73.5ms ± 1% -4.15% (p=0.000 n=18+19)
Reflect 172ms ± 1% 165ms ± 1% -4.13% (p=0.000 n=20+19)
Tar 63.1ms ± 1% 60.4ms ± 2% -4.24% (p=0.000 n=19+20)
XML 83.2ms ± 2% 79.2ms ± 2% -4.79% (p=0.000 n=20+20)
[Geo mean] 127ms 121ms -4.73%
For #60368.
Change-Id: I2cec0fc85e21c38d57ba6f0e5e90cde5d443ebd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/497455
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Updates the DecryptPKCS1v15SessionKey function comment to be less cut
and dry about its protections against Bleichenbacher attacks. In
particular note that the protocol using this method must be explicitly
designed with these mitigations in mind, and call out usages which
may cause the migiations to be useless.
Change-Id: I06fd25157f12a3afb401bb08dff4faef7fb0a9b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/469235
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
We already refuse to build code in modules are too new (CL 476279).
This is a more comprehensive check: refuse to do anything at all with
modules or workspaces that are too new.
Since the module or workspace is new, it may have semantics we don't
understand and misinterpret well before we get to the actual building of code.
For example when we switched from // +build to //go:build that changed
the decision about which files go into a package, which affects the way
the overall load phase runs and which errors it reports. Waiting until the
building of code would miss earlier changes like that one.
Leaving the test from CL 476279 alone, but it's not load-bearing anymore.
For #57001.
Change-Id: I8c39943db1d7ddbcb9b5cae68d80459fddd68151
Reviewed-on: https://go-review.googlesource.com/c/go/+/497435
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
If a hash match is "disabled" (!enabled) indicate that in the
output with DISABLED. This is helpful in ensuring that multiple
package-directed command-line flags have the intended behavior,
e.g.
```
go build -a \
-gcflags=all=-d=gossahash=vn \
-gcflags=runtime=-d=gossahash=vy \
std
```
Output looks like
[DISABLED] [bisect-match 0x11d0ee166d9d61b4]
or (w/ "v"-prefixed hashcode )
sort/slice.go:23:29 note [DISABLED] [bisect-match 0xa5252e1c1b85f2ec]
gossahash triggered sort/slice.go:23:29 note [DISABLED] 100001011111001011101100
Change-Id: I797e02b3132f9781d97bacd0dcd2e80af0035cd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497216
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
To make the new go lines work with 'go get' as minimum requirements,
this CL creates a synthetic 'go' module that has as its versions the valid
versions that can be listed on the 'go' line.
In preparation for allowing 'toolchain' changes as well, an equivalent
synthetic module is introduced for 'toolchain'.
For #57001.
Change-Id: Id0ebbd283f0f991859d516d21dffe59a834db540
Reviewed-on: https://go-review.googlesource.com/c/go/+/497080
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
go install m@v and go run m@v are the only commands
that ignore the local go.mod. As such they need to use a
different signal to find the Go version, namely the m@v go.mod.
Because there is no way to predict that Go version (no equivalent
of "go version" for interrogating the local go.mod), if we do switch
toolchains we always print about it.
For #57001.
Change-Id: I981a0b8fa61992b353589355ba72a3b9d55914e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/497079
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Clean up Go version comparison.
CL 494436 added an ad hoc version comparison for the toolchain switch.
There are also other version comparisons scattered throughout the code,
assuming that using semver.Compare with a "v" prefix gives the right answer.
As we start to allow versions like "go 1.21rc1" in the go.mod file,
those comparisons will not work properly.
A future CL will need to inject Go versions into semver for use with MVS,
so do what Bryan suggested in the review of CL 494436 and rewrite the
comparison in terms of that conversion.
For #57001.
Change-Id: Ia1d441f1bc259874c6c1b3b9349bdf9823a707d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/496735
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Since Linux 3.18, support for madvise is optional, depending on
the setting of the CONFIG_ADVISE_SYSCALLS configuration option.
The Go runtime currently assumes in several places that we
do not unmap heap memory; that needs to remain true. So, if
madvise is unsupported, we cannot fall back on munmap. AFAIK,
the only way to free the pages is to remap the memory region.
For the x86, the system call mmap() is implemented by sys_mmap2()
which calls do_mmap2() directly with the same parameters. The main
call trace for
mmap(v, n, PROT_READ|PROT_WRITE, MAP_ANON|MAP_FIXED|MAP_PRIVATE, -1, 0)
is as follows:
```
do_mmap2()
\- do_mmap_pgoff()
\- get_unmapped_area()
\- find_vma_prepare()
// If a VMA was found and it is part of the new mmaping, remove
// the old mapping as the new one will cover both.
// Unmap all the pages in the region to be unmapped.
\- do_munmap()
// Allocate a VMA from the slab allocator.
\- kmem_cache_alloc()
// Link in the new vm_area_struct.
\- vma_link()
```
So, it's safe to fall back on mmap().
See D.2 https://www.kernel.org/doc/gorman/html/understand/understand021.html
Change-Id: Ia2b4234bc0bf8a4631a9926364598854618fe270
GitHub-Last-Rev: 179f047154
GitHub-Pull-Request: golang/go#60218
Reviewed-on: https://go-review.googlesource.com/c/go/+/495081
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When associating methods with their receiver base, we need to implement
the same indirection through Cgo types as is done for selector
expressions. This fixes a bug where methods declared on aliases of Cgo
types were not associated with their receiver.
While porting to types2, align the types2 testFiles helper with the
go/types implementation. In order to avoid call-site bloat, switch to an
options pattern for configuring the Config used to type-check.
Fixesgolang/go#59944
Change-Id: Id14101f01c122b6c856ae5453bd00ec07e83f414
Reviewed-on: https://go-review.googlesource.com/c/go/+/493877
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This patch revives the testing.Coverage() function, which takes a
snapshot of the coverage counters within an executing "go test -cover"
test binary and returns a percentage approximating the percent of
statements covered so far.
Fixes#59590.
Change-Id: I541d47a42d71c8fb2edc473d86c8951fa80f4ab0
Reviewed-on: https://go-review.googlesource.com/c/go/+/495450
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Enhance the functions called by _testmain.go during "go test -cover"
test binary runs to allow for injection of extra or "auxiliary"
meta-data files when reporting coverage statistics. There are unit
tests for this functionality, but it is not yet wired up to be used by
the Go command yet, that will appear in a subsequent patch.
Change-Id: I10b79ca003fd7a875727dc1a86f23f58d6bf630c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495451
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Add a new function runtime/coverage.snapshot(), which samples the
current values of coverage counters in a running "go test -cover"
binary and returns percentage of statements executed so far. This
function is intended to be used by the function testing.Coverage().
Updates #59590.
Change-Id: I861393701c0cef47b4980aec14331168a9e64e8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/495449
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Add a flag to EmitPercent indicating to emit a single line percent
summary across all packages as opposed to a line per package. We need
to set this flag when reporting as part of a "go test -cover" run, but
false when reporting as part of a "go tool covdata percent" run.
Change-Id: Iba6a81b9ae27e3a5aaf9d0e46c0023c0e7ceae16
Reviewed-on: https://go-review.googlesource.com/c/go/+/495448
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Include some additional whitepace when emitting percentage of
statements covered per package, to make "go tool covdata percent"
output more like "go test -cover" output.
Change-Id: I450cf2bfa05b1eed747cb2f99967314419fa446c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495445
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Relax the policy on counter mode clashes in certain cases for "go tool
covdata" operations. Specifically, when generating 'percent',
'pkglist' or 'func' reports, we only care about whether a given
statement is executed, thus counter mode clashes are irrelevant; there
is no need to report clashes for these ops.
Example:
$ go build -covermode=count -o myprog.count.exe myprog
$ go build -covermode=set -o myprog.set.exe myprog
$ GOCOVERDIR=dir1 ./myprog.count.exe
...
$ GOCOVERDIR=dir2 ./myprog.set.exe
...
$ go tool covdata percent i=dir1,dir2
error: counter mode clash while reading meta-data file dir2/covmeta.1a0cd0c8ccab07d3179f0ac3dd98159a: previous file had count, new file has set
$
With this patch the command above will "do the right thing" and work
properly, and in addition merges using the "-pcombine" flag will also
operate with relaxed rules. Note that textfmt operations still require
inputs with consistent coverage modes.
Change-Id: I01e97530d9780943c99b399d03d4cfff05aafd8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495440
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Implement a real Seek() method in the slicereader helper (prior to
this it had a simplified SeekTo function), so that slicereader's will
satisfy the ReadSeeker interface (needed in a subsequent patch).
Change-Id: I832e3ec1e34d0f8c6b5edf390470f6f943c6ece0
Reviewed-on: https://go-review.googlesource.com/c/go/+/495438
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
If you are using a newer toolchain and set go env -w X=Y, then it's
a bit frustrating that you can't update the variable in an older toolchain
with go env -w X=OTHER or go env -u X, or even see it with go env X.
This CL makes all those work.
This is particularly important when playing with go env -w GOTOOLCHAIN=oldversion
because from that point on the old version is handling 'go env' commands,
and the old version doesn't know about GOTOOLCHAIN.
The most complete way to recover from that situation is to use
GOTOOLCHAIN=local go env -w ...
but we will backport this CL to Go 1.19 and Go 1.20 so that they can
recover a bit more easily.
Fixes#59870.
Change-Id: I7a0bb043109e75a0d746069015f6e7992f78287f
Reviewed-on: https://go-review.googlesource.com/c/go/+/496957
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
We don't normally keep explicit requirements for test dependencies of
packages loaded from other modules when the required version is
already the selected version in the module graph. However, in some
cases we may need to keep an explicit requirement in order to make use
of lazy module loading to disambiguate an otherwise-ambiguous import.
Note that there is no Go version guard for this change: in the cases
where the behavior of 'go mod tidy' has changed, previous versions of
Go would produce go.mod files that break successive calls to
'go mod tidy'. Given that, I suspect that any existing user in the
wild affected by this bug either already has a workaround in place
using redundant import statements (in which case the change does not
affect them) or is running 'go mod tidy -e' to force past the error
(in which case a change in behavior to a non-error should not be
surprising).
Fixes#60313.
Change-Id: Idf294f72cbe3904b871290d79e4493595a0c7bfc
Reviewed-on: https://go-review.googlesource.com/c/go/+/496635
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Many cgo integration tests do a lot of common setup in TestMain, and
that means they require a lot from the test environment to even get
off the ground. If something is missing, right now they print a "SKIP"
message to stderr and exit without running any tests.
Make these behave more like normal tests by instead setting a global
skip function if some precondition isn't satisfied, and having every
test call that. This way we run the tests and see them skip.
I would prefer something much more structured. For example, if we
replaced the global state set up by TestMain in these tests by instead
calling a function that returned that state (after setting it up on
the first call), that function could do the appropriate skips and
there would be no way to accidentally access this state without
checking the preconditions. But that's substantially more work and may
be much easier after we do further cleanup of these tests.
Change-Id: I92de569fd27596798c5e478402449cd735ec53a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/497096
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
There are many copies of overlaydir_test.go between the cgo tests
from when these couldn't share code. Now that they can, merge these
copies into a cmd/cgo/internal/cgotest package.
Change-Id: I203217f5d08e6306cb049a13718652cf7c447b80
Reviewed-on: https://go-review.googlesource.com/c/go/+/497078
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL is originally based on CL 484838 from rajbarik@uber.com.
Add a new PGO-based devirtualize pass. This pass conditionally
devirtualizes interface calls for the hottest callee. That is, it
performs a transformation like:
type Iface interface {
Foo()
}
type Concrete struct{}
func (Concrete) Foo() {}
func foo(i Iface) {
i.Foo()
}
to:
func foo(i Iface) {
if c, ok := i.(Concrete); ok {
c.Foo()
} else {
i.Foo()
}
}
The primary benefit of this transformation is enabling inlining of the
direct calls.
Today this change has no impact on the escape behavior, as the fallback
interface always forces an escape. But improving escape analysis to take
advantage of this is an area of potential work.
This CL is the bare minimum of a devirtualization implementation. There
are still numerous limitations:
* Callees not directly referenced in the current package can be missed
(even if they are in the transitive dependences).
* Callees not in the transitive dependencies of the current package are
missed.
* Only interface method calls are supported, not other indirect function
calls.
* Multiple calls to compatible interfaces on the same line cannot be
distinguished and will use the same callee target.
* Callees that only partially implement an interface (they are embedded
in another type that completes the interface) cannot be devirtualized.
* Others, mentioned in TODOs.
Fixes#59959
Change-Id: I8bedb516139695ee4069650b099d05957b7ce5ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/492436
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
A simple call to unsafe.StringData can't contain any pointers.
When looking for field references, a call to unsafe.StringData or
unsafe.SliceData can be treated as a type conversion.
In order to make unsafe.SliceData useful, recognize slice expressions
when calling C functions.
Fixes#59954
Change-Id: I08a3ace7882073284c1d46a5210582a2521b0b4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/493556
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Previously, handleState.prefix was nil if and only if the length of
the prefix was zero. Now, prefix is never nil.
Fix the nil check in the code by also checking if the length is non-zero.
Change-Id: I9f69c0029cb1c73fe6c2919c78fee7d4085bfd85
Reviewed-on: https://go-review.googlesource.com/c/go/+/495977
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
It doesn't make sense to call Logger.WithGroup with the empty string.
Make it a no-op by returning the receiver.
This relieves handlers of the burden of detecting that case themselves.
Less importantly, but for consistency, if Logger.With is called with
no args, make it a no-op by returning the receiver.
Along the way, fix obsolete mentions of "the Logger's context" in the
doc.
Change-Id: Ia6caa4f1ca70c1c4b0cab3e222b2fda48be73fef
Reviewed-on: https://go-review.googlesource.com/c/go/+/496175
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Add the slog static analysis pass to `go vet`.
Vendor in golang.org/x/tools@master to pick up the pass.
Tweak a test in slog to avoid triggering the vet check.
Change-Id: I55ceac9a4e6876c8385897784542761ea0af2481
Reviewed-on: https://go-review.googlesource.com/c/go/+/496156
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The existing implementation clears and recreates Javascript
timeouts when Go is called from js, leading to excessive
load on the js scheduler. Instead, we should remove redundant
calls to clearTimeout and refrain from creating new timeouts
if the previous event's timestamp is within 1 millisecond of
our target (the js scheduler's max precision)
Fixes#56100
Change-Id: I42bbed4c2f1fa6579c1f3aa519b6ed8fc003a20c
Reviewed-on: https://go-review.googlesource.com/c/go/+/442995
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
We will soon have PGO specialization. It doesn't make sense for the
debug flag to have inline in the name, so rename it to pgodebug.
pgoinline is now a flag that can be used to disable PGO inlining.
Devirtualization will have a similar debug flag.
For #59959.
Change-Id: I9770ff1f0d132dfa3cd417018a887a1bd5555bba
Reviewed-on: https://go-review.googlesource.com/c/go/+/494716
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Provide an exported version of implements to easily check if a type
implements an interface. This will be use for PGO devirtualization.
Even within the package, other callers can make use of this simpler API
to reduce duplication.
For #59959.
Change-Id: If4eb86f197ca32abc7634561e36498a247b5070f
Reviewed-on: https://go-review.googlesource.com/c/go/+/495915
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
The documentation for Assignop specifies that if the assignment is not
valid, the reason for the failure is returned via a reason string
without failing the build.
A few cases in Assignop1 -> implements -> ifacelookdot directly call
base.Errorf rather than plumbing through the reason string as they
should. Drop these calls. Since error messages are mostly unreachable
here (it only applies to generated code), don't maintain them and allow
them to just fallthrough to the generic "missing method" message.
This is important for PGO specialization, which opportunistically checks
if candidate interface call targets implement the interface. Many of
these will fail, which should not break the build.
For #59959.
Change-Id: I1891ca0ebebc1c1f51a0d0285035bbe8753036bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/494959
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This CL fixes two problems:
- NewContextStub initialize a context with the wrong FP. That
function should dereference the FP returned by getcallerfp, as it
returns the callers's FP instead of the caller's caller FP.
CL 494857 will rename getcallerfp to getfp to make this fact clearer.
- sehCallers skips the bottom frame when it should.
Fixes#60053
Change-Id: I7d59b0175fc95281fcc7dd565ced9293064df3a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/496140
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
The previous name was wrong due to the mistaken assumption that calling
f->g->getcallerpc and f->g->getcallersp would respectively return the
pc/sp at g. However, they are actually referring to their caller's
caller, i.e. f.
Rename getcallerfp to getfp in order to stay consistent with this
naming convention.
Also see discussion on CL 463835.
For #16638
This is a redo of CL 481617 that became necessary because CL 461738
added another call site for getcallerfp().
Change-Id: If0b536e85a6c26061b65e7b5c2859fc31385d025
Reviewed-on: https://go-review.googlesource.com/c/go/+/494857
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Before this CL, instructions such as SHA1SU0, AESD and AESE are encoded
in case 1 together with FMOV/ADD, and some error checking is missing,
for example:
SHA1SU0 V1.B16, V2.B16, V3.B16 // wrong data arrangement
SHA1SU0 V1.4S, V2.S4, V3.S4 // correct
Both will be accepted by the assembler, but the first one is totally
incorrect.
This CL fixes these potential encoding issues by moving them into
separate cases, adds some error tests, and also fixes a wrong encoding
operand for ASHA1C.
Change-Id: Ic778321a567735d48bc34a1247ee005c4ed9e11f
Reviewed-on: https://go-review.googlesource.com/c/go/+/493195
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Historically net.Conn.File.Fd has returned a descriptor in blocking mode.
That was broken by CL 495079, which changed the behavior for os.OpenFile
and os.NewFile without intending to affect net.Conn.File.Fd.
Use a hidden os entry point to preserve the historical behavior,
to ensure backward compatibility.
Change-Id: I8d14b9296070ddd52bb8940cb88c6a8b2dc28c27
Reviewed-on: https://go-review.googlesource.com/c/go/+/496080
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TestDialCancel assumes that packets sent to the private IP addresses
198.18.0.254 and 2001:2::254 will be routed to /dev/null.
Not all systems are configured that way. We already ignore one
error case in the test; ignore a couple more than have appeared
on the builders. The test is still valid as long as some builders
discard the packets as expected.
Fixes#52579Fixes#57364
Change-Id: Ibe9ed73b8b3b498623f1d18203dadf9207a0467e
Reviewed-on: https://go-review.googlesource.com/c/go/+/496037
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The documentation is yet to be written (more work in the go
command remains first). This CL implements the toolchain
selection described in
https://go.dev/design/57001-gotoolchain#the-and-lines-in-in-the-work-module
with these changes based on the issue discussion:
1. GOTOOLCHAIN=auto looks for a go1.19.1 binary in $PATH
and if found uses it instead of downloading Go 1.19.1 as a module.
2. GOTOOLCHAIN=path is like GOTOOLCHAIN=auto, with
downloading disabled.
3. GOTOOLCHAIN=auto+version and GOTOOLCHAIN=path+version
set a different minimum version of Go to use during the version
selection. The default is to use the newer of what's on the go line
or the current toolchain. If you are have Go 1.22 installed locally
and want to switch to a minimum of Go 1.25 with go.mod files
allowed to bump even further, you would set GOTOOLCHAIN=auto+go1.25.
The minimum is also important when there is no go.mod involved,
such as when you write a tiny x.go program and run "go run x.go".
That would get Go 1.25 in this example, instead of falling back to
the local Go 1.22.
Change-Id: I286625a24420424c313d1082b9949a463b2fe14a
Reviewed-on: https://go-review.googlesource.com/c/go/+/494436
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
We don't want to permit writing before the start of an OffsetWriter.
One of the goals of OffsetWriter is to restrict where data
can be written.
However, this rule can be violated by WriteAt() method of OffsetWriter
as the following code shows:
f, _ := os.Create("file.txt")
owr := io.NewOffsetWriter(f, 10)
owr.Write([]byte("world"))
owr.WriteAt([]byte("hello"), -10)
Change-Id: I6c7519fea68daefa641f25130cdd9803dc8aae22
GitHub-Last-Rev: a29d890d6f
GitHub-Pull-Request: golang/go#60222
Reviewed-on: https://go-review.googlesource.com/c/go/+/495155
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jabar Asadi <jasadi@d2iq.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This change replaces the statically sized pinnerBits with gcBits
based ones, that are copied in each GC cycle if they exist. The
pinnerBits now include a second bit per object, that indicates if a
pinner counter for multi-pins exists, in order to avoid unnecessary
specials iterations.
This is a follow-up to CL 367296.
Change-Id: I82e38cecd535e18c3b3ae54b5cc67d3aeeaafcfd
Reviewed-on: https://go-review.googlesource.com/c/go/+/493275
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The work to add the -json flag to the 'dist test' command also cleaned
how dist tests are tracked and registered. By now, a pair of (import
path, variant) strings is sufficient to uniquely identify every dist
test that exists. Some of the custom dist test names have been improved
along the way. And since the names are already changing a little anyway,
we use this opportunity to make them more uniform and predictable.
The mapping from the old dist test names to the new is as follows:
- "go_test:pkg" → "pkg" (this is the most common case)
- "go_test_bench:pkg" → "pkg:racebench"
- all other custom names are now called "pkg:variant", where variant
is a description of their test configuration and pkg is the import
path of the Go package under test
CL 495016 introduced test variants and used variant names for rewriting
the Package field in JSON events, and now that same name starts to also
be used as the dist test name.
Like previously done in CL 494496, registering a test variant involving
multiple Go packages creates a "pkg:variant" dist test name for each.
In the future we may combine their 'go test' invocation purely as an
optimization.
We can do this with the support of CL 496190 that keeps the coordinator
happy and capable of working with both new and old names.
In the end, all dist tests now have a consistent "pkg[:variant]" name.
For #37486.
For #59990.
Change-Id: I7eb02a42792a9831a2f3eeab583ff635d24269e8
Co-authored-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/496181
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This test is largely obviated by the goroot_executable and
list_goroot_symlink cmd/go script tests. It's the last user of several
special-case features in cmd/dist and runs only under a fairly
constrained set of conditions (including only running on builders, not
locally). Delete it.
Change-Id: Icc744e3f9f04813bfd0cad2ef3e88e42617ecf5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/496519
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Currently trace.lock is reentrant in a few cases. AFAICT, this was
necessary a long time ago when the trace reader would goparkunlock, and
might flush a trace buffer while parking the goroutine. Today, that's no
longer true, since that always happens without the trace.lock held.
However, traceReadCPU does still rely on this behavior, since it could
get called either with trace.lock held, or without it held. The silver
lining here is that it doesn't *need* trace.lock to be held, so the
trace reader can just drop the lock to call traceReadCPU (this is
probably also nice for letting other goroutines flush while the trace
reader is reading from the CPU log).
Stress-tested with
$ stress ./trace.test -test.run="TestTraceCPUProfile|TestTraceStress|TestTraceStressStartStop"
...
42m0s: 24520 runs so far, 0 failures
Change-Id: I2016292c17fe7384050fcc0c446f5797c4e46437
Reviewed-on: https://go-review.googlesource.com/c/go/+/496296
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change adds traceBlockReason which leaks fewer implementation
details of the tracer to the runtime. Currently, gopark is called with
an explicit trace event, but this leaks details about trace internals
throughout the runtime.
This change will make it easier to change out the trace implementation.
Change-Id: Id633e1704d2c8838c6abd1214d9695537c4ac7db
Reviewed-on: https://go-review.googlesource.com/c/go/+/494185
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
On Windows when connecting to an unavailable port, ConnectEx() will
retry for 2s, even on loopback devices.
This CL uses a call to WSAIoctl to make the ConnectEx() call fail
faster on local connections.
Fixes#23366
Change-Id: Iafeca8ea0053f01116b2504c45d88120f84d05e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/495875
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, if a test prints an incomplete line and then exits, in JSON
mode, the filter we use to rewrite Package lines will keep the last
incomplete line in an internal buffer and never print it. In theory
this should never happen anyway because the test should only write
JSON to stdout, but we try pretty hard to pass through any non-JSON,
so it seems inconsistent to swallow incomplete lines.
Fix this by adding a testJSONFilter.Flush method and calling it in the
right places. Unfortunately this is a bit tricky because the filter is
constructed pretty far from where we run the exec.Cmd, so we return
the flush function through the various layers in order to route it to
the place where we call Cmd.Run.
Updates #37486.
Change-Id: I38af67e8ad23458598a32fd428779bb0ec21ac3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/496516
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Retrying the original CL with a small modification. The original CL
did not handle the case of reading an itab out of a dictionary
correctly. When we read an itab out of a dictionary, we must treat
the type inside that itab as maybe being put in an interface.
Original CL: 486895
Revert CL: 490156
Change-Id: Id2dc1699d184cd8c63dac83986a70b60b4e6cbd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/491495
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently the trace clock is cputicks() with comments sprinkled in
different places as to which clock to use. Since the execution tracer
redesign will use a different clock, it seems like a good time to clean
that up.
Also, rename the start/end timestamps to be more readable (i.e.
startTime vs. timeStart).
Change-Id: If43533eddd0e5f68885bb75cdbadb38da42e7584
Reviewed-on: https://go-review.googlesource.com/c/go/+/494775
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The implementation of SetDeadline in Plan 9 begins by calculating
d = the offset of the requested deadline from time.Now(). If d > 0,
a timer is set to interrupt future I/O. If d < 0, the channel is
flagged to prevent future I/O and any current I/O is cancelled.
But if d = 0, nothing happens and the deadline isn't set.
The d = 0 case should be handled the same as d < 0.
Fixes#60282Fixes#52896
Change-Id: Id8167db3604db1c129d99376fa78a3da75417d20
Reviewed-on: https://go-review.googlesource.com/c/go/+/496137
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Currently STW events are only emitted for GC STWs. There's little reason
why the trace can't contain events for every STW: they're rare so don't
take up much space in the trace, yet being able to see when the world
was stopped is often critical to debugging certain latency issues,
especially when they stem from user-level APIs.
This change adds new "kinds" to the EvGCSTWStart event, renames the
GCSTW events to just "STW," and lets the parser deal with unknown STW
kinds for future backwards compatibility.
But, this change must break trace compatibility, so it bumps the trace
version to Go 1.21.
This change also includes a small cleanup in the trace command, which
previously checked for STW events when deciding whether user tasks
overlapped with a GC. Looking at the source, I don't see a way for STW
events to ever enter the stream that that code looks at, so that
condition has been deleted.
Change-Id: I9a5dc144092c53e92eb6950e9a5504a790ac00cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/494495
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
The new Pinner API's implementation imposes some partial-orders that are
safe but previously did not exist between a mspanSpecial, mheapSpecial,
and mheap. Fix that up in the lock ranking.
For #46787.
Change-Id: I51cc8f7f069240caeb44d749bed43515634f4814
Reviewed-on: https://go-review.googlesource.com/c/go/+/496193
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Some C APIs require the use or structures that contain pointers to
buffers (iovec, io_uring, ...). The pointer passing rules would
require that these buffers are allocated in C memory and to process
this data with Go libraries it would need to be copied.
In order to provide a zero-copy way to use these C APIs, this CL
implements a Pinner API that allows to pin Go objects, which
guarantees that the garbage collector does not move these objects
while pinned. This allows to relax the pointer passing rules so that
pinned pointers can be stored in C allocated memory or can be
contained in Go memory that is passed to C functions.
The Pin() method accepts pointers to objects of any type and
unsafe.Pointer. Slices and arrays can be pinned by calling Pin()
with the pointer to the first element. Pinning of maps is not
supported.
If the GC collects unreachable Pinner holding pinned objects it
panics. If Pin() is called with the other non-pointer types it
panics as well.
Performance considerations: This change has no impact on execution
time on existing code, because checks are only done in code paths,
that would panic otherwise. The memory footprint on existing code is
one pointer per memory span.
Fixes: #46787
Signed-off-by: Sven Anderson <sven@anderson.de>
Change-Id: I110031fe789b92277ae45a9455624687bd1c54f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/367296
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Currently if GOGC=off and GOMEMLIMIT is set, then the synchronous
scavenger is likely to work fairly often to maintain the limit, since
the heap goal goes right up to the edge of the memory limit (minus a
fixed 1 MiB of headroom).
If the application's allocation rate is high, and page-level
fragmentation is high, then most allocations will scavenge.
This change mitigates this problem by adding a proportional component
to constant headroom added to the memory-limit-based heap goal. This
means the runtime will have much more headroom before fragmentation
forces memory to be eagerly scavenged.
The proportional headroom in this case is 3%, or ~30 MiB for a 1 GiB
heap. This technically will increase GC frequency in the GOGC=off case
by a tiny amount, but will likely have a positive impact on both
allocation throughput and latency that outweighs this difference.
I wrote a small program to reproduce this issue and confirmed that the
issue is resolved by this patch:
https://github.com/golang/go/issues/57069#issuecomment-1551746565
This value of 3% is chosen as it seems to be a inflection point in this
particular small program. 2% still resulted in quite a bit of eager
scavenging work. I confirmed this results in a GC frequency increase of
about 3%.
This choice is still somewhat arbitrary because the program is
arbitrary, so perhaps worth revisiting in the future. Still, it should
help a good number of programs.
Fixes#57069.
Change-Id: Icb9829db0dfefb4fe42a0cabc5aa8d35970dd7d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/460375
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
I implemented this in order to debug connection failures on a
new-to-me VM development environment that uses Cloud NAT. It doesn't
directly fix the bug, but perhaps folks will find it useful to
diagnose port-exhaustion-related flakiness in other environments.
For #52545.
Change-Id: Icd3f13dcf62e718560c4f4a965a4df7c1bd785ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/473277
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
CL 495918 enabled testcarchive much more widely and added many dynamic
test skips. CL 495855 added TestDeepStack before these dynamic skips
were in. Unfortunately, the two CLs don't logically commute, so when
CL 495918 landed, it broke at least nocgo builders and platforms that
don't support c-archive builds. Fix this by adding the necessary skips
to TestDeepStack.
Change-Id: I3d352f731fe67a01c7b96871fde772db8eb21b5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/496376
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
The test driver for testso and testsovar are literally identical, and
only the testdata code is different between the two test packages.
Merge them into a single test package with two tests that share a
driver.
Change-Id: I3f107a6aba345c0dd58606c10e3ac8eee33b33c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/496315
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Currently, this test only enabled on non-Darwin UNIX platforms because
it uses the non-standard _thread attribute for thread-local storage.
C11 introduced a standard way to declare something thread-local, so
this CL takes advantage of that to generalize the test to Darwin and
Windows.
Change-Id: Iba31b6216721df6eb8e978d7487cd3a787cae588
Reviewed-on: https://go-review.googlesource.com/c/go/+/496295
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Currently, dist registers cmd/cgo/internal{test,testtls,testnocgo}
specially, so they're opted out of "go test std cmd". It has to
register these test packages to run in various non-default build
configurations, but at this point they can also run with the default
build configuration (and for test and testtls, we intentionally want
to test them in the default configuration; this is pointless but
harmless for testnocgo). Hence, this CL drops the special registration
of their default build configurations from registerCgoTests and lets
them be registered as part of registerStdTests.
Change-Id: Id283f3cdcdb202955a854648c0ed1e3c4aa554d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/496179
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This test is actually intended to test that we can build in -static
mode even without any cgo. That means it's quite harmless to run in
the default build configuration (in addition to running with various
other build configurations).
Change-Id: Ic6cb5c0eaab83f9bd5718aae57d0fdc69afcb8b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/496178
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is the default value of this flag, so passing it clutters up
debugging output. This also makes it clearer which tests are running
with a default configuration.
Change-Id: If793934829c79f087c7a6e3fa8f64dc33959c213
Reviewed-on: https://go-review.googlesource.com/c/go/+/496176
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL moves many cgo test conditions out of dist and into the tests
themselves, now that they can use the testenv.Must* helpers.
This refines a lot of the conditions, which happens to have the effect
of enabling many tests on Android and iOS that are disabled by
too-coarse GOOS checks in dist today.
Fixes#15919.
Change-Id: I2947526b08928d2f7f89f107b5b2403b32092ed8
Reviewed-on: https://go-review.googlesource.com/c/go/+/495918
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
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>
Currently, we have several tests disabled if GO_GCFLAGS is non-empty.
Long ago, this was critical because many of these tests use "go
install" with no -gcflags and would thus overwrite std packages in
GOROOT built with -gcflags=$GO_GCFLAGS. Now these packages all live in
the build cache, so this is no longer a concern.
The other reason for this (the reason given in the code comment), is
that these tests will rebuild significant portions of std without
flags. While this is still theoretically true, there are many tests
that run "go build" with no -gcflags, so these tests don't contribute
much overall.
Empirically, on my linux/amd64 host, running these tests at all grows
the Go build cache by 14%, from 1.899 GB to 2.165 GB. When building
with GO_GCFLAGS="-N -l" (the only use case on the builders), enabling
them grows the Go build cache by 18%, from 1.424 GB to 1.684 GB. This
is only a 4 percentage point difference, and still results in a build
cache that's smaller than the default build
Given all this, there's little reason to carry the complexity of
disabling these tests when GO_GCFLAGS != "". Removing this condition
is a step toward running these as regular cmd tests.
Change-Id: I2c41be721927c40a742e01476cd9a0f7650d38e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/495917
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
- Build the fake go1.999testpath binary from Go source instead of
special-casing a fake command on Windows.
- Skip the part of the test that uses shell scripts served from the
test GOPROXY if /bin/sh is not present.
This makes the test more expensive, but also more realistic: notably,
it does not require test hooks to determine whether to run a real or
fake binary.
Change-Id: If14fec52186631d7833eba653c91ec5198dede58
Reviewed-on: https://go-review.googlesource.com/c/go/+/486400
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Check all arguments for validity once, in the beginning.
Conservatively replace arg(x, i) calls with *x = args[i].
Use y (2nd arguments) directly, w/o copying.
Remove unnecessary copies and slice creations in append.
Change-Id: I1e2891cba9658f5b3cdf897e81db2f690a99b16b
Reviewed-on: https://go-review.googlesource.com/c/go/+/495515
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This test was introduced in CL 18882, but only recently enabled as of
CL 493603. It's intended to check that we don't move executing C code
between threads when it re-enters Go, but it has always contained a
flake. Go *can* preempt between the Go call to gettid and the C call
to gettid and move the goroutine to another thread because there's no
C code on the stack during the Go call to gettid. This will cause the
test to fail.
Fix this by making both gettid calls in C, with a re-entry to Go
between them.
Fixes#60265
Change-Id: I546621a541ce52b996d68b17d3bed709d2b5b1f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/496182
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
The asynchronous call to processFile is synchronized by the call to
GetExitCode. We can't safely access errBuf until then, because
processFile may still be writing to it.
This is diagnosed by 'go test -race cmd/gofmt', but only the
darwin-amd64-race builder caught it because the other "-race" builders
apparently all run as root (see #10719).
Updates #60225.
Change-Id: Ie66bb4e47429ece81043d6425f26953b7bb26002
Reviewed-on: https://go-review.googlesource.com/c/go/+/496155
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
ARM64 doesn't have MOVNP/MOVNPW and STLP/STLPW instructions, which are
currently useless instructions as well. This CL deletes them. At the
same time this CL sorts the opcodes by name, which looks cleaner.
Change-Id: I25cfb636b23356ba0a50cba527a8c85b3f7e2ee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/495695
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This enables the implementation for proposal #58671, which is
a likely accept. By enabling it early we get a bit extra soak
time for this feature. The change can be reverted trivially, if
need be.
For #58671.
Change-Id: Id6c27515e45ff79f4f1d2fc1706f3f672ccdd1ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/495955
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reapplies CL 485500, with a fix drafted in CL 492987 incorporated.
CL 485500 is reverted due to #60004 and #60007. #60004 is fixed in
CL 492743. #60007 is fixed in CL 492987 (incorporated in this CL).
[Original CL 485500 description]
This reapplies CL 481061, with the followup fixes in CL 482975, CL 485315, and
CL 485316 incorporated.
CL 481061, by doujiang24 <doujiang24@gmail.com>, speed up C to Go
calls by binding the M to the C thread. See below for its
description.
CL 482975 is a followup fix to a C declaration in testprogcgo.
CL 485315 is a followup fix for x_cgo_getstackbound on Illumos.
CL 485316 is a followup cleanup for ppc64 assembly.
CL 479915 passed the G to _cgo_getstackbound for direct updates to
gp.stack.lo. A G can be reused on a new thread after the previous thread
exited. This could trigger the C TSAN race detector because it couldn't
see the synchronization in Go (lockextra) preventing the same G from
being used on multiple threads at the same time.
We work around this by passing the address of a stack variable to
_cgo_getstackbound rather than the G. The stack is generally unique per
thread, so TSAN won't see the same address from multiple threads. Even
if stacks are reused across threads by pthread, C TSAN should see the
synchonization in the stack allocator.
A regression test is added to misc/cgo/testsanitizer.
[Original CL 481061 description]
This reapplies CL 392854, with the followup fixes in CL 479255,
CL 479915, and CL 481057 incorporated.
CL 392854, by doujiang24 <doujiang24@gmail.com>, speed up C to Go
calls by binding the M to the C thread. See below for its
description.
CL 479255 is a followup fix for a small bug in ARM assembly code.
CL 479915 is another followup fix to address C to Go calls after
the C code uses some stack, but that CL is also buggy.
CL 481057, by Michael Knyszek, is a followup fix for a memory leak
bug of CL 479915.
[Original CL 392854 description]
In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls.
So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call.
Instead, we only dropm while the C thread exits, so the extra M won't leak.
When invoking a Go function from C:
Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor.
And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits.
When returning back to C:
Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C.
This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows.
This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread.
For the newly added BenchmarkCGoInCThread, some benchmark results:
1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
[CL 479915 description]
Currently, when C calls into Go the first time, we grab an M
using needm, which sets m.g0's stack bounds using the SP. We don't
know how big the stack is, so we simply assume 32K. Previously,
when the Go function returns to C, we drop the M, and the next
time C calls into Go, we put a new stack bound on the g0 based on
the current SP. After CL 392854, we don't drop the M, and the next
time C calls into Go, we reuse the same g0, without recomputing
the stack bounds. If the C code uses quite a bit of stack space
before calling into Go, the SP may be well below the 32K stack
bound we assumed, so the runtime thinks the g0 stack overflows.
This CL makes needm get a more accurate stack bound from
pthread. (In some platforms this may still be a guess as we don't
know exactly where we are in the C stack), but it is probably
better than simply assuming 32K.
[CL 492987 description]
On the first call into Go from a C thread, currently we set the g0
stack's high bound imprecisely based on the SP. With CL 485500, we
keep the M and don't recompute the stack bounds when it calls into
Go again. If the first call is made when the C thread uses some
deep stack, but a subsequent call is made with a shallower stack,
the SP may be above g0.stack.hi.
This is usually okay as we don't check usually stack.hi. One place
where we do check for stack.hi is in the signal handler, in
adjustSignalStack. In particular, C TSAN delivers signals on the
g0 stack (instead of the usual signal stack). If the SP is above
g0.stack.hi, we don't see it is on the g0 stack, and throws.
This CL makes it get an accurate stack upper bound with the
pthread API (on the platforms where it is available).
Also add some debug print for the "handler not on signal stack"
throw.
Fixes#51676.
Fixes#59294.
Fixes#59678.
Fixes#60007.
Change-Id: Ie51c8e81ade34ec81d69fd7bce1fe0039a470776
Reviewed-on: https://go-review.googlesource.com/c/go/+/495855
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
When gofmt needs to rewrite a file, it first copies it into a backup.
If the rewrite fails, it used to rename the backup to the original.
However, if for some reason the file is owned by some other user,
and if the rewrite fails because gofmt doesn't have permission to
write to the file, then renaming the backup file will change
the file owner. This CL changes gofmt so that if it fails to rewrite
a file, it tries to write the original contents. If writing the original
content fails, it reports the problem to the user referring to the
backup file, rather than trying a rename.
Also create the backup file with the correct permissions,
to avoid a tiny gap when some process might get write access to the
file contents that it shouldn't have. (This tiny gap only applies to
files that are not formatted correctly, and have read-only permission,
and are in a directory with write permission.)
Fixes#60225
Change-Id: Ic16dd0c85cf416d6b2345e0650d5e64413360847
Reviewed-on: https://go-review.googlesource.com/c/go/+/495316
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
I think there is a theoretical possibility of a mistake before this CL.
pollCache.free would increment fdseq, but would not update atomicInfo.
The epoll code could compare to fdseq before the increment, but suspend
before calling setEventErr. The pollCache could get reallocated,
and pollOpen could clear eventErr. Then the setEventErr could continue
and set it again. Then pollOpen could call publishInfo.
Avoid this rather remote possibility by calling publishInfo after
incrementing fdseq. That ensures that delayed setEventErr will not
modify the eventErr flag.
Fixes#60133
Change-Id: I69e336535312544690821c9fd53f3023ff15b80c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495297
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>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This enables JSON output for all tests run by dist.
Most the complexity here is that, in order to disambiguate JSON
records from different package variants, we have to rewrite the JSON
stream on the fly to include variant information. We do this by
rewriting the Package field to be pkg:variant so existing CI systems
will naturally pick up the disambiguated test name.
Fixes#37486.
Change-Id: I0094e5e27b3a02ffc108534b8258c699ed8c3b87
Reviewed-on: https://go-review.googlesource.com/c/go/+/494958
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Currently, all uses of rtPreFunc are to print a message and skip a
test. When we move to JSON, the logic to just "print a message" is
going to be more complicated, so refactor this so the function returns
the skip message and we print it in just one place. We also rename the
option to rtSkipFunc to better represent what we use it for.
For #37486.
Change-Id: Ibd537064fa646a956a1c0f85a5d8c6febd098dde
Reviewed-on: https://go-review.googlesource.com/c/go/+/495856
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Many of the commands dist test executes are "background" commands run
by a work queue system. The work queue allows it to run commands in
parallel, but still serialize their output. Currently, the work queue
system assumes that exec.Cmd.Stdout and Stderr will be nil and that it
can take complete control over them.
We're about to inject output filters on many of these commands, so we
need a way to interpose on Stdout and Stderr. This CL rearranges
responsibilities in the work queue system to make that possible. Now,
the thing enqueuing the work item is responsible to constructing the
Cmd to write its output to work.out. There's only one place that
constructs work objects (there used to be many more), so that's
relatively easy, and sets us up to add filters.
For #37486.
Change-Id: I55ab71ddd456a12fdbf676bb49f698fc08a5689b
Reviewed-on: https://go-review.googlesource.com/c/go/+/494957
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
There are no uses of addCmd, so delete it. The only use of bgDirCmd is
dirCmd, so inline it. Now the only function that interacts with the
work queue is registerTest and dist's "background commands" are used
exclusively in goTest.bgCommand and registerTest (which calls
goTest.bgCommand).
For #37486.
Change-Id: Iebbb24cf9dbee45f3975fe9504d858493e1cd947
Reviewed-on: https://go-review.googlesource.com/c/go/+/494956
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Pull in CL 492990. This teaches 'go mod tidy' and other go subcommands
that write go.mod files to use semantic sort for exclude blocks, gated
on said files declaring Go version 1.21 or higher.
go get golang.org/x/mod@e7bea8f1d64f # includes CL 492990
go mod tidy
go mod vendor
Fixes#60028.
Change-Id: Ia9342dcc23cd68de068a70657b59c25f69afa381
Reviewed-on: https://go-review.googlesource.com/c/go/+/494578
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
This change wraps the errors from the CharsetReader function so the caller can distinguish different error conditions.
Context: I have an XML file with an unknown encoding which I like to handle separately. I like to use the CharsetReader for this but the error type has not been forwarded.
Change-Id: I6739a0dee04ec376cd20536be2806ce7f50c5213
GitHub-Last-Rev: ada9dd510f
GitHub-Pull-Request: golang/go#60199
Reviewed-on: https://go-review.googlesource.com/c/go/+/494897
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
sysBlockTraced is a subtle and confusing flag.
Currently, it's only used in one place: a condition around whether to
traceGoSysExit when a goroutine is about to start running. That condition
looks like "gp.syscallsp != 0 && gp.trace.sysBlockTraced".
In every case but one, "gp.syscallsp != 0" is equivalent to
"gp.trace.sysBlockTraced."
That one case is where a goroutine is running without a P and racing
with trace start (world is stopped). It switches itself back to
_Grunnable from _Gsyscall before the trace start goroutine notices, such
that the trace start goroutine fails to emit a EvGoInSyscall event for
it (EvGoInSyscall or EvGoSysBlock must precede any EvGoSysExit event).
sysBlockTraced is set unconditionally on every syscall entry and the
trace start goroutine clears it if there was no EvGoInSyscall event
emitted (i.e. did not observe _Gsyscall on the goroutine). That way when
the goroutine-without-a-P wakes up and gets scheduled, it only emits
EvGoSysExit if the flag is set, i.e. trace start didn't _clear_ the
flag.
What makes this confusing is the fact that the flag is set
unconditionally and the code relies on it being *cleared*. Really, all
it's trying to communicate is whether the tracer is aware of a
goroutine's syscall at the point where a goroutine that lost its P
during a syscall is trying to run again.
Therefore, we can replace this flag with a less subtle one:
tracedSyscallEnter. It is set when GoSysCall is traced, indicating on
the goroutine that the tracer is aware of the syscall. Later, if
traceGoSysExit is called, the tracer knows its safe to emit an event
because the tracer is aware of the syscall.
This flag is then also set at trace start, when it emits EvGoInSyscall,
which again, lets the goroutine know the tracer is aware of its syscall.
The flag is cleared by GoSysExit to indicate that the tracer is no
longer aware of any syscalls on the goroutine. It's also cleared by
trace start. This is necessary because a syscall may have been started
while a trace was stopping. If the GoSysExit isn't emitted (because it
races with the trace end STW) then the flag will be left set at the
start of the next trace period, which will result in an erroneous
GoSysExit. Instead, the flag is cleared in the same way sysBlockTraced
is today: if the tracer doesn't notice the goroutine is in a syscall, it
makes that explicit to the goroutine.
A more direct flag to use here would be one that explicitly indicates
whether EvGoInSyscall or EvGoSysBlock specifically were already emitted
for a goroutine. The reason why we don't just do this is because setting
the flag when EvGoSysBlock is emitted would be racy: EvGoSysBlock is
emitted by whatever thread is stealing the P out from under the
syscalling goroutine, so it would need to synchronize with the goroutine
its emitting the event for.
The end result of all this is that the new flag can be managed entirely
within trace.go, hiding another implementation detail about the tracer.
Tested with `stress ./trace.test -test.run="TestTraceStressStartStop"`
which was occasionally failing before the CL in which sysBlockTraced was
added (CL 9132). I also confirmed also that this test is still sensitive
to `EvGoSysExit` by removing the one use of sysBlockTraced. The result
is about a 5% error rate. If there is something very subtly wrong about
how this CL emits `EvGoSysExit`, I would expect to see it as a test
failure. Instead:
53m55s: 200434 runs so far, 0 failures
Change-Id: If1d24ee6b6926eec7e90cdb66039a5abac819d9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/494715
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
In race mode (or other instrumentation mode), if the caller is in
a regular package and the callee is in a norace (or noinstrument)
package, don't inline. Otherwise, when the caller is instumented
it will also affect the inlined callee.
An example is sync.(*Mutex).Unlock, which is typically not inlined
but with PGO it can be inlined into a regular function, which is
then get instrumented. But the rest of the sync package, in
particular, the Lock function is not instrumented, causing the
race detector to signal false race.
Change-Id: Ia78bb602c6da63a34ec2909b9a82646bf20873f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/495595
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
More tightening up of the tracer's interface.
This increases the size of each G very slightly, which isn't great, but
we stay within the same size class, so actually memory use will be
unchanged.
Change-Id: I7d1f5798edcf437c212beb1e1a2619eab833aafb
Reviewed-on: https://go-review.googlesource.com/c/go/+/494188
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Prior to this change, 'go get' pulled in every version of each module
whose path is explicitly listed in the go.mod file. When graph pruning
is enabled (that is, when the main module is at 'go 1.17' or higher),
that pulled in transitive dependencies of older-than-selected versions
of dependencies, which are normally pruned out by other 'go' commands
(including 'go mod tidy' and 'go mod graph').
To make matters worse, different parts of `go get` were making
different assumptions about which kinds of conflicts would be
reported: the modget package assumed that any conflict is necessarily
due to some explicit constraint, but 'go get' was imposing an
additional constraint that modules could not be incidentally upgraded
in the course of a downgrade. When that additional constraint failed,
the modload package reported the failure as though it were a real
(caller-supplied) constraint, confusing the caller (which couldn't
identify any specific package or argument that caused the failure).
This change fixes both of those problems by replacing the
modload.EditRequirements algorithm with a different one.
The new algorithm is, roughly, as follows.
1. Propose a list of “root requirements” to be written to the updated
go.mod file.
2. Load the module graph from those requirements mostly as usual, but
if any root is upgraded due to transitive dependencies, retain the
original roots and the paths leading from those roots to the
upgrades. (This forms an “extended graph”, in which we can trace a
path from to each version that appears in the graph starting at one
or more of the original roots.)
3. Identify which roots caused any module path to be upgraded above
its passed-in version constraint. For each such root, either report
an unresolvable conflict (if the root itself is constrained to a
specific version) or identify an updated version to propose: either
a downgrade to the next-highest version, or an upgrade to the
actually-selected version of the root (if that version is allowed).
To avoid looping forever or devolving into an NP-complete search,
we never propose a version that was already rejected previously,
regardless of what other roots were present alongside it at the
time.
4. If the version of any root was changed, repeat from (1).
This algorithm is guaranteed to terminate, because there are finitely
many root versions and we permanently reject at least one each time we
downgrade its path to a lower version.
In addition, this change implements support for the '-v' flag to log
more information about version changes at each iteration.
Fixes#56494.
Fixes#55955.
Change-Id: Iebc17dd7586594d5732e228043c3c4c6da230f44
Reviewed-on: https://go-review.googlesource.com/c/go/+/471595
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
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>
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>
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 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 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>
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>
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>
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>
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>
The provided description for `NewReader` says that the underlying string is read-only. but the following example shows that this is not the case.
<br />
rd := strings.NewReader("this is a text")
rd.Reset("new text") <--- underlying string gets updated here
Change-Id: I95c7099c2e63670c84307d4317b702bf13a4025a
GitHub-Last-Rev: a16a60b0f1
GitHub-Pull-Request: golang/go#60074
Reviewed-on: https://go-review.googlesource.com/c/go/+/493817
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The effect and motivation is for the test to be selected when doing
'go test cmd' and not when doing 'go test std' since it's primarily
about testing the Go compiler and linker. Other than that, it's run
by all.bash and 'go test std cmd' as before.
For #56844.
Fixes#60059.
Change-Id: I2d499af013f9d9b8761fdf4573f8d27d80c1fccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/493876
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
In the case of a wrong method, we were not ensuring that it was
type-checked before passing it to funcString.
Formatting the missing method error message requires a fully set-up
signature.
Fixes#59848
Change-Id: I1467e036afbbbdd00899bfd627a945500dc709c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/494615
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Russ added test/bench/go1 in CL 5484071 to have a stable suite of
programs to use as benchmarks. For the compiler and runtime we had
back then, those were reasonable benchmarks, but the compiler and
runtime are now far more sophisticated and these benchmarks no longer
have good coverage. We also now have better benchmark suites
maintained outside the repo (e.g., golang.org/x/benchmarks). Keeping
test/bench/go1 at this point is actively misleading.
Indirectly related to #37486, as this also removes the last package
dist test runs outside of src/.
Change-Id: I2867ef303fe48a02acce58ace4ee682add8acdbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/494193
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Host tests are used for emulated builders that use cross-compilation.
Today, this is the android-{386,amd64}-emu builders and all wasm
builders. These builders run all.bash on a linux/amd64 host to build
all packages and most tests for the emulated guest, and then run the
resulting test binaries inside the emulated guest. A small number of
test packages are “host tests”: these run on the host rather than the
guest because they invoke the Go toolchain themselves (which only
lives on the host) and run the resulting binaries in the guest.
However, this host test mechanism is barely used today, despite being
quite complex. This complexity is also causing significant friction to
implementing structured all.bash output.
As of this CL, the whole host test mechanism runs a total of 10 test
cases on a total of two builders (android-{386,amd64}-emu). There are
clearly several tests that are incorrectly being skipped, so we could
expand it to cover more test cases, but it would still apply to only
two builders. Furthermore, the two other Android builders
(android-{arm,arm64}-corellium) build the Go toolchain directly inside
Android and also have access to a C toolchain, so they are able to get
significantly better test coverage without the use of host tests. This
suggests that the android-*-emu builders could do the same. All of
these tests are cgo-related, so they don't run on the wasm hosts
anyway.
Given the incredibly low value of host tests today, they are not worth
their implementation complexity and the friction they cause. Hence,
this CL drops support for host tests. (This was also the last use of
rtSequential, so we drop support for sequential tests, too.)
Fixes#59999.
Change-Id: I3eaca853a8907abc8247709f15a0d19a872dd22d
Reviewed-on: https://go-review.googlesource.com/c/go/+/492986
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
On cross-compiling builder machines, we run internal/testdir on the
host, where it can access the Go toolchain to build binaries for the
guest and run them through an exec wrapper. Currently this uses dist
test's existing host test mechanism, which is quite complicated and we
are planning to eliminate (#59999).
Switch internal/testdir to use a more cooperative mechanism. With this
CL, dist still understands that it has to build and run the test using
the host GOOS/GOARCH, but rather than doing complicated manipulation
of environment variables itself, it passes the guest GOOS/GOARCH to
the test, which can easily inject it into its environment. This means
dist test can use "go test" directly, rather than having to split up
the build and run steps.
For #37486.
Change-Id: I556938c0b641960bb778b88b13f2b26256edc7c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/492985
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The test directory driver currently sets the GOOS/GOARCH environment
variables if they aren't set. This appears to be in service of a
single test, test/env.go, which was introduced in September 2008 along
with os.Getenv. It's not entirely clear what that test is even trying
to check, since runtime.GOOS isn't necessarily the same as $GOOS. We
keep the test around because golang.org/x/tools/go/ssa/interp uses it
as a test case, but we simplify the test and eliminate the need for
the driver to set GOOS/GOARCH.
Change-Id: I5acc0093b557c95d1f0a526d031210256a68222d
Reviewed-on: https://go-review.googlesource.com/c/go/+/493601
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This moves the misc/swig test to cmd/cgo/internal.
This lets these tests access facilities in internal/testenv. It's also
now just a normal test that can run as part of the cmd tests.
For #37486.
Change-Id: Ibe5026219999d175aa0a310b9886bef3f6f9ed17
Reviewed-on: https://go-review.googlesource.com/c/go/+/492722
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Currently, the misc/swig tests directly use Swig and C++ and will fail
to build if either Swig or a C++ compiler are not present. Typically,
we hide this fact from users because dist test itself checks for Swig
and a C++ compiler before even attempting to run this test, though
users will see this is they try to go test ./... from misc.
However, we're about to move the misc/swig tests into the cmd module,
where they will be much more visible and much more likely to run
unintentionally. To prevent build errors, this CL restructures these
tests into a single pure Go test plus two test packages hidden in
testdata. This is relatively easy to do for this test because there
are only four test cases total. The pure Go test can check for the
necessary build tools before trying to build and run the tests in
testdata. This also gives us the opportunity to move the LTO variant
of these tests out of dist and into the test itself, simplifying dist.
For #37486.
Change-Id: Ibda089b4069e36866cb31867a7006c790be2d8b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/493599
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Currently, if cmd/go builds a swig file with the -n (dry run) flag, it
will print the swig command invocation without executing it, but then
attempt to actually rename one of swig's output files, which will
fail. Make this rename conditional on -n. While we're here, we fix the
missing logging of the rename command with -x, too.
Change-Id: I1f6e6efc53dfe4ac5a42d26096679b97bc322827
Reviewed-on: https://go-review.googlesource.com/c/go/+/493255
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We're about to move this package to cmd/cgo/internal, where it will
get caught up in the "CGO_ENABLED=0 go install cmd" done by make.bash.
Currently, building this package with CGO_ENABLED=0 fails because it
contains several source files that don't themselves import "C", but do
import a subdirectory where that package imports "C" and thus has no
exported API.
Fix the CGO_ENABLED=0 build of this package by adding the necessary
cgo build tags. Not all source files need it, but this CL makes
"CGO_ENABLED=0 go test -c" work in this package.
For #37486.
Change-Id: Id137cdfbdd950eea802413536d990ab642ebcd7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/493215
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Vet's cgocall check fails on misc/cgo/test with "possibly passing Go
type with embedded pointer to C". This error is confusing, but the
cgocall check is looking for passing pointers to Go slices to C, which
is exactly what this test is doing. Normally we don't notice this
because vet doesn't run on misc, but we're about to move this test to
cmd/cgo/internal, where vet will start failing.
I'm not sure why we're passing a pointer to a slice here. It's
important that we call a C function with an unsafe.Pointer to memory
containing a pointer to test #25941 and that the result is this call
is then passed to another C function for #28540. This CL maintains
these two properties without the use of a slice.
For #37486.
Change-Id: I672a3c35931a59f99363050498d6f0c80fb6cd98
Reviewed-on: https://go-review.googlesource.com/c/go/+/493137
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This moves most misc/cgo tests to cmd/cgo/internal. This is mostly a
trivial rename and updating dist/test.go for the new paths, plus
excluding these packages from regular dist test registration. A few
tests were sensitive to what path they ran in, so we update those.
This will let these tests access facilities in internal/testenv.
For #37486.
Change-Id: I3ed417c7c22d9b667f2767c0cb1f59118fcd4af6
Reviewed-on: https://go-review.googlesource.com/c/go/+/492720
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The test had a 5 second timeout. Running the test on a Darwin system
sometimes took less than 5 seconds but often took up to 8 seconds.
We don't need a timeout anyhow. Instead, use testenv.Command to
run the program, which uses the test timeout.
Fixes#59807
Change-Id: Ibf3eda9702731bf98601782f4abd11c3caa0bf40
Reviewed-on: https://go-review.googlesource.com/c/go/+/494456
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This was also the cause of my issues in CL 455275
Before:
root@arch:~/aa# $(time sleep 5 && mv /etc/hosts /tmp/hosts) &
[1] 2214
root@arch:~/aa# go run main.go
[232.223.232.123] <nil>
[232.223.232.123] <nil>
[232.223.232.123] <nil>
[232.223.232.123] <nil>
[232.223.232.123] <nil>
[232.223.232.123] <nil>
(....)
After:
root@arch:~/aa# $(time sleep 5 && mv /etc/hosts /tmp/hosts) &
[1] 2284
root@arch:~/aa# go run main.go
[232.223.232.123] <nil>
[232.223.232.123] <nil>
[232.223.232.123] <nil>
[232.223.232.123] <nil>
[232.223.232.123] <nil>
[] lookup sth on 127.0.0.53:53: server misbehaving
[] lookup sth on 127.0.0.53:53: server misbehaving
Change-Id: I3090fd8f3105db8c2d7c3bf5afe7b18ebca61cda
GitHub-Last-Rev: cb0dac6448
GitHub-Pull-Request: golang/go#59963
Reviewed-on: https://go-review.googlesource.com/c/go/+/492555
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Mateusz Poliwczak <mpoliwczak34@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
graph.go is a simplified fork of github.com/google/pprof/internal/graph,
which is used as an intermediate data structure to construct the final
graph exported by package pgo (IRGraph).
Exporting both is a bit confusing as the former is unused outside of the
package. Since the naming is also similar, move graph.go to its own
package entirely.
Change-Id: I2bccb3ddb6c3f63afb869ea9cf34d2a261cad058
Reviewed-on: https://go-review.googlesource.com/c/go/+/494437
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Currently, we check the total size of all data+DWARF sections
doesn't exceed 2 GB, which doesn't make sense. We should check
data and DWARF separately. And for DWARF, check each section
separately, as we use section offset for references.
Change-Id: I723cde6a2f46e55cc5cb0621926722272581eb48
Reviewed-on: https://go-review.googlesource.com/c/go/+/494439
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
This change introduces the trivial traceEnabled function to help tighten
up the execution tracer's API in preparation for the execution trace
redesign GOEXPERIMENT.
A follow-up change will refactor the runtime to use it.
Change-Id: I19c8728e30aefe543b4a826d95446affa14897e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/494180
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently there is a small bug in the LookupAddr for unix systems
that causes the use of go resolver instead of the cgo one.
Example for nss myhostname:
func main() {
fmt.Println(net.LookupAddr(os.Args[1]))
}
root@arch:~# cat /etc/nsswitch.conf | grep host
hosts: myhostname dns
root@arch:~# GODEBUG=netdns=+3 go run main.go 192.168.1.200
go package net: confVal.netCgo = false netGo = false
go package net: dynamic selection of DNS resolver
go package net: hostLookupOrder() = dns
[] lookup 200.1.168.192.in-addr.arpa. on 8.8.8.8:53: no such host
root@arch:~# GODEBUG=netdns=go+3 go run main.go 192.168.1.200
go package net: confVal.netCgo = false netGo = true
go package net: GODEBUG setting forcing use of Go's resolver
go package net: hostLookupOrder() = dns
[] lookup 200.1.168.192.in-addr.arpa. on 8.8.8.8:53: no such host
root@arch:~# GODEBUG=netdns=cgo+3 go run main.go 192.168.1.200
go package net: confVal.netCgo = true netGo = false
go package net: using cgo DNS resolver
go package net: hostLookupOrder() = cgo
[arch] <nil>
The problem come from that we are only checking for hostnames that the
myhostname can resolve, but not for the addrs that it can also.
man nss-myhostname:
Please keep in mind that nss-myhostname (and nss-resolve) also
resolve in the other direction — from locally attached IP
addresses to hostnames.
Change-Id: Ic18a9f99a2214b2938463e9a95f7f3ca5db1c01b
GitHub-Last-Rev: ade40fd3e3
GitHub-Pull-Request: golang/go#59921
Reviewed-on: https://go-review.googlesource.com/c/go/+/491235
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Mateusz Poliwczak <mpoliwczak34@gmail.com>
The previous name was wrong due to the mistaken assumption that calling
f->g->getcallerpc and f->g->getcallersp would respectively return the
pc/sp at g. However, they are actually referring to their caller's
caller, i.e. f.
Rename getcallerfp to getfp in order to stay consistent with this
naming convention.
Also see discussion on CL 463835.
For #16638
Change-Id: I07990645da78819efd3db92f643326652ee516f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/481617
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Delete the "InlineSCCOnePass" debugging flag and the inliner fallback
code that kicks in if it is used. The change it was intended to guard
has been working on tip for some time, no need for the fallback any
more.
Updates #58905.
Change-Id: I2e1dbc7640902d9402213db5ad338be03deb96c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/492015
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The abi.Type field was changed to *abi.Type, thus the
bitwise representation is the same, many casts are now
avoided and replace by either rtype{afoo} or rfoo.Type.
Change-Id: Ie7643edc714a0e56027c2875498a4dfe989cf7dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/487558
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This refactoring is more problematic because the client
package wrap abi.Type, thus the self-referential fields
within ArrayType need to be downcast to the client wrappers
in several places. It's not clear to me this is worthwhile;
this CL is for additional comment, before I attempt similar
changes for other self-referential types.
Change-Id: I41e517e6d851b32560c41676b91b76d7eb17c951
Reviewed-on: https://go-review.googlesource.com/c/go/+/466236
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
I think there may be an issue in bisect search with
change set elements not actually being independent,
to be explored later. For now, modify the test to
remove that property.
Change-Id: I4b171bc024795d950cf4663374ad1dfc4e2952fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/494036
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
targs and xlist belong together (xlist contains the type expressions for
each of the type arguments).
Also, in builtins.go, rename xlist to alist2 to avoid some confusion.
Preparation for adding more parameters to the Checker.arguments signature.
Change-Id: I960501cfd2b88410ec0d581a6520a4e80fcdc56a
Reviewed-on: https://go-review.googlesource.com/c/go/+/494121
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
If the infer argument is true, funcInst behaves as before.
If infer is false and there are not enough type arguments,
rather then inferring the missing arguments and instantiating
the function, funcInst returns the found type arguments.
This permits the use of funcInst (and all the checks it does)
to collect the type arguments for partially instantiated
generic functions used as arguments to other functions.
For #59338.
Change-Id: I049034dfde52bd7ff4ae72964ff1708e154e5042
Reviewed-on: https://go-review.googlesource.com/c/go/+/494118
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This eliminate a network access in 'go mod tidy' of an already-tidy
module, which would otherwise be needed to fetch go.mod checksums for
the test dependencies whose go.mod checksums were omitted in Go
releases between Go 1.17 and 1.20 due to bug #56222.
For modules between 'go 1.17' and 'go 1.20' we intentionally preserve
the old 'go mod tidy' output (omitting go.sum entries for the go.mod
files of test dependencies of external packages). We should also avoid
performing extra sumdb lookups for checksums that would be discarded
anyway.
Updates #56222.
Change-Id: I7f0f1c8e902db0e3414c819621c4b99052f503f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/492741
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Don't assume we have all type arguments if the number of type arguments
matches the number of type parameters. Instead, look explicitly for nil
type arguments in the provided targs.
Preparation for type inference with type arguments provided for type
parameters of generic function arguments passed to other functions.
For #59338.
Change-Id: I00918cd5ed06ae3277b4e41a3641063e0f53fef0
Reviewed-on: https://go-review.googlesource.com/c/go/+/494115
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add tags to the fields of Source that lower-cases their names for JSON.
The implementation still treats Source specially for performance, but
now the result would be identical if it did not.
Change-Id: I5fd2e500f1a301db62af87be8b877ecd954a26ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/494035
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
libfuzzer is written in C and so requires by the C abi that SP be
aligned correctly mod 16. Normally CALLs need to have SP aligned to 0
mod 16, but because we're simulating a CALL (which pushes a return
address) with a JMP (which doesn't), we need to align to 8 mod 16
before JMPing.
This is not causing any current problems that I know of. All the
functions called from this callsite that I checked don't rely on
correct alignment. So this CL is just futureproofing.
Update #49075
Change-Id: I13fcbe9aaf2853056a6d44dc3aa64b7db689e144
Reviewed-on: https://go-review.googlesource.com/c/go/+/494117
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
On Windows, syscall.Seek is a thin wrapper over SetFilePointerEx [1],
which does not work on pipes, although it doesn't return an error on
that case. To avoid this undefined behavior, Seek defensively
calls GetFileType and errors if the type is FILE_TYPE_PIPE.
The problem with this approach is that Seek is a low level
foundational function that can be called many times for the same file,
and the additional cgo call (GetFileType) will artificially slow
down seek operations. I've seen GetFileType to account for 10% of cpu
time in seek-intensive workloads.
A better approach, implemented in this CL, would be to move the check
one level up, where many times the file type is already known so the
GetFileType is unnecessary.
The drawback is that syscall.Seek has had this behavior since pipes
where first introduced to Windows in
https://codereview.appspot.com/1715046 and someone could be relying on
it. On the other hand, this behavior is not documented, so we couldn't
be breaking any contract.
[1] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfilepointerex
Change-Id: I7602182f9d08632e22a8a1635bc8ad9ad35a5056
Reviewed-on: https://go-review.googlesource.com/c/go/+/493626
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The purpose of the debug.SetMaxThreads limit is to avoid accidental fork
bomb from something like millions of goroutines blocking on system
calls, causing the runtime to create millions of threads.
By definition we don't create threads created in C, so this isn't a
problem for those threads, and we can exclude them from the limit. If C
wants to create tens of thousands of threads, who are we to say no?
Fixes#60004.
Change-Id: I62b875890718b406abca42a9a4078391e25aa21b
Reviewed-on: https://go-review.googlesource.com/c/go/+/492743
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
The FS form was only necessary for reliable hashes in tests,
and for that we can use -trimpath.
Another potential concern would be temporary work directory
names leaking into the names of files generated by cgo and the
like, but we already make sure to avoid those to ensure
reproducible builds: the compiler never sees those paths.
So the FS form is not necessary for that either.
Change-Id: Idae2c6acb22ab64dfb33bb053244d23fbe153830
Reviewed-on: https://go-review.googlesource.com/c/go/+/493737
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Using more of internal/bisect gives us more that will be deleted
from base/hashdebug.go when we have updated the tools that
need the old protocol. It is also cheaper: there is no allocation to
make a decision about whether to enable, and no locking unless
printing is needed.
Change-Id: I43ec398461205a1a9e988512a134ed6b3a3b1587
Reviewed-on: https://go-review.googlesource.com/c/go/+/493736
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The call sites that cared all reversed inner-to-outer to outer-to-inner already.
The ones that didn't care left it alone. No one explicitly wanted inner-to-outer.
Also change to a callback-based interface, so that call sites aren't required
to accumulate the results in a slice (the main reason for that before was to
reverse the slice!).
There were three places where these lists were printed:
1. -d=ssa/genssa/dump, explicitly reversing to outer-to-inner
2. node dumps like -W, leaving the default inner-to-outer
3. file positions for HashDebugs, explicitly reversing to outer-to-inner
It makes no sense that (1) and (2) would differ. The reason they do is that
the code for (2) was too lazy to bother to fix it to be the right way.
Consider this program:
package p
func f() {
g()
}
func g() {
println()
}
Both before and after this change, the ssa dump for f looks like:
# x.go:3
00000 (3) TEXT <unlinkable>.f(SB), ABIInternal
00001 (3) FUNCDATA $0, gclocals·g2BeySu+wFnoycgXfElmcg==(SB)
00002 (3) FUNCDATA $1, gclocals·g2BeySu+wFnoycgXfElmcg==(SB)
v4 00003 (-4) XCHGL AX, AX
# x.go:4
# x.go:8
v5 00004 (+8) PCDATA $1, $0
v5 00005 (+8) CALL runtime.printlock(SB)
v7 00006 (-8) CALL runtime.printnl(SB)
v9 00007 (-8) CALL runtime.printunlock(SB)
# x.go:5
b2 00008 (5) RET
00009 (?) END
Note # x.go:4 (f) then # x.go:8 (g, called from f) between v4 and v5.
The -W node dumps used the opposite order:
before walk f
. AS2 Def tc(1) # x.go:4:3
. INLMARK # +x.go:4:3
. PRINTN tc(1) # x.go:8:9,x.go:4:3
. LABEL p..i0 # x.go:4:3
Now they match the ssa dump order, and they use spaces as separators,
to avoid potential problems with commas in some editors.
before walk f
. AS2 Def tc(1) # x.go:4:3
. INLMARK # +x.go:4:3
. PRINTN tc(1) # x.go:4:3 x.go:8:9
. LABEL p..i0 # x.go:4:3
I'm unaware of any argument for the old order other than it was easier
to compute without allocation. The new code uses recursion to reverse
the order without allocation.
Now that the callers get the results outer-to-inner, most don't need
any slices at all.
This change is particularly important for HashDebug, which had been
using a locked temporary slice to walk the inline stack without allocation.
Now the temporary slice is gone.
Change-Id: I5cb6d76b2f950db67b248acc928e47a0460569f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/493735
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
CL 491875 introduces a new bisect command, which we plan to
document for use by end users to debug semantic changes in
the compiler and in GODEBUGs.
This CL adds bisect support to GODEBUGs, at least the ones
used via internal/godebug. Support for runtime-internal
GODEBUGs like panicnil will take a bit more work in followup CLs.
The new API in internal/bisect to support stack-based bisecting
should be easily reusable in non-GODEBUG settings as well,
once we finalize and export the API.
Change-Id: I6cf779c775329aceb3f3b2b2b2f221ce8a67deee
Reviewed-on: https://go-review.googlesource.com/c/go/+/491975
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Today, external linking is not supported on any ppc64 ELF target, but
soon openbsd will be enabled with external linking support.
This relocation does not require additional endian specific fixups
like most other PPC64 Go relocation types.
I discovered this during an experiment to support external linking
on ppc64/linux.
Change-Id: I0b12b6172c7ba08df1c8cf024b4aa5e7ee76d0c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/492618
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The x/net version was updated in CL 493596; cmd/internal/moddeps
catches the skew, but only runs on the -longtest builders (because it
requires network access for the bundle tool and x/net dependency).
Change-Id: I48891d51aab23b2ca6f4484215438c60bd8c8c21
Reviewed-on: https://go-review.googlesource.com/c/go/+/493875
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
go get golang.org/x/tools@8f7fb01dd429 # CL 493619
go mod tidy
go mod vendor
The goal is to set up for importing the bisect command,
for use in tests, in a follow-up CL.
This also updates x/sys and x/net, including in std,
because x/tools now depends on newer versions of those.
Change-Id: I24c283cc165464d9c873ba7a9a4e75a9d02919b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/493596
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
The unused analyzer handles dot imports now, so a few tests
have picked up vet errors. This CL errors like:
context/x_test.go:524:47: result of context.WithValue call not used
Change-Id: I711a62fd7b50381f8ea45ac526bf0c946a171047
Reviewed-on: https://go-review.googlesource.com/c/go/+/493598
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
TestCrashExitCode was added in CL 491935 to test that the exit code
is honored when using GOTRACEBACK=crash, which is what normally happens
on a stock Windows. The problem is that some applications (not only WER,
as I incorrectly assumed in CL 491935) can hijack a crashing process
and change its exit code.
There is no way to tell if a crashing process using GOTRACEBACK=crash/
wer will have its error code hijacked, so we better don't test this
behavior, which in fact is not documented by the Go runtime.
Change-Id: Ib8247a8a1fe6303c4c7812a1bf2ded5f4e89acb1
Reviewed-on: https://go-review.googlesource.com/c/go/+/493495
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Thanks to the recent addition of the memcombine pass, the
ppc64 ports now have the memcombine optimizations. Previously
in PPC64.rules, the memcombine rules were only added for
ppc64le targets due to the significant increase in size of
the rewritePPC64.go file when those rules were added. The
ppc64 and ppc64le rules had to be different because of the
byte order due to endianness differences.
This enables the memcombine tests to be run on ppc64 as well
as ppc64le.
Change-Id: I4081e2d94617a1b66541d536c0c2662e266c9c1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/492615
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Lynn Boger <laboger@linux.vnet.ibm.com>
There are quite a few locations that get/put Ms from the extra M list,
but the API is pretty clumsy to use. Add an easier to use getExtraM /
putExtraM API.
There are only two minor semantic changes:
1. dropm no longer calls setg(nil) inside the lockextra critical
section. It is important that this thread no longer references the G
(and in turn M) once it is published to the extra M list and another
thread could acquire it. But there is no reason that needs to happen
only after lockextra.
2. extraMLength (renamed from extraMCount) is no longer protected by
lockextra and is instead simply an atomic (though writes are still in
the critical section). The previous readers all dropped lockextra
before using the value they read anyway.
For #60004.
Change-Id: Ifca4d6c84d605423855d89f49af400ca07de56f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/492742
Run-TryBot: Michael Pratt <mpratt@google.com>
Commit-Queue: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
When Git has safe.bareRepository=explicit set, operations on bare Git
repositories will fail unless --git-dir or GIT_DIR is set. The rest of
the time, specifying the gitdir makes repository discovery at the
beginning of a Git command ever-so-slightly faster. So, there is no
downside to ensuring that users with this stricter security config set
can still use 'go mod' commands easily.
See
https://lore.kernel.org/git/pull.1261.v8.git.git.1657834081.gitgitgadget@gmail.com/
for a more detailed description of security concerns around embedded
bare repositories without an explicitly specified GIT_DIR.
Change-Id: I01c1d97a79fdab12c2b5532caf84eb7760f96b18
Reviewed-on: https://go-review.googlesource.com/c/go/+/489915
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
In CL 486275 I added a somewhat complex init function that sets up a
callback to probe for exec support. A lot of the complexity was simply
to avoid an unnecessary call to os.Environ during init.
In CL 491660, I made the os.Environ call unconditional on all
platforms anyway in order to make HasGoBuild more robust.
Since the init-function indirection no longer serves a useful purpose,
I would like to simplify it to a package-level function, avoiding the
complexity of changing package variables at init time.
Change-Id: Ie0041d52cbde06ff14540192c8fba869a851158e
Reviewed-on: https://go-review.googlesource.com/c/go/+/492977
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For untyped constant binary operations we need to determine the
"maximum" (untyped) type which includes both constant types.
Factor out this functionality.
Change-Id: If42bd793d38423322885a3063a4321bd56443b36
Reviewed-on: https://go-review.googlesource.com/c/go/+/492619
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
first with an attempt in CL 482355, then again in CL 484859, and then
one more time with CL 492135.]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Change-Id: I5f75fcceb177f05853996b75184a486528eafe96
Reviewed-on: https://go-review.googlesource.com/c/go/+/492017
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
If the function referenced by a closure expression is incorporated
into a static init, be sure to mark it as non-hidden, since otherwise
it will be live but no longer reachable from the init func, hence it
will be skipped during escape analysis, which can lead to
miscompilations.
Fixes#59680.
Change-Id: Ib858aee296efcc0b7655d25c23ab8a6a8dbdc5f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/492135
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
[This is a roll-forward of CL 484859, this time including a fix for
issue #59709. The call to do dead function marking was taking place in
the wrong spot, causing it to run more than once if generics were
instantiated.]
This patch generalizes the code in the inliner that marks unreferenced
hidden closure functions as dead. Rather than doing the marking on the
fly (previous approach), this new approach does a single pass at the
end of inlining, which catches more dead functions.
Change-Id: I0e079ad755c21295477201acbd7e1a732a98fffd
Reviewed-on: https://go-review.googlesource.com/c/go/+/492016
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
For generic functions, the previous CL makes it record the full
instantiated symbol name in the runtime func table. This CL
changes the pprof package to use that name in CPU profile. This
way, it matches the symbol name the compiler sees, so it can apply
PGO.
TODO: add a test.
Fixes#58712.
Change-Id: If40db01cbef5f73c279adcc9c290a757ef6955b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/491678
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
For generic functions and methods, we replace the instantiated
shape type parameter name to "...", to make the function name
printed in stack traces looks more user friendly. Currently, this
is done in the binary's runtime func table at link time, and the
runtime has no way to access the full symbol name. This causes
the profile to also contain the replaced name. For PGO, this also
cause the compiler to not be able to find out the original fully
instantiated function name from the profile.
With this CL, we change the linker to record the full name, and
do the name substitution at run time when a printing a function's
name in traceback.
For #58712.
Change-Id: Ia0ea0989a1ec231f3c4fbf59365c9333405396c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/491677
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We now use SHF_COMPRESSED sections for DWARF compression, and no
longer generate zdebug sections on ELF platforms. No need to
generate them in the section header string table.
Updates #50796.
Change-Id: I5c79ccd43f803c75dbd86e28195d0db1c0beb087
Reviewed-on: https://go-review.googlesource.com/c/go/+/492719
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, we pass elfsetstring to the loader as a callback, for
a special case of Addstring. This is only used for ELF when adding
strings to the section header string table. Move the logic to the
caller instead, so the loader would not have this special case.
Change-Id: Icfb91f380fe4ba435985c3019681597932f58242
Reviewed-on: https://go-review.googlesource.com/c/go/+/492718
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This patch contains a small set of changes with fixes for some
issues that surfaced during the code review for CL 484535. Due
to an error on my part, these never got included in the final version
that was checked in (I rebased, mailed the rebase, but then never
mailed the final patch set with the changes). This patch sends
the remaining bits and pieces.
Updates #59563.
Change-Id: I87dc05a83f8e44c8bfe7203bc2b035defc817af9
Reviewed-on: https://go-review.googlesource.com/c/go/+/492981
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When we load a package from a module, we need the go version line from
that module's go.mod file to know what language semantics to use for
the package. We need to save a checksum for the go.mod file even if
the module's requirements are pruned out of the module graph.
Previously, we were missing checksums for test dependencies of
packages in 'all' and packages passed to 'go get -t'.
This change preserves the existing bug for 'go mod tidy' in older
module versions, but fixes it for 'go mod tidy' in modules at go 1.21
or higher and for 'go get -t' at all versions.
Fixes#56222.
Change-Id: Icd6acce348907621ae0b02dbeac04fb180353dcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/489075
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
CL 491875 introduces a new bisect command, which we plan to
document for use by end users to debug semantic changes in
the compiler and in GODEBUGs.
This CL adapts the existing GOSSAHASH support, which bisect
is a revision of, to support the specific syntax and output used
by bisect as well.
A followup CL will remove the old GOSSAHASH syntax and output
once existing consumers of that interface have been updated.
Change-Id: I99c4af54bb82c91c74bd8b8282ded968e6316f56
Reviewed-on: https://go-review.googlesource.com/c/go/+/491895
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This touches a lot of files, which is bad, but it is also good,
since there's N copies of this information commoned into 1.
The new files in internal/abi are copied from the end of the stack;
ultimately this will all end up being used.
Change-Id: Ia252c0055aaa72ca569411ef9f9e96e3d610889e
Reviewed-on: https://go-review.googlesource.com/c/go/+/462995
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This is intended to support automated pairing of performance
regressions with transformed loops; there is already a POC
for doing this in the general missed-optimization case; the
difference here is the ability to describe an entire range,
which required some extra plumbing to acquire and publish
the ending line+column.
Change-Id: Ibe606786f6be917b5a9a69d773560ed716a0754d
Reviewed-on: https://go-review.googlesource.com/c/go/+/492717
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
go env, without any arguments, outputs the environment variables in
the form of a script that can be run on the host OS. On Unix, single
quote the strings and place single quotes themselves outside the
single quoted strings. On windows use the set "var=val" syntax with
the quote starting before the variable.
Fixes#58508
Change-Id: Iecd379a4af7285ea9b2024f0202250c74fd9a2bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/488375
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
TestWERDialogue intent is to check that the WER dialog doesn't pop-up
when `GOTRACEBACK=wer` is set. CL 474915 extended the test to also
check the error code of the crashed process. This change is causing
failures in Microsoft internal test pipelines because some WER setups
can modify the exit code of the crashed application, for example to
signal that the crash dump has been collected.
Fix this issue by not checking the error code in TestWERDialogue. Also,
add a new test, TestCrashExitCode, which does the same but using
`GOTRACEBACK=crash` instead, so that we have one test that checks the
error code.
Change-Id: Iedde09e1df7223009ebef38a32a460f1ab07e31a
Reviewed-on: https://go-review.googlesource.com/c/go/+/491935
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Remove the special-case handling of NaN and infinities from
appendJSONValue, making JSONHandler behave almost exactly like
a json.Encoder without HTML escaping.
The only differences are:
- Encoding errors are turned into strings, instead of causing the Handle method to fail.
- Values of type `error` are displayed as strings by calling their `Error` method.
Fixes#59345.
Change-Id: Id06bd952bbfef596e864bd5fd3f9f4f178f738c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/486855
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
This test calls runtime.GC quite a number of times. GC is a global
operation. To reduce interference with other tests, don't run this
test in parallel with other tests.
May fix#57601.
Change-Id: I6efadb62c4dada37a927455f5c6cd98cafb88aaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/492715
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Move the "Attrs and Values" section lower. It describes an optimization;
the API it covers is not essential.
Also, move the brief section on Logger.With up to the first section.
It was in the "Groups" section but didn't belong there.
Change-Id: I0e36ef654e95f918d5b480566ec58d9990d26b40
Reviewed-on: https://go-review.googlesource.com/c/go/+/487856
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
HasExec is an attractive nuisance: it is tempting to check in a
TestMain function, but TestMain really shouldn't be running
subprocesses eagerly anyway (they add needless overhead for operations
like 'go test -list=.'), and the trick of re-executing the test binary
to determine whether 'exec' works ends up in infinite recursion if
TestMain itself calls HasExec.
Instead, tests that need to execute a subprocess should call
MustHaveExec or MustHaveExecPath from within a specific test,
or just try to exec the program and check its error status
(perhaps using testenv.SyscallIsNotSupported).
While I'm in here and testing on the SlowBots anyway, a few other
cleanups relating to subprocesses:
- Add more t.Helper calls to support checks where appropriate.
- Remove findGoTool, which can be simplified to exec.LookPath as of
CL 404134.
- Add tests confirming the expected behavior of the support functions
on the Go project's builders.
Change-Id: I163c701b2dd6eb6b7a036c6848f99b64dd9f0838
Reviewed-on: https://go-review.googlesource.com/c/go/+/491660
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
When combining a byteswap and a load, the resulting combined op
must go in the load's block, not the byteswap's block, as the load
has a memory argument that might only be valid in its original block.
Fixes#59973
Change-Id: Icd84863ef3a9ca1fc22f2bb794a003f2808c746f
Reviewed-on: https://go-review.googlesource.com/c/go/+/492616
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Keith Randall <khr@google.com>
Proposal #59338 has been accepted and we expect this feature to
be available starting with Go 1.21. Remove the flag to explicitly
enable it through the API and enable by default.
For now keep an internal constant enableReverseTypeInference to
guard and mark the respective code, so we can disable it for
debugging purposes.
For #59338.
Change-Id: Ia1bf3032483ae603017a0f459417ec73837e2891
Reviewed-on: https://go-review.googlesource.com/c/go/+/491798
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
After type arguments for all type parameters have been determined,
the type arguments are "simplified" by substituting any type parameters
that might occur in them with their corresponding type arguments until
all type parameters have been removed.
If in this process a (formerly) generic function signature becomes
non-generic, make sure to nil out its (declared) type parameters.
Fixes#59953.
For #59338.
Change-Id: Ie16bffd7b0a8baed18e76e5532cdfaecd26e4278
Reviewed-on: https://go-review.googlesource.com/c/go/+/491797
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
For correct inference, if the same generic function is provided
more than once as an argument to another function, the argument
function's type parameters must be unique for each argument so
that the type parameters can be correctly inferred.
Example:
func f(func(int), func(string)) {}
func g[P any](P) {}
func _() {
f(g, g)
}
Here the type parameter P for the first g argument resolves to int
and the type parameter P for the second g argument resolves to string.
Fixes#59956.
For #59338.
Change-Id: I10ce0ea08c2033722dd7c7c976b2a5448b2ee2d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/492516
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
After CL 487196 there is no need anymore to return
completed == false from the cgo lookup functions and
then fallback to to go resolver. (Before CL 487196 this
change would cause the (only?) tests to fail)
Now the cgoAvailable constant guards that correctly.
This change will cause a panic when the cgo resolver is being
used without the cgo support, so it will be easier to
detect bug while changing the code in the net package.
I am leaving the completed return from cgoLookupCNAME,
because it is super broken now.
Change-Id: I2661b9a3725de2b1a229847c12adf64b3f62b136
GitHub-Last-Rev: 2a6501a53e
GitHub-Pull-Request: golang/go#59925
Reviewed-on: https://go-review.googlesource.com/c/go/+/491275
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Mateusz Poliwczak <mpoliwczak34@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Previously localGitURL was initialized in TestMain, which creates
needless work if the test flags do not result in running a test that
requires localGitURL.
We had also been skipping a bunch of tests that used
vcs-test.golang.org in order to avoid network traffic, but now that
that content is served through an in-process vcweb server that is no
longer necessary. (All of the 'git' tests together take less than a
second to run.)
The 'hg' tests are much slower, so we do still skip those in short
mode.
Updates #59940.
Change-Id: Ie4f2d2bc825d7a011e25e754edf1a7c3c6010c77
Reviewed-on: https://go-review.googlesource.com/c/go/+/491659
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Simplify the PLT stub generation code to minimize stub generation
knowing there is only ever a single TOC pointer when linking
internally.
The OpenBSD port requires Go make dynamic calls into its C library,
so the linker must create stubs which work without R2 being set up.
This new case is exactly case 3 described in the PPC64 ELFv2 1.5
section 4.2.5.3.
Updates #56001
Change-Id: I07ebd08442302e55b94b57db474dfd7e7a0c2ac9
Reviewed-on: https://go-review.googlesource.com/c/go/+/488316
Auto-Submit: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Previously, type arguments could only be inferred for generic
functions in call expressions, whereas with the reverse type inference
proposal they can now be inferred in assignment contexts too. As a
consequence, we now need to check Info.Instances to find the inferred
type for more cases now.
Updates #59338.
Fixes#59955.
Change-Id: I9b6465395869459c2387d0424febe7337b28b90e
Reviewed-on: https://go-review.googlesource.com/c/go/+/492455
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Fix up the coverage testpoint TestIssue59563TruncatedCoverPkgAll
to avoid spurious failures due to racy behavior. Specifically,
we are only interested in verifying coverage for the larger
function of the two in the test package (the smaller one is only
there to trigger additional function registrations while the
test is finalizing the cov data).
Updates #59867.
Updates #59563.
Change-Id: Ibfbbcbf68e0ad7a4d9606cbcfc69d140375c7b87
Reviewed-on: https://go-review.googlesource.com/c/go/+/492175
Run-TryBot: Than McIntosh <thanm@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
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: I9b152754f27231f583a6995fc7cd8472aa7d390c
Reviewed-on: https://go-review.googlesource.com/c/go/+/458755
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
This removes the duplicate (and possible error-prone) versions
(once for test and once for error message) and simplifies code.
Adjusted multiple go/types call sites to match types2.
Renamed posFor to atPos in types2, for closer match with go/types
and to keep automatic generation of instantiate.go working.
Change-Id: Iff428fc742f305a65bb7d077b7e31b66df3b706d
Reviewed-on: https://go-review.googlesource.com/c/go/+/491715
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Allow function-typed function arguments to be generic and collect
their type parameters together with the callee's type parameters
(if any). Use a single inference step to infer the type arguments
for all type parameters simultaneously.
Requires Go 1.21 and that Config.EnableReverseTypeInference is set.
Does not yet support partially instantiated generic function arguments.
Not yet enabled in the compiler.
Known bug: inference may produce an incorrect result is the same
generic function is passed twice in the same function
call.
For #59338.
Change-Id: Ia1faa27a28c6353f0bbfd7f81feafc21bd36652c
Reviewed-on: https://go-review.googlesource.com/c/go/+/483935
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
go_android_exec gets the exit status of the process run inside the
Android emulator by sending a small shell script that runs the desired
command and then prints "exitcode=" followed by the exit code. This is
necessary because adb does not reliably pass through the exit status
of the subprocess.
An old bug about this
(https://code.google.com/p/android/issues/detail?id=3254) was closed
in 2016 as fixed in Android N (7.0), but it seems that the adb on the
Android builder at least still sometimes fails to pass through the
exit code.
Unfortunately, this workaround has the effect of injecting
"exitcode=N" into the output of the subprocess it runs, which messes
up tests that are looking for golden output from a subprocess.
Fix this by inserting a filter Writer that looks for the final
"exitcode=N" and strips it from the exec wrapper's own stdout.
For #15919.
This will help us in cleaning up "host tests" for #37486.
Change-Id: I9859f5b215e0ec4a7e33ada04a1857f3cfaf55ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/488975
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This makes 'go test -list cmd/api' work, and fixes an infinite
recursion via testenv.HasExec that would otherwise occur.
As of CL 488076, testenv.HasExec tries to re-exec the test
executable using -list to suppress running the tests, which
produces a fork bomb if TestMain itself calls HasExec.
For this test, it turns out that the HasExec check is redundant
anyway: if we can exec 'go build', we can certainly exec programs in
general too.
Change-Id: I165f98315c181098c8be8b7525b9dfa3f98e14f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/491656
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Add TestSystemstackFramePointerAdjust as a regression test for CL
489015.
By turning stackPoisonCopy into a var instead of const and introducing
the ShrinkStackAndVerifyFramePointers() helper function, we are able to
trigger the exact combination of events that can crash traceEvent() if
systemstack restores a frame pointer that is pointing into the old
stack.
Updates #59692
Change-Id: I60fc6940638077e3b60a81d923b5f5b4f6d8a44c
Reviewed-on: https://go-review.googlesource.com/c/go/+/489115
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
The type name symbol is always from a Go object file and we never
change it. Convert the data to string using unsafe conversion
without allocation.
Linking cmd/go (on macOS/amd64),
name old alloc/op new alloc/op delta
Deadcode_GC 1.25MB ± 0% 1.17MB ± 0% -6.29% (p=0.000 n=20+20)
name old allocs/op new allocs/op delta
Deadcode_GC 8.98k ± 0% 0.10k ± 3% -98.91% (p=0.000 n=20+20)
Change-Id: I33117ad1f991e4f14ce0b38cceec50b041e3c0a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/490915
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Re-enable frame pointer unwinding for execution tracing on amd64 by
default, now that CL 489015 and CL 488755 have fixed recently-discovered
crashes. This reverts CL 486382.
These fixes, together with CL 241158 to fix up frame pointers when
copying stacks on arm64, also make frame pointer unwinding for tracing
safe to enable for arm64. This should significantly reduce the CPU and
latency overhead of execution tracing on arm64, as it has for amd64.
Co-Authored-By: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Change-Id: I64a88bd69dfd8cb13956ec46f8b1203dbeaa26a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/490815
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Run-TryBot: Nick Ripley <nick.ripley@datadoghq.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This change causes cgo to emit an error (with the same
message as the compiler) when it encounters a declaration
of a method whose receiver type is C.T or *C.T.
Conceptually, C is another package, but unfortunately
the desugaring of C.T is a type within the same package,
causing the previous behavior to accept invalid input.
It is likely that at least some users are intentionally
exploiting this behavior, so this may break their build.
We should mention it in the release notes.
Fixes#57926
Change-Id: I513cffb7e13bc93d08a07b7e61301ac1762fd42d
Reviewed-on: https://go-review.googlesource.com/c/go/+/490819
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Some versions of dsymutils, notably the one in clang 14.0.3, which
is shipped in some versions of Xcode, have a bug that it creates a
temporary directory but doesn't clean it up at exit. The temporary
directory is created in DSYMUTIL_REPRODUCER_PATH (if set,
otherwise TMPDIR). Work around the issue by setting
DSYMUTIL_REPRODUCER_PATH to the linker's temporary directory, so
the linker will clean it up at exit anyway.
Fixes#59026.
Change-Id: Ie3e90a2d6a01f90040dc2eac91e8e536ccdda5a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/490818
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Static data symbols are compiler generated, not user symbols. The
linker already does not include them in the final DWARF section.
Don't generate the DWARF info in the first place.
Change-Id: Id2ae36683bfc1ed60b9924b7305eae5e8aa14d80
Reviewed-on: https://go-review.googlesource.com/c/go/+/490817
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL adds a .xdata section to the PE file generated by the Go linker.
It is also the first CL of the SEH chain that adds effective support
for unwinding the Go stack, as demonstrated by the newly added tests.
The .xdata section is a standard PE section that contains
an array of unwind data info structures. This structures are used to
record the effects a function has on the stack pointer,
and where the nonvolatile registers are saved on the stack [1].
Note that this CL still does not support unwinding the cgo stack.
Updates #57302
[1] https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64#struct-unwind_info
Change-Id: I6f305a51ed130b758ff9ca7b90c091e50a109a6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/457455
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Davis Goodin <dagood@microsoft.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL adds a .pdata section to the PE file generated by the Go linker.
The .pdata section is a standard section [1] that contains an array of
function table entries that are used for stack unwinding.
The table entries layout is taken from [2].
This CL just generates the table entries without any unwinding
information, which is enough to start doing some E2E tests
between the Go linker and the Win32 APIs.
The goal of the .pdata table is to allow Windows retrieve
unwind information for a function at a given PC. It does so by doing
a binary search on the table, looking for an entry that meets
BeginAddress >= PC < EndAddress.
Each table entry takes 12 bytes and only non-leaf functions with
frame pointer needs an entry on the .pdata table.
The result is that PE binaries will be ~0.7% bigger due to the unwind
information, a reasonable amount considering the benefits in
debuggability.
Updates #57302
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-pdata-section
[2] https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64#struct-runtime_function
Change-Id: If675d10c64452946dbab76709da20569651e3e9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/461738
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, for a global variable, its debug info symbol is a named
symbol with the variable's name with a special prefix. And the
linker looks it up by name. This CL makes the debug info symbol an
aux symbol of the variable symbol.
Change-Id: I55614d0ef2af9c53eb40144ad80e09339bf3cbee
Reviewed-on: https://go-review.googlesource.com/c/go/+/490816
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 484615 rewrote isParameterized by handling tuple types only where
they occur (function signatures). However, isParameterized is also
called from Checker.callExpr, with a result parameter list which
is a tuple. This CL handles tuples again.
Fixes#59890.
Change-Id: I35159ff65f23322432557e6abcab939933933d40
Reviewed-on: https://go-review.googlesource.com/c/go/+/490695
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
This makes it reasonable to "go build" from this directory by changing
the name of the directory to a more reasonable name for the binary and
dropping the unnecessary "ignore" build tag. The resulting binary
doesn't *quite* have the necessary name for a Go exec wrapper because
that needs to have the form, go_android_$GOARCH_exec, but it's close.
Change-Id: I036cb1af9c034462a952b176a794526fa3ffd1ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/490495
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>
A section with uninitialized data contains no bytes and occupies
no space in the file. This change makes it return an error on reading
from this section so that it will force the caller to check for
a section with uninitialized data.
This is the debug/pe version of CL 429601.
This will break programs that expect a byte slice with the length
described by the SizeOfRawData field. There are two reasons to
introduce this breaking change: 1) uninitialized data is uninitialized
and there is no reason to allocate memory for it; 2) it could result
in an OOM if the file is corrupted and has a large invalid SizeOfRawData.
No test case because the problem can only happen for invalid data. Let
the fuzzer find cases like this.
For #47653Fixes#59817
Change-Id: I1ae94e9508f803b37926275d9a571f724a09af9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/488475
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: kortschak <dan@kortschak.io>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change adjustframe to adjust the frame pointer of systemstack (aka
FuncID_systemstack_switch) before returning early.
Without this fix it is possible for traceEvent() to crash when using
frame pointer unwinding. The issue occurs when a goroutine calls
systemstack in order to call shrinkstack. While returning, systemstack
will restore the unadjusted frame pointer from its frame as part of its
epilogue. If the callee of systemstack then triggers a traceEvent, it
will try to unwind into the old stack. This can lead to a crash if the
memory of the old stack has been reused or freed in the meantime.
The most common situation in which this will manifest is when when
gcAssistAlloc() invokes gcAssistAlloc1() on systemstack() and performs a
shrinkstack() followed by a traceGCMarkAssistDone() or Gosched()
triggering traceEvent().
See CL 489115 for a deterministic test case that triggers the issue.
Meanwhile the problem can frequently be observed using the command
below:
$ GODEBUG=tracefpunwindoff=0 ../bin/go test -trace /dev/null -run TestDeferHeapAndStack ./runtime
SIGSEGV: segmentation violation
PC=0x45f977 m=14 sigcode=128
goroutine 0 [idle]:
runtime.fpTracebackPCs(...)
.../go/src/runtime/trace.go:945
runtime.traceStackID(0xcdab904677a?, {0x7f1584346018, 0x0?, 0x80}, 0x0?)
.../go/src/runtime/trace.go:917 +0x217 fp=0x7f1565ffab00 sp=0x7f1565ffaab8 pc=0x45f977
runtime.traceEventLocked(0x0?, 0x0?, 0x0?, 0xc00003dbd0, 0x12, 0x0, 0x1, {0x0, 0x0, 0x0})
.../go/src/runtime/trace.go:760 +0x285 fp=0x7f1565ffab78 sp=0x7f1565ffab00 pc=0x45ef45
runtime.traceEvent(0xf5?, 0x1, {0x0, 0x0, 0x0})
.../go/src/runtime/trace.go:692 +0xa9 fp=0x7f1565ffabe0 sp=0x7f1565ffab78 pc=0x45ec49
runtime.traceGoPreempt(...)
.../go/src/runtime/trace.go:1535
runtime.gopreempt_m(0xc000328340?)
.../go/src/runtime/proc.go:3551 +0x45 fp=0x7f1565ffac20 sp=0x7f1565ffabe0 pc=0x4449a5
runtime.newstack()
.../go/src/runtime/stack.go:1077 +0x3cb fp=0x7f1565ffadd0 sp=0x7f1565ffac20 pc=0x455feb
runtime.morestack()
.../go/src/runtime/asm_amd64.s:593 +0x8f fp=0x7f1565ffadd8 sp=0x7f1565ffadd0 pc=0x47644f
goroutine 19 [running]:
runtime.traceEvent(0x2c?, 0xffffffffffffffff, {0x0, 0x0, 0x0})
.../go/src/runtime/trace.go:669 +0xe8 fp=0xc0006e6c28 sp=0xc0006e6c20 pc=0x45ec88
runtime.traceGCMarkAssistDone(...)
.../go/src/runtime/trace.go:1497
runtime.gcAssistAlloc(0xc0003281a0)
.../go/src/runtime/mgcmark.go:517 +0x27d fp=0xc0006e6c88 sp=0xc0006e6c28 pc=0x421a1d
runtime.deductAssistCredit(0x0?)
.../go/src/runtime/malloc.go:1287 +0x54 fp=0xc0006e6cb0 sp=0xc0006e6c88 pc=0x40fed4
runtime.mallocgc(0x400, 0x7a9420, 0x1)
.../go/src/runtime/malloc.go:1002 +0xc9 fp=0xc0006e6d18 sp=0xc0006e6cb0 pc=0x40f709
runtime.newobject(0xb3?)
.../go/src/runtime/malloc.go:1324 +0x25 fp=0xc0006e6d40 sp=0xc0006e6d18 pc=0x40ffc5
runtime_test.deferHeapAndStack(0xb4)
.../go/src/runtime/stack_test.go:924 +0x165 fp=0xc0006e6e20 sp=0xc0006e6d40 pc=0x75c2a5
Fixes#59692
Co-Authored-By: Cherry Mui <cherryyz@google.com>
Co-Authored-By: Michael Knyszek <mknyszek@google.com>
Co-Authored-By: Nick Ripley <nick.ripley@datadoghq.com>
Change-Id: I1c0c28327fc2fac0b8cfdbaa72e25584331be31e
Reviewed-on: https://go-review.googlesource.com/c/go/+/489015
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Go programs targeting GOOS=wasip1 were failing to open directories when
executed with runtimes like wasmtime or wasmedge due to requesting
rights for operations that are not supported on directories such as
fd_read, fd_write, etc...
This change addresses the issue by performing a second path_open when
observing EISDIR, and masking the requested rights to only ask for
permissions to perform operations supported by a directory.
Change-Id: Ibf65acf4a38bc848a649f41dbd026507d8b63c82
Reviewed-on: https://go-review.googlesource.com/c/go/+/490755
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This indicates the symbol does not use or preserve the TOC pointer in
R2. Likewise, it does not have a distinct local entry point. This
happens when gcc compiles an object with -mcpu=power10.
Recycle the SymLocalentry field of a text symbol to pass through this
hint as the bogus value 1 (A valid offset must be a multiple of 4
bytes), and update the usage to check and generate errors further into
the linking process. This matches the behavior of st_other as used by
ELFv2.
Change-Id: Ic89ce17b57f400ab44213b21a3730a98c7cdf842
Reviewed-on: https://go-review.googlesource.com/c/go/+/490295
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The current mp.incgocallback() logic allows for trace events to be
recorded using frame pointer unwinding during cgocallbackg when they
shouldn't be. Specifically, mp.incgo will be false during the
reentersyscall call at the end. It's possible to crash with tracing
enabled because of this, if C code which uses the frame pointer register
for other purposes calls into Go. This can be seen, for example, by
forcing testprogcgo/trace_unix.c to write a garbage value to RBP prior
to calling into Go.
We can drop the mp.incgo check, and instead conservatively avoid doing
frame pointer unwinding if there is any C on the stack. This is the case
if mp.ncgo > 0, or if mp.isextra is true (meaning we're coming from a
thread created by C). Rename incgocallback to reflect that we're
checking if there's any C on the stack. We can also move the ncgo
increment in cgocall closer to where the transition to C happens, which
lets us use frame pointer unwinding for the entersyscall event during
the first Go-to-C call on a stack, when there isn't yet any C on the
stack.
Fixes#59830.
Change-Id: If178a705a9d38d0d2fb19589a9e669cd982d32cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/488755
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Nick Ripley <nick.ripley@datadoghq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Symbol names in the final executable apply escaping to the final
component of a package path (main in example.com becomes
example%2ecom.main).
ir.PkgFuncName does not perform this escaping, meaning we'd fail to
match functions that are escaped in the profile.
Add ir.LinkFuncName which does perform escaping and use it for PGO.
Fixes#59887.
Change-Id: I10634d63d99d0a6fd2f72b929ab35ea227e1336f
Reviewed-on: https://go-review.googlesource.com/c/go/+/490555
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This simplifies callers, as they do not need to call opirr before calling oaddi.
Additionally, use appropriate types (int16) for registers, which avoids the need
to continually cast.
Change-Id: I8ca3807a97867ac49d63792f6922a18f35824448
Reviewed-on: https://go-review.googlesource.com/c/go/+/471520
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Put zero-sized data symbols at same address as runtime.zerobase,
so zero-sized global variables have the same address as zero-sized
allocations.
Change-Id: Ib3145dc1b663a9794dfabc0e6abd2384960f2c49
Reviewed-on: https://go-review.googlesource.com/c/go/+/490435
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TestReaddirnamesOneAtATime and TestChdirAndGetwd assumes the underlying file system
has /usr/bin but it is not the case when running it on WASI runtime hosted on Windows.
This change adds wasip1 in the special cased switch case to make them host OS agonstic.
Change-Id: Idb667021b565f939c814b9cd9e637cd75f9a610d
Reviewed-on: https://go-review.googlesource.com/c/go/+/489575
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Syntactically incorrect source files may produce valid (but
unexpected) syntax trees, leading to difficult to understand
test failures.
Make sure to call mustParse when we call mustTypecheck.
Change-Id: I9f5ba3fe57ad3bbc16caabf285d2e7aeb5b9de0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/489995
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Currently, in plugin build mode we don't write the build ID. This
is disabled in CL 29394 since plugin is supported on Darwin. Maybe
it caused some problem with the Darwin dynamic linker. But it
seems no problem currently. Enabled it.
Fixes#59845.
Change-Id: I60589ffc7937e4d30055960d391cac1e7cd0cd42
Reviewed-on: https://go-review.googlesource.com/c/go/+/489457
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
This change addresses a `checkdead` panic caused by a race condition between
`sysmon->startm` and `checkdead` callers, due to prematurely releasing the
scheduler lock. The solution involves allowing a `startm` caller to acquire the
scheduler lock and call `startm` in this context. A new `lockheld` bool
argument is added to `startm`, which manages all lock and unlock calls within
the function. The`startIdle` function variable in `injectglist` is updated to
call `startm` with the lock held, ensuring proper lock handling in this
specific case. This refined lock handling resolves the observed race condition
issue.
Fixes#59600
Change-Id: I11663a15536c10c773fc2fde291d959099aa71be
Reviewed-on: https://go-review.googlesource.com/c/go/+/487316
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
- Fall back to 'go env GOROOT' to locate GOROOT if runtime.GOROOT() is
empty (as may be the case if the tool is built with -trimpath).
- Copy all of $GOROOT/android_$GOARCH/bin, not just cmd/go, to
$GOROOT/bin.
- For consistency with CL 404134, place $GOROOT/bin at the beginning
of $PATH, not the end.
- Don't use the install target for the "runtime" package to locate pkg/tool.
As of Go 1.20 "runtime" doesn't have an install directory anyway.
Since the real reason we need pkg/tool is for commands in "cmd",
use an arbitrary command (namely "cmd/compile") to locate it.
- Use 'go list' to determine the package import path for the current
directory, instead of assuming that it is within GOROOT or GOPATH.
(That assumption does not hold in module mode.)
Updates #58775.
Change-Id: If76ff22bce76d05175c40678230f046a4aff0940
Reviewed-on: https://go-review.googlesource.com/c/go/+/472096
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Changkun Ou <mail@changkun.de>
Auto-Submit: Bryan Mills <bcmills@google.com>
The resulting code behaves mostly the same. There are some minor
differences in error cases when the cgo resolver is not available:
instead of just falling back we keep trying to work out the right
nsswitch.conf order.
Change-Id: I17fadc940528fa2397043ac8f8ed7da3bd7a95c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/487196
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@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>
Reviewed-by: Mateusz Poliwczak <mpoliwczak34@gmail.com>
We no longer use the optional parameter to compareAPI.
We now always set allowAdd to false.
(Except in tests, making them less useful than they could be.)
Flags and parsing their value are no more.
Remove all the unused functionality and update test cases so they're
closer to what the API checker does when it runs for real. Order the
features, required, exception variables and fields more consistently.
For #43956.
Change-Id: Iaa4656a89a3fca3129742165a448d385e55e4a98
Reviewed-on: https://go-review.googlesource.com/c/go/+/489436
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We want the API check to catch if some API present in api/next/*
files is no longer implemented in the tree, and report it in the
same CL that is making the change (by failing loudly). Arguably
this should've been the case since CL 315350, but I didn't notice
it at the time. Do it now.
For #43956.
Change-Id: I73330dd5fd3f5706a1fdf13b2bf8e0f24c6b48e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/488135
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
It is necessary to invoke the t.Parallel() method in both the top-level test function and its subtest function to maximize parallelism. In doing so, all subtest functions calling the t.Parallel() method in the package will work in parallel.
On my machine, the execution time of this test file was cut in half.
Change-Id: If09147a2a9969bb044932d71e6bfea29492866d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/482755
Run-TryBot: shuang cui <imcusg@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This reapplies CL 481061, with the followup fixes in CL 482975, CL 485315, and
CL 485316 incorporated.
CL 481061, by doujiang24 <doujiang24@gmail.com>, speed up C to Go
calls by binding the M to the C thread. See below for its
description.
CL 482975 is a followup fix to a C declaration in testprogcgo.
CL 485315 is a followup fix for x_cgo_getstackbound on Illumos.
CL 485316 is a followup cleanup for ppc64 assembly.
[Original CL 481061 description]
This reapplies CL 392854, with the followup fixes in CL 479255,
CL 479915, and CL 481057 incorporated.
CL 392854, by doujiang24 <doujiang24@gmail.com>, speed up C to Go
calls by binding the M to the C thread. See below for its
description.
CL 479255 is a followup fix for a small bug in ARM assembly code.
CL 479915 is another followup fix to address C to Go calls after
the C code uses some stack, but that CL is also buggy.
CL 481057, by Michael Knyszek, is a followup fix for a memory leak
bug of CL 479915.
[Original CL 392854 description]
In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls.
So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call.
Instead, we only dropm while the C thread exits, so the extra M won't leak.
When invoking a Go function from C:
Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor.
And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits.
When returning back to C:
Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C.
This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows.
This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread.
For the newly added BenchmarkCGoInCThread, some benchmark results:
1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
[CL 479915 description]
Currently, when C calls into Go the first time, we grab an M
using needm, which sets m.g0's stack bounds using the SP. We don't
know how big the stack is, so we simply assume 32K. Previously,
when the Go function returns to C, we drop the M, and the next
time C calls into Go, we put a new stack bound on the g0 based on
the current SP. After CL 392854, we don't drop the M, and the next
time C calls into Go, we reuse the same g0, without recomputing
the stack bounds. If the C code uses quite a bit of stack space
before calling into Go, the SP may be well below the 32K stack
bound we assumed, so the runtime thinks the g0 stack overflows.
This CL makes needm get a more accurate stack bound from
pthread. (In some platforms this may still be a guess as we don't
know exactly where we are in the C stack), but it is probably
better than simply assuming 32K.
[CL 485500 description]
CL 479915 passed the G to _cgo_getstackbound for direct updates to
gp.stack.lo. A G can be reused on a new thread after the previous thread
exited. This could trigger the C TSAN race detector because it couldn't
see the synchronization in Go (lockextra) preventing the same G from
being used on multiple threads at the same time.
We work around this by passing the address of a stack variable to
_cgo_getstackbound rather than the G. The stack is generally unique per
thread, so TSAN won't see the same address from multiple threads. Even
if stacks are reused across threads by pthread, C TSAN should see the
synchonization in the stack allocator.
A regression test is added to misc/cgo/testsanitizer.
Fixes#51676.
Fixes#59294.
Fixes#59678.
Change-Id: Ic62be31a06ee83568215e875a891df37084e08ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/485500
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
PPC64 processes external object relocations against the section
symbols. This needs to be set correctly to determine the type of
PLT stub to generate when both Go and External code make PLT calls.
Change-Id: I5abdd5a0473866164083c33e80324dffcc1707f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/488895
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This patch revises the way coverage counter data writing takes place
to avoid problems where useful counter data (for user-written functions)
is skipped in favor of counter data from stdlib functions that are
executed "late in the game", during the counter writing process itself.
Reading counter values from a running "--coverpkg=all" program is an
inherently racy operation; while the the code that scans the coverage
counter segment is reading values, the program is still executing,
potentially updating those values, and updates can include execution
of previously un-executed functions. The existing counter data writing
code was using a two-pass model (initial sweep over the counter
segment to count live functions, second sweep to actually write data),
and wasn't properly accounting for the fact that the second pass could
see more functions than the first.
In the bug in question, the first pass discovered an initial set of
1240 functions, but by the time the second pass kicked in, several
additional new functions were also live. The second pass scanned the
counter segment again to write out exactly 1240 functions, but since
some of the counters for the newly executed functions were earlier in
the segment (due to linker layout quirks) than the user's selected
function, the sweep terminated before writing out counters for the
function of interest.
The fix rewrites the counter data file encoder to make a single sweep
over the counter segment instead of using a two-pass scheme.
Fixes#59563.
Change-Id: I5e908e226bb224adb90a2fb783013e52deb341da
Reviewed-on: https://go-review.googlesource.com/c/go/+/484535
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
The slicewriter Seek method was being too restrictive on offsets
accepted, due to an off-by-one problem in the error checking code.
This fixes the problem and touches up the unit tests.
Change-Id: I75d6121551de19ec9275f0e331810db231db6ea9
Reviewed-on: https://go-review.googlesource.com/c/go/+/488116
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, "dist test -compile-only" still runs the test binaries,
just with -run=^$ so no tests are run. It does this because, until
recently, "go test -c" would fail if passed multiple test packages.
But this has some unexpected consequences: init code still runs,
TestMain still runs, and we generally can't test cross-compiling of
tests.
Now that #15513 is fixed, we can pass multiple packages to "go test
-c". Hence, this CL make dist just use "go test -c" as one would
expect.
Found in the course of working on #37486, though it doesn't really
affect that.
Change-Id: If7d3c72c9e0f74d4ea0dd422411e5ee93b314be4
Reviewed-on: https://go-review.googlesource.com/c/go/+/488275
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
The Go runtime allocates the TLS slot in the TEB TLS slots instead of
using the TEB arbitrary pointer. See CL 431775 for more context.
The problem is that the TEB TLS slots array only has capacity for 64
indices, allocating more requires some complex logic that we don't
support yet.
Although the Go runtime only allocates one index, a Go DLL can be
loaded in a process with more than 64 TLS slots allocated,
in which case it abort.
This CL avoids aborting by falling back to the older behavior, that
is to use the TEB arbitrary pointer.
Fixes#59213
Change-Id: I39c73286fe2da95aa9c5ec5657ee0979ecbec533
Reviewed-on: https://go-review.googlesource.com/c/go/+/486816
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The memmove implementation relies on the variable
runtime.arm64UseAlignedLoads to select fastest code
path. Considering Neoverse N2 and V2 cores prefer aligned
loads, this patch adds code to detect them for
memmove performance.
And this patch uses a new variable ARM64.IsNeoverse to
represent all Neoverse cores, removing the more specific
versions.
Change-Id: I9e06eae01a0325a0b604ac6af1e55711dd6133f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/487815
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Fannie Zhang <Fannie.Zhang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Due to a stray edit in CL 486275, the assignment to tryExecOk
in tryExec on ios would be immediately overwritten back to false.
This change fixes the stray edit.
Change-Id: I4f45fbf130dc912305e5f453b0d1a622ba199ad4
Reviewed-on: https://go-review.googlesource.com/c/go/+/488076
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
We added a check for incorrect baseOffset in CL 408734, but in doing so
we introduced a panic when directoryOffset overflowed a int64. The zip
spec uses uint64, but since io.SectionReader requires int64 we convert,
and possibly introduce an overflow. If offset < 0 && size-offset < 0,
SectionReader will panic when we attempt to read from it.
Since it's extremely unlikely we're ever going to process a zip file
larger than 1<<63-1 byte, just limit directory size and offset to the
max int64.
Change-Id: I1aaa755cf4da927a6e12ef59f97dfc83a3426d86
Reviewed-on: https://go-review.googlesource.com/c/go/+/488195
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TestRaceProf and TestRaceSignal were changed to run on all platforms
that support the race detector as of CL 487575, but the testprogcgo
source files needed to run the test rely on POSIX threads and were
still build-constrained to only linux/amd64 and freebsd/amd64.
Since the C test program appears to require only POSIX APIs, update
the constraint to build the source file on all Unix platforms, and
update the tests to skip on Windows.
This may slightly increase testprogcgo build time on Unix platforms
that do not support the race detector.
Change-Id: I704dd496d475a3cd2e2da2a09c7d2e3bb8e96d02
Reviewed-on: https://go-review.googlesource.com/c/go/+/488115
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Add a package for testing that a slog.Handler implementation
satisfies that interface's documented requirements.
Code copied from x/exp/slog/slogtest.
Updates #56345.
Change-Id: I89e94d93bfbe58e3c524758f7ac3c3fba2a2ea96
Reviewed-on: https://go-review.googlesource.com/c/go/+/487895
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
For data symbols, we currently sort them by size, then by name if
the size is the same. Sorting by name is not really necessary.
Instead, we sort by symbol index. Like name, the symbol index is
deterministic, and pretty stable if only a small portion of the
input is changed, and also naturally partitioned by packages. This
reduces the CPU time for reading the symbol names and comparing
strings.
Linking cmd/compile (on macOS/amd64),
Dodata 57.2ms ± 6% 54.5ms ± 4% -4.74% (p=0.000 n=19+17)
Change-Id: I1c4f2b83dbbb4b984b2c8ab4a7e8543b9f7f22b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/487515
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, a symbol's global index, the Sym type, is defined as an
int, which is 64-bit on 64-bit machines. We're unlikely to have
more than 4 billion symbols in the near future. Even if we will,
we will probably hit some other limit (e.g. section size) before
the symbol number limit. Use a 32-bit type to reduce memory usage.
E,g, linking cmd/compile in external linking mode (on macOS/amd64)
Munmap_GC 43.2M ± 0% 35.5M ± 1% -17.74% (p=0.000 n=16+20)
This brings the memory usage back before the previous CL, and even
lower.
Change-Id: Ie185f1586638fe70d8121312bfa9410942d518c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/487416
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Although we aren't precise about enforcing the hosts just yet,
we can eventually use the declared hostnames to selectively skip
tests (for example, if an external service has an outage while
a Go release is being tested).
Also relax the constraint to [short] in tests that require only
vcs-test.golang.org, which has redirected to an in-process server
since around CL 427914.
Also enforce that tests that use the network actually use the [net]
constraint, by setting TESTGONETWORK=panic in the test environment
until the condition is evaluated.
For #52545.
For #54503.
Updates #27494.
Change-Id: I13be6b42a9beee97657eb45424882e787ac164c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/473276
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Bypass: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
The current implementation for this metric populates a histogram
that is never reset, i.e. where each bucket count increases
monotonically.
The comment in the definition of the Cumulative attribute calls
out that cumulative means that if the metric is a distribution,
then each bucket count increases monotonically.
In that sense, the cumulative attribute should be set to true for
this metric.
Change-Id: Ifc34e965a62f2d7881b5c8e8cbb8b7207a4d5757
Reviewed-on: https://go-review.googlesource.com/c/go/+/486755
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently, a symbol's outer symbol, the "special" attribute, and
whether a symbol is a generator symbol are represented as maps,
and are accessed in some loops over nearly all reachable symbols.
The map lookups are a bit expensive.
For outer symbol, a non-trivial portion of the symbols have outer
symbol set (e.g. type symbols, which we put into container symbols
like "type:*"). Using a slice to access more efficiently.
For the special and generator symbol attributes, use a bitmap.
There are not many symbols have those attributes, so the bitmap is
quite sparse. The bitmap is not too large anyway, so use it for
now. If we want to further reduce memory usage we could consider
some other data structure like a Bloom filter.
Linking cmd/compile in external linking mode (on macOS/amd64)
Symtab 12.9ms ± 9% 6.4ms ± 5% -50.08% (p=0.000 n=19+18)
Dodata 64.9ms ±12% 57.1ms ±12% -11.90% (p=0.000 n=20+20)
Asmb 36.7ms ±11% 32.8ms ± 9% -10.61% (p=0.000 n=20+18)
Asmb2 26.6ms ±15% 21.9ms ±12% -17.75% (p=0.000 n=20+18)
There is some increase of memory usage
Munmap_GC 40.9M ± 1% 43.2M ± 0% +5.54% (p=0.000 n=20+19)
The next CL will bring the memory usage back.
Change-Id: Ie4347eb96c51f008b9284270de37fc880bb52d2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/487415
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
When server and client have mismatch in curve preference, the server will
send HelloRetryRequest during TLSv1.3 PSK resumption. There was a bug
introduced by Go1.19.6 or later and Go1.20.1 or later, that makes the client
calculate the PSK binder hash incorrectly. Server will reject the TLS
handshake by sending alert: invalid PSK binder.
Fixes#59424
Change-Id: I2ca8948474275740a36d991c057b62a13392dbb9
GitHub-Last-Rev: 1aad9bcf27
GitHub-Pull-Request: golang/go#59425
Reviewed-on: https://go-review.googlesource.com/c/go/+/481955
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
This is the AIX and Solaris equivalent of CL 269378.
On AIX and Solaris, where we use libc for syscalls, when the runtime exits,
it calls the libc exit function, which may call back into user code,
such as invoking functions registered with atexit. In particular, it
may call back into Go. But at this point, the Go runtime is
already exiting, so this wouldn't work.
On non-libc platforms we use exit syscall directly, which doesn't
invoke any callbacks. Use _exit on AIX and Solaris to achieve the same
behavior.
Test is TestDestructorCallback.
For #59711
Change-Id: I666f75538d3e3d8cf3b697b4c32f3ecde8332890
Reviewed-on: https://go-review.googlesource.com/c/go/+/487635
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Some iOS environments may support exec. wasip1 and js do not, but
trying to exec on those platforms is inexpensive anyway and gives
better test coverage for the ios path.
Change-Id: I4baffb2ef5dc7d81e6a260f69033bfb229f13d92
Reviewed-on: https://go-review.googlesource.com/c/go/+/486275
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
The modification of these rules is optimization to load/store global
variables. If there are a sequence of loads/stores nearby a global
variable address, the address can only be loaded from GOT once instead
of every time.
For #43264
Change-Id: Idedaf6c81f085955371320f51bca148ffb42a2d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/348732
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
As part of developing #57411, we ran into cases where a flag was
defined in one package init and Set in another package init, and there
was no init ordering implied by the spec between those two
packages. Changes in initialization ordering as part of #57411 caused
a Set to happen before the definition, which makes the Set silently
fail.
This CL makes the Set fail loudly in that situation.
Currently Set *does* fail kinda quietly in that situation, in that it
returns an error. (It seems that no one checks the error from Set,
at least for string flags.) Ian suggsted that instead we panic at
the definition site if there was previously a Set called on that
(at the time undefined) flag.
So Set on an undefined flag is ok and returns an error (as before),
but defining a flag which has already been Set causes a panic. (The
API for flag definition has no way to return an error, and does
already panic in some situations like a duplicate definition.)
Update #57411
Change-Id: I39b5a49006f9469de0b7f3fe092afe3a352e4fcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/480215
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Memory op combining is currently done using arch-specific rewrite rules.
Instead, do them as a arch-independent rewrite pass. This ensures that
all architectures (with unaligned loads & stores) get equal treatment.
This removes a lot of rewrite rules.
The new pass is a bit more comprehensive. It handles things like out-of-order
writes and is careful not to apply partial optimizations that then block
further optimizations.
Change-Id: I780ff3bb052475cd725a923309616882d25b8d9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/478475
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This change resolves an issue where checkdead could result in a double lock when shedtrace is enabled. This fix involves adding unlocks before all throws in the checkdead function to ensure the scheduler lock is properly released.
Fixes#59758
Change-Id: If3ddf9969f4582c3c88dee9b9ecc355a63958103
Reviewed-on: https://go-review.googlesource.com/c/go/+/487375
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Leaked goroutines are the only explanation I can think of for excess
allocs in TestDiscard, and TestOutputRace is the only place I can see
where the log package leaks goroutines. Let's fix that leak and see if
it eliminates the TestDiscard flakes.
Fixes#58797 (maybe).
Change-Id: I2d54dcba3eb52bd10a62cd1c380131add6a2f651
Reviewed-on: https://go-review.googlesource.com/c/go/+/487356
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The current definitions of StackLimit and StackGuard only indirectly
specify the NOSPLIT stack limit and duplicate a literal constant
(928). Currently, they define the stack guard delta, and from there
compute the NOSPLIT limit.
Rationalize these by defining a new constant, abi.StackNosplitBase,
which consolidates and directly specifies the NOSPLIT stack limit (in
the default case). From this we then compute the stack guard delta,
inverting the relationship between these two constants. While we're
here, we rename StackLimit to StackNosplit to make it clearer what's
being limited.
This change does not affect the values of these constants in the
default configuration. It does slightly change how
StackGuardMultiplier values other than 1 affect the constants, but
this multiplier is a pretty rough heuristic anyway.
before after
stackNosplit 800 800
_StackGuard 928 928
stackNosplit -race 1728 1600
_StackGuard -race 1856 1728
For #59670.
Change-Id: Ia94094c5e47897e7c088d24b4a5e33f5c2768db5
Reviewed-on: https://go-review.googlesource.com/c/go/+/486976
Auto-Submit: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The initial purpose of PCALIGN was to identify code
where it would be beneficial to align code for performance,
but avoid cases where too many NOPs were added. On p10, it
is now necessary to enforce a certain alignment in some
cases, so the behavior of PCALIGN needs to be slightly
different. Code will now be aligned to the value specified
on the PCALIGN instruction regardless of number of NOPs added,
which is more intuitive and consistent with power assembler
alignment directives.
This also adds 64 as a possible alignment value.
The existing values used in PCALIGN were modified according to
the new behavior.
A testcase was updated and performance testing was done to
verify that this does not adversely affect performance.
Change-Id: Iad1cf5ff112e5bfc0514f0805be90e24095e932b
Reviewed-on: https://go-review.googlesource.com/c/go/+/485056
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
A CI machine has been set up to verify GOPPC64=power10 on ppc64/linux.
This should be sufficient to verify the PCrel relocation support works
for BE.
Note, power10/ppc64/linux is an oddball case. Today, it can only link
internally. Furthermore, all PCrel relocs are resolved at link time,
so it works despite ELFv1 having no official support for PCrel relocs
today.
Change-Id: Ibf79df69406ec6f9352c9d7d941ad946dba74e73
Reviewed-on: https://go-review.googlesource.com/c/go/+/485075
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Today Current may fail if the binary is not built with cgo
and USER and/or HOME is not set in the environment.
That should not cause the test to fail.
After this change,
GOCACHE=$(go env GOCACHE) CGO_ENABLED=0 USER= HOME= go test os/user
now passes on linux/amd64.
For #59583.
Change-Id: Id290cd1088051e930d73f0dd554177124796e8f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/487015
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
ssagen.ssafn already holds the ir.Func, and ssa.Frontend.SetWBPos and
ssa.Frontend.Lsym are simple wrappers around parts of the ir.Func.
Expose the ir.Func through ssa.Frontend, allowing us to remove these
wrapper methods and allowing future access to additional features of the
ir.Func if needed.
While we're here, drop ssa.Frontend.Line, which is unused.
For #58298.
Change-Id: I30c4cbd2743e9ad991d8c6b388484a7d1e95f3ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/484215
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
The scavenge index currently doesn't guard against overflow, and CL
436395 removed the minHeapIdx optimization that allows the chunk scan to
skip scanning chunks that haven't been mapped for the heap, and are only
available as a consequence of chunks' mapped region being rounded out to
a page on both ends.
Because the 0'th chunk is never mapped, minHeapIdx effectively prevents
overflow, fixing the iOS breakage.
This change also refactors growth and initialization a little bit to
decouple it from pageAlloc a bit and share code across platforms.
Change-Id: If7fc3245aa81cf99451bf8468458da31986a9b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/486695
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Add a struct called Source that holds the function, file and line
of a location in the program's source code.
When HandleOptions.AddSource is true, the ReplaceAttr function will
get an Attr whose key is SourceKey and whose value is a *Source.
We use *Source instead of Source to save an allocation. The pointer
and the value each cause one allocation up front: the pointer when it
is created, and the value when it is assigned to the `any` field of a
slog.Value (handle.go:283). If a ReplaceAttr function wanted to modify
a Source value, it would have to create a new slog.Value to return,
causing a second allocation, but the function can modify a *Source in
place.
TextHandler displays a Source as "file:line".
JSONHandler displays a Source as a group of its non-zero fields.
This replaces the previous design, where source location was always a
string with the format "file:line". The new design gives users more
control over how to output and consume source locations.
Fixes#59280.
Change-Id: I84475abd5ed83fc354b50e34325c7b246cf327c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/486376
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
During bootstrapping, cmd/dist writes a file indicating which
GOOS/GOARCH combinations are valid, and which support cgo-enabled
builds. That information previously went into the go/build package,
but today it fits in more naturally in the internal/platform package
(which already has a number of functions indicating feature support
for GOOS/GOARCH combinations).
Moreover, as of CL 450739 the cmd/go logic for determining whether to
use cgo is somewhat more nuanced than the go/build logic: cmd/go
checks for the presence of a C compiler, whereas go/build does not
(mostly because it determines its configuration at package-init time,
and checking $PATH for a C compiler is somewhat expensive).
To simplify this situation, this change:
- consolidates the “cgo supported” check in internal/platform
(alongside many other platform-support checks) instead of making
it a one-off in go/build,
- and updates a couple of tests to use testenv.HasCGO instead of
build.Default.CgoEnabled to decide whether to test a cgo-specific
behavior.
For #58884.
For #59500.
Change-Id: I0bb2502dba4545a3d98c9e915727382ce536a0f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/483695
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
The current definitions of StackLimit and StackGuard only indirectly
specify the NOSPLIT stack limit and duplicate a literal constant
(928). Currently, they define the stack guard delta, and from there
compute the NOSPLIT limit.
Rationalize these by defining a new constant, abi.StackNosplitBase,
which consolidates and directly specifies the NOSPLIT stack limit (in
the default case). From this we then compute the stack guard delta,
inverting the relationship between these two constants. While we're
here, we rename StackLimit to StackNosplit to make it clearer what's
being limited.
This change does not affect the values of these constants in the
default configuration. It does slightly change how
StackGuardMultiplier values other than 1 affect the constants, but
this multiplier is a pretty rough heuristic anyway.
before after
stackNosplit 800 800
_StackGuard 928 928
stackNosplit -race 1728 1600
_StackGuard -race 1856 1728
For #59670.
Change-Id: Ibe20825ebe0076bbd7b0b7501177b16c9dbcb79e
Reviewed-on: https://go-review.googlesource.com/c/go/+/486380
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We really need 3 mix steps between the data being hashed and the output.
One mix can only spread a 1 bit change to 32 bits. The second mix
can spread to all 128 bits, but the spread is not complete. A third mix
spreads out ~evenly to all 128 bits.
The amd64 version has 3 mix steps.
Fixes#59643
Change-Id: I54ad8686ca42bcffb6d0ec3779d27af682cc96e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/486616
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The gVisor team reported a regression in their checkers,
which don't set Config.GoVersion, processing files that say
//go:build go1.13 but still use 'any' (which happened in Go 1.18).
That situation should continue to work, since it worked before,
so add a special case for not knowing the GoVersion.
Change-Id: I8820d8ccbdf76d304e2c7e45f6aaa993ff3d16a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/486398
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Remove calls to Value.Resolve from Record.AddAttrs, Record.Add and Logger.With.
Handlers must resolve values themselves; document that in Handler.
Call Value.Resolve in the built-in handlers.
Updates #59292.
Change-Id: I00ba2131be0b16e3b1a22741249fd6f81c3efde1
Reviewed-on: https://go-review.googlesource.com/c/go/+/486375
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Found by running
$ go run golang.org/x/tools/go/analysis/passes/nilness/cmd/nilness@latest std
No actual bugs--other than one panic(nil)--but a
few places where error nilness was unclear.
Change-Id: Ia916ba30f46f29c1bcf928cc62280169b922463a
Reviewed-on: https://go-review.googlesource.com/c/go/+/486675
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Alan Donovan <adonovan@google.com>
The point of DialWithTimeout seems to be to test what happens when the
connection times out during handshake. However, the test wasn't
actually verifying that the connection made it into the handshake at
all. That would not only fail to test the intended behavior, but also
leak the Accept goroutine until arbitrarily later, at which point it
may call t.Error after the test t is already done.
Instead, we now:
- retry the test with a longer timeout if we didn't accept a
connection, and
- wait for the Accept goroutine to actually complete when the test
finishes.
Fixes#59646.
Change-Id: Ie56ce3297e2c183c02e67b8f6b26a71e50964558
Reviewed-on: https://go-review.googlesource.com/c/go/+/485115
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Commit-Queue: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add an AfterFunc function, which registers a function to run after
a context has been canceled.
Add support for contexts that implement an AfterFunc method, which
can be used to avoid the need to start a new goroutine watching
the Done channel when propagating cancellation signals.
Fixes#57928
Change-Id: If0b2cdcc4332961276a1ff57311338e74916259c
Reviewed-on: https://go-review.googlesource.com/c/go/+/482695
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Sameer Ajmani <sameer@golang.org>
Previously, all.bash and all.bat restored the original $PATH before
calling 'dist banner', so that it would do its job of checking whether
the user still needs to add $GOROOT/bin to their $PATH. That worked for
those scripts, but had no effect on make.bash nor make.bat.
Instead of trying to extend that logic to more scripts, change the
approach to provide dist an unmodified copy of $PATH via an internal
to dist environment variable $DIST_UNMODIFIED_PATH. The make.bash and
make.bat scripts happen to use dist env -p to modify $PATH, making it
viable to add the internal variable there instead of in each script.
It currently works by adding semicolon terminators to dist env output
so that make.bash's 'eval $(dist env -p)' works as before but is able to
export DIST_UNMODIFIED_PATH for following dist invocations to observe.
Nothing needs to be done for Windows since its 'set ENV=val' format
already has that effect.
Plan 9 doesn't use the -p flag of dist env, and checks that GOROOT/bin
is bound before /bin rather than looking at the $PATH env var like other
OSes, so it may not have this bug. I don't have easy access to Plan 9
and haven't tried to confirm.
Fixes#42563.
Change-Id: I74691931167e974a930f7589d22a48bb6b931163
Reviewed-on: https://go-review.googlesource.com/c/go/+/485896
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes#55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
An apparent typo in CL 484837 caused the test to check for ErrExist
instead of ErrNotExist when opening /dev/net/tun for read. That causes
the test to fail on platforms where /dev/net/ton does not exist,
such as on the darwin-amd64-longtest builder.
Updates #59545.
Change-Id: I9402ce0dba11ab459674e8358ae9a8b97eabc8d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/486255
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Commit-Queue: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Marking variables in erroneous variable declarations as used is
convenient for tests but doesn't necessarily hide follow-on errors
in real code: either the variable is not supposed to be declared in
the first place and then we should get an error if it is not used,
or it is there because it is intended to be used, and the we expect
an error it if is not used.
This brings types2 closer to go/types.
Change-Id: If7ee1298fc770f7ad0cefe7e968533fd50ec2343
Reviewed-on: https://go-review.googlesource.com/c/go/+/486175
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The relevant code was broken with CL 478218. Before that CL,
Checker.assignVar used to return the assigned type, or nil,
in case of failure. Checker.recordCommaOkTypes used to take
two types (not two operands), and if one of those types was
nil, it would simply not record. CL 478218, lost that (nil)
signal.
This change consistently reports an assignment check failure
by setting x.mode to invalid for initVar and assignVar and
then tests if x.mode != invalid before recording a comma-ok
expression.
Fixes#59371.
Change-Id: I193815ff3e4b43e3e510fe25bd0e72e0a6a816c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/486135
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Per the doc string, Checker.assignment must set x.mode to invalid
in case of failure.
(It may be simpler to return a bool, but the operand x may be tested
by callers several stack frames above.)
Change-Id: Ia1789b0396e8338103c0e707761c46f8d253fd31
Reviewed-on: https://go-review.googlesource.com/c/go/+/485875
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
This reapplies CL 481075, which was a reappliation of CL 478917.
This CL has been reverted twice now due to conflicts with CL 392854 /
CL 481061, which had bugs and had to be reverted.
Now this CL skips the conflicting changes to runtime/cgo/asm_ppc64x.s,
which will be merged directly into a new version of CL 392854 /
CL 481061. That way, if there are _more_ issues, this CL need not be
involved in any more reverts.
Change-Id: I2801b918faf9418dd0edff19f2a63f4d9e08896c
Reviewed-on: https://go-review.googlesource.com/c/go/+/485335
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Test cases added to debug/dwarf because that is where it matters in practice.
The new test binary line-gcc-zstd.elf built with
gcc -g -no-pie -Wl,--compress-debug-sections=zstd line[12].c
using
gcc (Debian 12.2.0-10) 12.2.0
with a development version of the GNU binutils.
Fixes#55107
Change-Id: I48507c96902e1f83a174e5647b5cc403d965b52b
Reviewed-on: https://go-review.googlesource.com/c/go/+/473256
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
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: Than McIntosh <thanm@google.com>
This package only does zstd decompression, which is starting to
be used for ELF debug sections. If we need zstd compression we
should use github.com/klauspost/compress/zstd. But for now that
is a very large package to vendor into the standard library.
For #55107
Change-Id: I60ede735357d491be653477ed419cf5f2f0d3f71
Reviewed-on: https://go-review.googlesource.com/c/go/+/473356
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
It is possible for a netpoll file to be closed and for the pollDesc
to be reused while a netpoll is running. This normally only causes
spurious wakeups, but if there is an error on the old file then the
new file can be incorrectly marked as having an error.
Fix this problem on most systems by introducing an fd sequence field
and using that as a tag in a taggedPointer. The taggedPointer is
stored in epoll or kqueue or whatever is being used. If the taggedPointer
returned by the kernel has a tag that does not match the fd
sequence field, the notification is for a closed file, and we
can ignore it. We check the tag stored in the pollDesc, and we also
check the tag stored in the pollDesc.atomicInfo.
This approach does not work on 32-bit systems where the kernel
only provides a 32-bit field to hold a user value. On those systems
we continue to use the older method without the sequence protection.
This is not ideal, but it is not an issue on Linux because the kernel
provides a 64-bit field, and it is not an issue on Windows because
there are no poller errors on Windows. It is potentially an issue
on *BSD systems, but on those systems we already call fstat in newFile
in os/file_unix.go to avoid adding non-pollable files to kqueue.
So we currently don't know of any cases that will fail.
Fixes#59545
Change-Id: I9a61e20dc39b4266a7a2978fc16446567fe683ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/484837
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Orlando Labao <orlando.labao43@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@golang.org>
This was a remaining place where we made the assumption that there is
only one workspace module. So we'd only skip the first workspace
module when running go mod verify. Instead skip over the first
MainModules.Len() modules of the buildlist, which are all the main
modules.
Fixes#54372
Change-Id: Ife687c907ae4326759c43cc35f78d429d5113b19
Reviewed-on: https://go-review.googlesource.com/c/go/+/485475
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Currently android doesn't include godebug.md in its doc folder, and
TestAll in godebugs_test.go is failing because it can't open the file.
Add a skip in case the file is missing (except for linux so we can
catch the case where we stop generating the file).
Change-Id: I37a711e49a494c33bc92bf3e31cf40471ea9d5b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/485795
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
There's a stub for gotoolchain.go for the js build tag because js/wasm
doesn't define syscall.Exec. But there are builders that are wasm but
not js, which also don't have syscall.Exec. The wasip1 GOOS is one
example. Stub out gotoolchain.go for wasip1 also.
Change-Id: I224bb385474ad9c5d3c28a83a000f450dfb43c0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/485735
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
This new TCPConn method returns whether the connection is using MPTCP or
if a fallback to TCP has been done, e.g. because the other peer doesn't
support MPTCP.
When working on the new E2E test linked to MPTCP (#56539), it looks like
the user might need to know such info to be able to do some special
actions (report, stop, etc.). This also improves the test to make sure
MPTCP has been used as expected.
Regarding the implementation, from kernel version 5.16, it is possible
to use:
getsockopt(..., SOL_MPTCP, MPTCP_INFO, ...)
and check if EOPNOTSUPP (IPv4) or ENOPROTOOPT (IPv6) is returned. If it
is, it means a fallback to TCP has been done. See this link for more
details:
https://github.com/multipath-tcp/mptcp_net-next/issues/294
Before v5.16, there is no other simple way, from the userspace, to check
if the created socket did a fallback to TCP. Netlink requests could be
done to try to find more details about a specific socket but that seems
quite a heavy machinery. Instead, only the protocol is checked on older
kernels.
The E2E test has been modified to check that the MPTCP connection didn't
do any fallback to TCP, explicitely validating the two methods
(SO_PROTOCOL and MPTCP_INFO) if it is supported by the host.
This work has been co-developed by Gregory Detal
<gregory.detal@tessares.net> and Benjamin Hesmans
<benjamin.hesmans@tessares.net>.
Fixes#59166
Change-Id: I5a313207146f71c66c349aa8588a2525179dd8b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/471140
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
A //go:debug line mentioning an unknown or retired setting
should be diagnosed as making the program invalid. Do that.
We agreed on this in the proposal but I forgot to implement it.
Change-Id: Ie69072a1682d4eeb6866c02adbbb426f608567c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/476280
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For proposal #57001, add code to reinvoke a different Go toolchain
based on $GOTOOLCHAIN. The toolchain is searched for in $PATH
first and otherwise downloaded. The download is a standard module
download, so the toolchain is validated using the checksum database
before being executed or even stored in the file system.
Followup CLs will refine the exact toolchain selection and implement
other parts of the proposal. This is only the download+reinvoke code.
For #57001.
Change-Id: I44363cbd916dac01342b1bfce6a487fe7166be4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/475955
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This reverts CL 481075 (a re-apply of previously reverted CL 478917).
Reason for revert: CL 481061 causes C TSAN failures and must be
reverted. See CL 485275. This CL depends on CL 481061.
For #59678.
Change-Id: I4bf7f43d9df1ae28e04cd4065552bcbee82ef13f
Reviewed-on: https://go-review.googlesource.com/c/go/+/485316
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This patch generalizes the code in the inliner that marks unreferenced
hidden closure functions as dead. Rather than doing the marking on the
fly (previous approach), this new approach does a single pass at the
end of inlining, which catches more dead functions.
Fixes#59638.
Updates #59404.
Updates #59547.
Change-Id: I54fd63e9e37c9123b08a3e7def7d1989919bba91
Reviewed-on: https://go-review.googlesource.com/c/go/+/484859
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Preparation for reverse type inference where there is no need
to rename all type parameters supplied to type inference when
passing generic functions as arguments to (possibly generic)
function calls.
This also leads to a better separation of concerns.
Change-Id: Id487a5c1340b743519b9053edc43f8aa99408522
Reviewed-on: https://go-review.googlesource.com/c/go/+/484655
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
The Go arm64 assembler places constants into the text section of a binary.
OpenBSD 7.3 enabled xonly by default on OpenBSD/arm64. This means that any
externally linked Go binary now segfaults. Disable execute-only when invoking
the external linker on openbsd/arm64, in order to work around this issue.
Updates #59615
Change-Id: I1a291293da3c6e4409b21873d066ea15e9bfe280
Reviewed-on: https://go-review.googlesource.com/c/go/+/484555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Aaron Bieber <deftly@gmail.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Than McIntosh <thanm@google.com>
Due to reverse type inference, we may not have an index expression when
type-checking a function instantiation. Fix a panic when the index expr
is nil.
Fixes#59639
Change-Id: Ib5de5e49cdb7b339653e4fb775bf5c5fdb3c6907
Reviewed-on: https://go-review.googlesource.com/c/go/+/484757
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
The code is using typecheck.ConvNop to convert from untyped int to
uintptr. However, that left the literal node untyped. It often does not
matter, because typecheck.EvalConst will see the OCONVNOP, and replace
the node with a new constant node.
This CL changes the code to construct the constant node directly using
typecheck.DefaultLit, so the last dependecy of typecheck.EvalConst will
go away, next CL can safely remove it from the code base.
Change-Id: Ie5a3d1ff6d3b72be7b8c43170eaa4f6cbb3206fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/484317
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 399694 added constant-fold switch early in compilation. So function:
func f() string {
switch intSize {
case 32:
return "32"
case 64:
return "64"
default:
panic("unreachable")
}
}
will be constant-fold to:
func f() string {
switch intSize {
case 64:
return "64"
}
}
When this function get inlined, there is a check whether we can delay
declaring the result parameter until the "return" statement. For the
original function, we can't delay the result, because there's more than
one return statement. However, the constant-fold one can, because
there's on one return statement in the body now. The result parameter
~R0 ends up declaring inside the switch statement scope.
Now, when walking the switch statement, it's re-written into if-else
statement. Without typecheck.EvalConst, the if condition "if 64 == 64"
is passed as-is to the ssa generation pass. Because "64 == 64" is not a
constant, the ssagen creates normal blocks for branching the results.
This confuses the liveness analysis, because ~R0 is only live inside the
if block. With typecheck.EvalConst, "64 == 64" is evaluated to "true",
so ssagen can branch the result without emitting conditional blocks.
Instead, the constant-fold can be re-written as:
switch {
case true:
// Body
}
So it does not depend on the delay results check during inlining. Adding
a test, which will fail when typecheck.EvalConst is removed, so we can
do the cleanup without breaking things.
Change-Id: I638730bb147140de84260653741431b807ff2f15
Reviewed-on: https://go-review.googlesource.com/c/go/+/484316
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Static init inliner is using typecheck.EvalConst to handle string
concatenation expressions. But static init inliner may reveal constant
expressions after substitution, and the compiler needs to evaluate those
expressions in non-constant semantic. Using typecheck.EvalConst, which
always evaluates expressions in constant semantic, is not the right
choice.
For safety, this CL fold the logic to handle string concatenation to
static init inliner, so there won't be regression in handling constant
expressions in non-constant semantic. And also, future CL can simplify
typecheck.EvalConst logic.
Updates #58293
Updates #58339Fixes#58439
Change-Id: I74068d99c245938e576afe9460cbd2b39677bbff
Reviewed-on: https://go-review.googlesource.com/c/go/+/466277
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
(This is a retry of CL 462035 which was reverted at 474976.
The only change from that CL is the aix fix SRODATA->SNOPTRDATA
at inittask.go:141)
As described here:
https://github.com/golang/go/issues/31636#issuecomment-493271830
"Find the lexically earliest package that is not initialized yet,
but has had all its dependencies initialized, initialize that package,
and repeat."
Simplify the runtime a bit, by just computing the ordering required
in the linker and giving a list to the runtime.
Update #31636Fixes#57411
RELNOTE=yes
Change-Id: I28c09451d6aa677d7394c179d23c2c02c503fc56
Reviewed-on: https://go-review.googlesource.com/c/go/+/478916
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #57001, enforce the go line as declaring the minimum required
version of Go that can compile a module.
Modules that maintain compatibility with old versions of Go
but want to make use of new features in //go:build-constrained files
will be able to do so: the //go:build constraint will be interpreted
as changing the minimum Go version for that file and will unlock
the Go features allowed in that version.
Change-Id: Ibeeb7c93ce7ea2e5187d78af0757cbfac19484a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/476279
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
For #57001, compilers and others tools will need to understand that
a different Go version can be used in different files in a program,
according to the //go:build lines in those files.
Update go/types and cmd/compile/internal/types2 to track and
use per-file Go versions. The two must be updated together because
of the files in go/types that are generated from files in types2.
The effect of the //go:build go1.N line depends on the Go version
declared in the 'go 1.M' line in go.mod. If N > M, the file gets go1.N
semantics when built with a Go 1.N or later toolchain
(when built with an earlier toolchain the //go:build line will keep
the file from being built at all).
If N < M, then in general we want the file to get go1.N semantics
as well, meaning later features are disabled. However, older Go 1.M
did not apply this kind of downgrade, so for compatibility, N < M
only has an effect when M >= 21, meaning when using semantics
from Go 1.21 or later.
For #59033.
Change-Id: I93cf07e6c687d37bd37a9461dc60cc032bafd01d
Reviewed-on: https://go-review.googlesource.com/c/go/+/476278
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
load.TestPackagesAndErrors is given an optional done func() argument.
If set, load.TestPackagesAndErrors will perform part of its work
asynchronously and call done when done. This allows go list to run
testPackagesAndErrors so that the parallelizable parts of
TestPackagesAndErrors run in parallel, making go list -e faster.
Fixes#59157
Change-Id: I11f45bbb3ea4ceda928983bcf9fd41bfdcc4fbd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/484496
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Changes the set of types supported in functions declared with the
go:wasmimport directive to only allow 32 bits and 64 bits integers
and floats, as well as unsafe.Pointer in parameters only. Both the
compiler code and the standard library are updated because the new
restrictions require modifying the use of go:wasmimport in the
syscall and runtime packages.
In preparation of enabling packages outside of the standard library
to use the go:wasmimport directive, the error messages are modified
to carry more context and use ErrorfAt instead of Fatalf to avoid
printing the compiler stack trace when a function with an invalid
signature is encountered.
Fixes#59156
Change-Id: Ied8317f8ead9c28f0297060ac35a5b5255ab49db
Reviewed-on: https://go-review.googlesource.com/c/go/+/483415
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
For #57001, compilers and others tools will need to understand that
a different Go version can be used in different files in a program,
according to the //go:build lines in those files.
Update go/parser to populate the new ast.File.GoVersion field.
This requires running the go/scanner in ParseComments mode
always and then implementing discarding of comments in the
parser instead of the scanner. The same work is done either way,
since the scanner was already preparing the comment result
and then looping. The loop has just moved into go/parser.
Also make the same changes to cmd/compile/internal/syntax,
both because they're necessary and to keep in sync with go/parser.
For #59033.
Change-Id: I7b867f5f9aaaccdca94af146b061d16d9a3fd07f
Reviewed-on: https://go-review.googlesource.com/c/go/+/476277
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This reverts commit 4c49d52439.
Reason for revert: it is trickier than expected to enforce an invariant that x.typ == Typ[Invalid] => x.mode == invalid. For example, builtins have invalid type until their call is evaluated.
I think it is better to keep this defensive code for now. My bad for suggesting this strictness. I will send a follow-up CL with a test that exercises the panic discovered inside Google, and a bit more commentary about what 'invalid' means in both contexts.
Fixes#59603
Change-Id: If291f7268e7ef7ae6cd9bb861bb9af349a729cb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/484375
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
tparamIndex returns the index of a type parameter given the type
parameter and a list of type parameters. If an index >= 0 is returned,
it is the index assigned to the type parameter (TypeParam.index), and
the index of the type parameter in the provided list of parameters.
For it to work correctly, the type parameter list must be from a single
type parameter declaration.
To allow for lists of arbitrary type parameters (from different generic
signatures), change the implementation to do a linear search. The result
is the index of the type parameter in the provided type parameter list,
which may be different from the index assigned to the type parameter.
The linear search is likely fast enough since type parameter lists tend
to be very short.
Change-Id: I913f97fa4c042abeb535ee86ca6657241a4cf796
Reviewed-on: https://go-review.googlesource.com/c/go/+/483995
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
On macOS, TMPDIR is typically a symlink, and the GOROOT for the
buildlet is in TMPDIR as well. PWD must be preserved in order for
os.Getwd (and functions based on it) to report paths that remain
relative to GOROOT, and paths relative to GOROOT are necessary in
order for filepath.Rel to report subdirectories as subdirectories
(rather than paths with long "../../…" prefixes).
Fortunately, the (*Cmd).Environ method added for #50599 makes
preserving PWD somewhat easier.
This fixes 'go test cmd/internal/moddeps' on the new
darwin-amd64-longtest builder.
For #35678.
Change-Id: Ibaa458bc9a94b44ba455519bb8da445af07fe0d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/484295
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
The list_goroot_symlink test relies on fsys.Walk (and ultimately
syscall.Lstat) conforming to POSIX pathname resolution semantics.
POSIX requires that symlinks ending in a slash be fully resolved,
but it appears that lstat in current darwin kernels does not fully
resolve the last pathname component when it is a symlink to a symlink.
For #59586.
For #35678.
Change-Id: I37526f012ba94fa1796b33109a41c3226c967d3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/484216
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Bypass: Bryan Mills <bcmills@google.com>
Due to a missing "&& !alias" check, the unified linker was treating
type aliases the same as defined types for the purpose of exporting
method bodies. The methods will get exported anyway alongside the
aliased type, so this mistake is normally harmless.
However, if multiple type aliases instantiated the same generic type
but with different type arguments, this could result in the
same (generic) method body being exported multiple times under
different symbol names. Further, because bodies aren't expected to be
exported multiple times, we were sorting them simply based on index.
And consequently, the sort wasn't total and is sensitive to the map
iteration order used while ranging over linker.bodies.
The fix is simply to add the missing "&& !alias" check, so that we
don't end up with duplicate bodies in the first place.
Thanks rsc@ for providing a minimal repro case.
Fixes#59571.
Change-Id: Iaa55968cc7110b601e2f0f9b620901c2d55f7014
Reviewed-on: https://go-review.googlesource.com/c/go/+/484155
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Fix the argument passing to runtime.newosproc0, the ABI0 argument
storing must account for the fixed frame size.
Cleanup the _rt0_ppc64le_linux_lib definition, the assembler
should not generate a stack frame. And convert it to use the
new ABI wrappers.
Change-Id: Ibc0be8b37f6522900781a19980fa018dd89ba7b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/479796
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
If a LogValue call panics, recover and return an error instead.
The error contains some stack information to make it easier to
find the problem. A number of people complained that panics
in fmt.Formatter.Format functions are hard to debug because
there is no context.
This is an example of the error text:
LogValue panicked
called from log/slog.panickingLogValue.LogValue (/usr/local/google/home/jba/repos/go/src/log/slog/value_test.go:221)
called from log/slog.Value.resolve (/usr/local/google/home/jba/repos/go/src/log/slog/value.go:465)
called from log/slog.Value.Resolve (/usr/local/google/home/jba/repos/go/src/log/slog/value.go:446)
called from log/slog.TestLogValue (/usr/local/google/home/jba/repos/go/src/log/slog/value_test.go:192)
called from testing.tRunner (/usr/local/google/home/jba/repos/go/src/testing/testing.go:1595)
(rest of stack elided)
Fixes#59141.
Change-Id: I62e6ff6968d1aa34873e955c2d606d25418a673b
Reviewed-on: https://go-review.googlesource.com/c/go/+/484097
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Replace the default Logger in some examples with a locally constructed
Logger.
Calling SetDefault changes global state that could affect other tests.
Although we could use a defer to restore the state, that clutters
the example and would not work if tests were run concurrently.
Change-Id: Ib2595c57f8e6c3e0b39b982f682ba287c2ae249d
Reviewed-on: https://go-review.googlesource.com/c/go/+/482475
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Before slog.SetDefault is called the first time, calls to slog's
default Logger invoke log's default Logger.
Originally, this was done by calling log.Output. This caused source
line information to be wrong sometimes, because log.Output requires a
call depth and the code invoking it could not know how many calls were
between it and the original logging call (slog.Info, etc.). The line
information would be right if the default handler was called directly,
but wrong if it was wrapped by another handler. The handler has the pc
of the logging call, but it couldn't give that pc to the log package.
This CL fixes the problem by adding a function in the log package
that uses the pc instead of a call depth, and making that function
available to slog.
The simplest way to add pc functionality to the log package is to add
a pc argument to Logger.output, which uses it only if it's not zero.
To make that function visible to slog without exporting it, we store
the function in a variable that lives in the new log/internal package.
Change-Id: I0bb6daebb4abc518a7ccc4e6d2f3c1093b1d0fe4
Reviewed-on: https://go-review.googlesource.com/c/go/+/482239
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
The existing error log in check doesn't report the got/want hostname
even though that can be the cause of the error. Log those as well.
While we're here, also report os.Hostname() errors.
For #59568.
Change-Id: Ia277f85eddc541f2e78d719bc731db24e4513754
Reviewed-on: https://go-review.googlesource.com/c/go/+/483915
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
In TestTransportPrefersResponseOverWriteError and TestMaxBytesHandler,
the server may respond to an incoming request without ever reading the
request body. The client's Do method will return as soon as the
server's response headers are read, but the Transport will remain
active until it notices that the server has closed the connection,
which may be arbitrarily later.
When the server has closed the connection, it will call the Close
method on the request body (if it has such a method). So we can use
that method to find out when the Transport is close enough to done for
the test to complete without interfering too much with other tests.
For #57612.
For #59526.
Change-Id: Iddc7a3b7b09429113ad76ccc1c090ebc9e1835a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/483895
Run-TryBot: Bryan Mills <bcmills@google.com>
Commit-Queue: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
We don't have a way to terminate the leaked goroutines, and we can't
wait forever for them to exit (or else we would risk timing out the
test and losing the log line describing what exactly leaked).
So we have reason to believe that they will remain leaked while we run
the next test, and we don't want the goroutines from the first leak to
generate a spurious error when the second test completes.
This also removes a racy Parallel call I added in CL 476036, which was
flagged by the race detector in the duplicate-suppression check.
(I hadn't considered the potential interaction with the leak checker.)
For #59526.
Updates #56421.
Change-Id: Ib1f759f102fb41ece114401680cd728343e58545
Reviewed-on: https://go-review.googlesource.com/c/go/+/483896
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
This CL adds support for os.File.Chdir() on Windows by implementing
syscall.Fchdir, which is internally used by Chdir.
Windows does not provide a function that sets the working directory
using a file handle, so we have to fallback to retrieving the file
handle path and then use it in SetCurrentDirectory.
Change-Id: I2ae93575e50411e5a9426ea531541958d7c9e812
Reviewed-on: https://go-review.googlesource.com/c/go/+/480135
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
We want to enable others to reproduce the exact distribution archives
we are serving on go.dev/dl. Today the code for building those
archives lives in golang.org/x/build, which is fundamentally tied to
running on the Go team build infrastructure and not easy for others to
run. This CL adds a new flag -distpack to cmd/dist, usually invoked as
make.bash -distpack, to build the distribution archives using code in
the main repository that anyone can run. Starting in Go 1.21,
the Go team build infrastructure will run this instead of its current
custom code to build those archives.
The current builds are not reproducible even given identical
infrastructure, because the archives are stamped with the current
time. It is helpful to have a timestamp in the archives indicating
when the code is from, but that time needs to be reproducible.
To ensure this, the new -distpack flag extends the VERSION file to
include a time stamp, which it uses as the modification time for all
files in the archive.
The new -distpack flag is implemented by a separate program,
cmd/distpack, instead of being in cmd/dist, so that it can be compiled
by the toolchain being distributed and not the bootstrap toolchain.
Otherwise details like the exact compression algorithms might vary
from one bootstrap toolchain to another and produce non-reproducible
builds. So there is a new 'go tool distpack', but it's omitted from
the distributions themselves, just as 'go tool dist' is.
make.bash already accepts any flags for cmd/dist, including -distpack.
make.bat is less sophisticated and looks for each known flag, so this
CL adds an update to look for -distpack. The CL also changes make.bat
to accept the idiomatic Go -flagname in addition to the non-idiomatic
(for Go) --flagname. Previously it insisted on the --flag form.
I have confirmed that using make.bash -distpack produces the
identical distribution archives for windows/amd64, linux/amd64,
darwin/amd64, and darwin/arm64 whether it is run on
windows/amd64, linux/amd64, or darwin/amd64 hosts.
For #24904.
Change-Id: Ie6d69365ee3d7294d05b4f96ffb9159b41918074
Reviewed-on: https://go-review.googlesource.com/c/go/+/470676
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Carlos Amedee <amedee@google.com>
forkAndExecInChild1 func must not acquire any locks in child, because
they might have been locked at the time of the fork. This implies to
no rescheduling, no malloc calls, and no new stack segments.
So, doing a "checkptrAlignment" is bad here, because checkptr
functions added by the instrumentation could grow the stack, which
should not be done between fork and exec calls.
Hence using a Go directive "go:nocheckptr" to forkAndExecInChild1
func,so that the compiler should not do "checkptrAlignment" when
functions marked with "go:norace".
This race detection bug was caught in go 1.21 on s390x.
Running a "./race.bash" script from "go/src" directory failed and the
bug details are provided in issue link mentioned below.
Fixes#58785
Change-Id: I254091368b0789d886acdf26f8aa8d8f5a986b24
Reviewed-on: https://go-review.googlesource.com/c/go/+/481415
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Re-run all go:generate stringer commands. This mostly adds checks
that the constant values did not change, but does add new strings
for the debug/dwarf and internal/pkgbits packages.
Change-Id: I5fc41f20da47338152c183d45d5ae65074e2fccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/483717
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
For #57001, compilers and others tools will need to understand that
a different Go version can be used in different files in a program,
according to the //go:build lines in those files.
This CL adds a GoVersion string field to ast.File, to allow exposing this
per-file Go version information.
For #59033.
Change-Id: I3931ea86c237983d152964f48dce498bcb1f06aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/476276
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
For #57001, programs need to be able to deduce the Go version
implied by a given build constraint. GoVersion determines that,
by discarding all build tags other than Go versions and computing
the minimum Go version implied by the resulting expression.
For #59033.
Change-Id: Ifb1e7af2bdbdf172f82aa490c826c9b6ca5e824b
Reviewed-on: https://go-review.googlesource.com/c/go/+/476275
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the case where a user program requests overlapped I/O directly on a
handlethat is managed by the runtime, it is possible that
runtime.netpoll will attempt to dereference a pointer with an invalid
value. This CL prevents the runtime from accessing the invalid pointer
value by adding a special key to each overlapped I/O operation that it
creates.
Fixes#58870
Co-authored-by: quimmuntal@gmail.com
Change-Id: Ib58ee757bb5555efba24c29101fc6d1a0dedd61a
Reviewed-on: https://go-review.googlesource.com/c/go/+/482495
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add support for the Read Processor ID (RDPID) instruction to the x86
assembler. This returns the current logical processor's ID in the
specified register, as a faster alternative to RDTSCP.
Fixes#56525
Change-Id: I43482e42431dfc385ce2e7f6d44b9746b0cc4548
Reviewed-on: https://go-review.googlesource.com/c/go/+/482955
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
In the language specification under "Constants" the lists matching default
types to untyped contstant types is missing an Oxford comma in the first
list. I found a number of other places in the spec and #23442 that use the
Oxford comma to support its use.
Add missing Oxford comma in Constants default type list.
Change-Id: I4562d692610334bc82452db076145d2414617a04
GitHub-Last-Rev: 8acdb60d6e
GitHub-Pull-Request: golang/go#59528
Reviewed-on: https://go-review.googlesource.com/c/go/+/483555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
It's fine to ignore errors when reading trim.txt, since it might not
exist or might be corrupted. However, if we encounter an error in
writing the file, we will end up trimming again at every cmd/go
invocation, which will cause invocations to become progressively
slower (because each command will check more and more cache files for
trimming).
Although that situation would not cause the output of any 'go' command
to be invalid, it still seems better to escalate the problem to the
user to be fixed instead of proceeding in a degraded state.
Returning an explicit error also allows TestCacheTrim to skip if the
Trim error indicates that a required operation (in this case, file
locking) is not supported by the platform or filesystem.
For #58141.
Updates #35220.
Updates #26794.
Change-Id: Iedb94bff4544fd9914f5ac779a783a116372c80f
Reviewed-on: https://go-review.googlesource.com/c/go/+/482795
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Update to use the common macros to ensure all ELFv2 callee-save registers
are saved properly when transitioning from ELFv2 to Go calling/stack
conventions. Simplify the inlined Go function call, and remove the asm
hacks which inhibited implicit stack frame management.
Change-Id: Iee118a4069962a791436c6fe19370e1929404a8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/479795
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
setPos is called for most nodes, and in a number of cases,
the position is already the same.
PositionFor is a relatively expensive call,
as it needs to "unpack" a token.Pos into a token.Position.
If we can tell that the position is the same in a cheap way,
we can then avoid calling setPos and PositionFor.
Luckily, we can get the position's offset within the file,
and it doesn't involve the relatively expensive unpacking.
name old time/op new time/op delta
PrintFile-16 4.79ms ± 1% 4.36ms ± 1% -8.88% (p=0.008 n=5+5)
name old speed new speed delta
PrintFile-16 10.8MB/s ± 1% 11.9MB/s ± 1% +9.73% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
PrintFile-16 106kB ± 1% 106kB ± 1% ~ (p=0.167 n=5+5)
name old allocs/op new allocs/op delta
PrintFile-16 2.42k ± 0% 2.42k ± 0% ~ (all equal)
This does assume that the positions of a node being printed are all
within a file, as go/token.Position.Offset is relative to each file.
This seems like a perfectly fine assumption to make right now,
as the largest node which can be printed is an *ast.File.
Change-Id: I2ae55f507ba8ba9f280898c9c8e01c994d9b2a26
Reviewed-on: https://go-review.googlesource.com/c/go/+/461739
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The function just calculates the number of needed padding bytes,
instead of actually carrying out the alignment operation. And it has
the context argument at the end of the argument list, while contexts
idiomatically come first. Indeed, this is the only case in
cmd/internal/obj where ctxt is not the only argument and does not come
first.
Fix those two nits; no functional change intended.
Suggested by Ian during review of CL 479815 (that introduces a copy of
this helper into the loong64 port).
Change-Id: Ieb221ead23282abe6e04804d537e1234c7ab21d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/483155
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
cmd/doc passes structs to go/format, but that means that comments
on fields within those structs don't look like what cmd/doc prints
when asked for a struct field directly. Tweak the field comments
so that they look the same either way.
Fixes#56592
Change-Id: I198cb7a58e3d8558406c386072c630332f91c6b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/483055
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Stop depending on DepsErrors to report errors to the user and instead
only use it and compute it in list. Instead, use Incomplete to figure
out when a package or its depencies have an error, and only if they
do, do the work of finding all those errors.
For #59157
Change-Id: Ied927f53e7b1f66fad9248b40dd11ed960b3ef91
Reviewed-on: https://go-review.googlesource.com/c/go/+/483495
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Standard inlining has a reduced maximum cost of callees (20 instead of
80) when inlining into a "big" function, to limit how much bigger we
will make an already big function.
When adding PGO hot call budget increases, we inadvertently bypassed
this "big" function restriction, allowing hot calls of up to
inlineHotMaxBudget, even into big functions.
Add the restriction back, even for hot calls. If a function is already
very large, we probably shouldn't inline even more.
A very important note here is that function "big"-ness is computed prior
to any inlining. One potential problem with PGO is that many hot calls
inline into an initially-small function and ultimately make it very
large. This CL does nothing to address that case, which would require
recomputing size after inlining.
This CL has no impact on sweet PGO benchmarks. I specifically dug into
tile38, which contained 0 hot big functions. Other benchmarks are
probably similar.
Change-Id: I3b6304eaf7738a219359d4b8bb121d68babfea8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/482157
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
And assign the error to the importing package. Before this change, for
some errors for bad imports, such as importing a vendored package with
the wrong path, we would make a dummy package for the imported package
with the error on it. Instead report the error on the importing
package where it belongs. Do so by returning an error from loadImport
and handling it on the importing package.
For #59157
Change-Id: I952e1a82af3857efc5da4fd3f8bc6be473a60cf5
Reviewed-on: https://go-review.googlesource.com/c/go/+/482877
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The LoongArch ELF psABI v2 [1] relocs are vastly simplified from the v1
which involved a stack machine for computing the reloc values, but the
details of PC-relative addressing are changed as well. Specifically, the
`pcaddu12i` instruction is substituted with the `pcalau12i`, which is
like arm64's `adrp` -- meaning the lower bits of a symbol's address now
have to be absolute and not PC-relative.
However, apart from the little bit of added complexity, the obvious
advantage is that only 1 reloc needs to be emitted for every kind of
external reloc we care about. This can mean substantial space savings
(each RELA reloc occupies 24 bytes), and no open-coded stack ops has to
remain any more.
While at it, update the preset value for the output ELF's flags to
indicate the psABI update.
Fixes#58784
[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
Change-Id: I5c13bc710eaf58293a32e930dd33feff2ef14c28
Reviewed-on: https://go-review.googlesource.com/c/go/+/455017
Run-TryBot: Ben Shi <powerman1st@163.com>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
In order to avoid a CPU exception resulting from signed overflow, the signed
division code tests if the divisor is -1 and if it is, runs fix up code to
manually compute the quotient and remainder (thus avoiding IDIV and potential
signed overflow).
However, the way that this is currently structured means that the normal code
path for the case where the divisor is not -1 results in five instructions
and two branches (CMP, JEQ, followed by sign extension, IDIV and another JMP
to skip over the fix up code).
Rework the fix up code such that the final JMP is incurred by the less likely
divisor is -1 code path, rather than more likely code path (which is already
more expensive due to IDIV). This result in a four instruction sequence
(CMP, JNE, sign extension, IDIV), with only a single branch.
Updates #59089
Change-Id: Ie8d065750a178518d7397e194920b201afeb0530
Reviewed-on: https://go-review.googlesource.com/c/go/+/482658
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The same switch statement handles code generation for signed division of
words, double words and quad words. Rather than using multiple switch
statements to select the appropriate instructions, determine all of the
correctly sized operands up front, then use them as needed.
Updates #59089
Change-Id: I2b7567c8e0ecb9904c37607332538c95b0521dca
Reviewed-on: https://go-review.googlesource.com/c/go/+/482657
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Use the type of the store for the byteswap, not the type of the
store's value argument.
Normally when we're storing a 16-bit value, the value being stored is
also typed as 16 bits. But sometimes it is typed as something smaller,
usually because it is the result of an upcast from a smaller value,
and that upcast needs no instructions.
If the type of the store's arg is thinner than the type being stored,
and the byteswap'd value uses that thinner type, and the byteswap'd
value needs to be spilled & restored, that spill/restore happens using
the thinner type, which causes us to lose some of the top bits of the
value.
Fixes#59367
Change-Id: If6ce1e8a76f18bf8e9d79871b6caa438bc3cce4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/481395
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
HashDebugPos function/method included a parameter that was always
the same, and a variable in the same package as the hashdebug code.
So remove it.
(I wrote that code, there was no reason for it to be that way).
Also corrects a stale comment in the loopvar code.
Change-Id: Id3da69cfe6dadeb31d5de62fb76d15103a5d6152
Reviewed-on: https://go-review.googlesource.com/c/go/+/482816
Run-TryBot: 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>
The ELF ABI just requires that the address and the offset of a
segment are congruent modulo the alignment, but does not require
the start address to be aligned. While usually the segment's
start address is aligned, apparently the zig linker generates
binary with unaligned address.
At the run time, the memory mapping that contains the segment
starts at an aligned address (rounding down). Use the aligned
address for the load address, which matches the mapping.
Apparently this is what the pprof library expects.
Fixes#59466.
Change-Id: Ife78909b20b7bc975ac4c76f2c5f5db325ddec9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/483035
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
The loong64 PCALIGN directive works with PCs relative to beginning of
functions. So if the function alignment is less than that requested by
PCALIGN, the following code may in fact not be aligned as such, leading
to unexpected performance.
The current function alignment on loong64 is 8 bytes, which seems to
stem from mips64 or riscv64. In order to make performance more
predictable on loong64, it is raised to 16 bytes to ensure that at
least `PCALIGN $16` works.
As alignment of loops written in Go is yet to be tackled, and the
codegen is not otherwise touched, benchmark numbers for this change are
not going to be meaningful, and not included.
Change-Id: I2120ef3746ce067e274920c82091810073bfa3be
Reviewed-on: https://go-review.googlesource.com/c/go/+/481936
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: WANG Xuerui <git@xen0n.name>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Allow writing `PCALIGN $imm` where imm is a power-of-2 between 8 and
2048 (inclusive), for ensuring that the following instruction is
placed at an imm-byte boundary relative to the beginning of the
function. If the PC is not sufficiently aligned, NOOPs will be
inserted to make it so, otherwise the directive will do nothing.
This could be useful for both asm performance hand-tuning, and future
scenarios where a certain bigger alignment might be required.
Change-Id: Iad6244669a3d5adea88eceb0dc7be1af4f0d4fc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/479815
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: WANG Xuerui <git@xen0n.name>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Like https://go.dev/cl/481376 did for encoding/gob,
but now for encoding/xml, which had very similar code.
One minor difference is that encoding/xml now needs a SetLen before the
call to Index, as otherwise we index just past the length.
Still, calling Grow and SetLen is easier to understand,
and avoids needing to make a new zero value.
goos: linux
goarch: amd64
pkg: encoding/xml
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
Unmarshal-8 6.904µ ± 1% 6.980µ ± 1% +1.10% (p=0.009 n=6)
│ old │ new │
│ B/op │ B/op vs base │
Unmarshal-8 7.656Ki ± 0% 7.586Ki ± 0% -0.92% (p=0.002 n=6)
│ old │ new │
│ allocs/op │ allocs/op vs base │
Unmarshal-8 188.0 ± 0% 185.0 ± 0% -1.60% (p=0.002 n=6)
Change-Id: Id83feb467a9c59c80c7936aa892780aae7e8b809
Reviewed-on: https://go-review.googlesource.com/c/go/+/483135
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 440035 added rewrite rules to simplify "costly" LEA
instructions, but the types in the rewrites were wrong and
the code would go bad if the wrong-typed register was spilled.
CL 482536 attempted to fix this by correcting the type in the
rewrite, but that "fix" broke something on windows-amd64-race.
Instead / for-now, remove the offending rewrite rules.
Updates #21735.
Fixes#59432.
Change-Id: I0497c42db414f2055e1378e0a53e2bceee9cd5d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/482820
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
After performing a round trip on a connection, the connection is
usually returned to the idle connection pool. If the write of the
request did not complete successfully, the connection is not
returned.
It is possible for the response to be read before the write
goroutine has finished signalling that its write has completed.
To allow for this, the check to see if the write completed successfully
waits for 50ms for the write goroutine to report the result of the
write.
See comments in persistConn.wroteRequest for more details.
On a slow builder, it is possible for the write goroutine to take
longer than 50ms to report the status of its write, leading to test
flakiness when successive requests unexpectedly use different connections.
Set the timeout for waiting for the writer to an effectively
infinite duration in tests.
Fixes#51147Fixes#56275Fixes#56419Fixes#56577Fixes#57375Fixes#57417Fixes#57476Fixes#57604Fixes#57605
Change-Id: I5e92ffd66b676f3f976d8832c0910f27456a6991
Reviewed-on: https://go-review.googlesource.com/c/go/+/483116
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis since fixed in CL 482355.]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I1f4fc96c71609c8feb59fecdb92b69ba7e3b5b41
Reviewed-on: https://go-review.googlesource.com/c/go/+/482356
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When a closure is inlined, it may contain other hidden closures, which
the inliner will duplicate, rendering the original nested closures as
unreachable. Because they are unreachable, they don't get processed in
escape analysis, meaning that go/defer statements don't get rewritten,
which can then in turn trigger errors in walk. This patch looks for
nested hidden closures and marks them as dead, so that they can be
skipped later on in the compilation flow. NB: if during escape
analysis we rediscover a hidden closure (due to an explicit reference)
that was previously marked dead, revive it at that point.
Fixes#59404.
Change-Id: I76db1e9cf1ee38bd1147aeae823f916dbbbf081b
Reviewed-on: https://go-review.googlesource.com/c/go/+/482355
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
PCrelative trampolines have no dependence on the TOC pointer or build
mode, thus they are preferable to use when supported.
This is a step towards eliminating the need to use and maintain the
TOC pointer in R2 when PCrel is supported.
Change-Id: I1b1a7e16831cfd6732b31f7fad8df2a7c88c8f84
Reviewed-on: https://go-review.googlesource.com/c/go/+/461599
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Currently, the prove pass can get knowledge from some specific logic
operators only before the CFG is explored, which means that the bounds
information of the branch will be ignored.
This CL updates the facts table by the logic operators in every
branch. Combined with the branch information, this will be helpful for
BCE in some circumstances.
Fixes#57243
Change-Id: I0bd164f1b47804ccfc37879abe9788740b016fd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/419555
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The test file has a C declaration which doesn't match the actual
definition. Remove it and include "_cgo_export.h" to have the
right declaration.
Change-Id: Iddf6d8883ee0e439147c7027029dd3e352ef090d
Reviewed-on: https://go-review.googlesource.com/c/go/+/482975
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
A test flake in #59447 seems to indicate that this test got stuck
waiting for the test handler to close the readc channel.
If the handler returns early due to an unexpected error, it might
fail to close this channel. Add a second channel to act as a
signal that the handler has given up and the test should stop.
This won't fix whatever happened in the flake, but might help
us debug it if it happens again.
For #59447
Change-Id: I05d84c6176aa938887d93126a6f3bb4dc941c90d
Reviewed-on: https://go-review.googlesource.com/c/go/+/482935
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
This setting appears to be needed to avoid “Filename too long” errors
when downloading modules from repos with long branch names,
particularly if the path to the module cache is already fairly long
(as may be the case in CI systems and in tests of cmd/go itself).
Change-Id: I3aa89ea872b29eb0460c8a8afc94f182a68982fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/482819
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The compiler disallows line and column numbers > (1<<30)
(cmd/compiler/internal/syntax.PosMax).
Set the go/scanner limit to the same rather than off by one.
For #59180
Change-Id: Ibf9e0e6826d6f6230b0d492543b7e906298a0524
Reviewed-on: https://go-review.googlesource.com/c/go/+/482595
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
ServeFile and FileServer will respond to methods such as DELETE by
serving the file contents. This is surprising, but we don't want to
change it without some consideration.
Add tests covering the current behavior.
For #59470
Change-Id: Ib6a2594c5b2b7f380149fc1628f7204b308161e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/482876
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fix two long tests that fail in the builders we're trying out:
- TestQueryImport was failing with:
open /nonexist-gopath/pkg/sumdb/sum.golang.org/latest: no such file or directory
which eventually turns out to be because it couldn't create
/nonexist-gopath because it wasn't running as root. The test already
uses a temporary GOPATH, but missed overriding a configuration
variable set at init time.
- test_flags fails if the working directory has /x/ in it, which it now
happens to.
Change-Id: Ideef0f318157b42987539e3a20f9fba6a3d3bdd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/480255
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The goal here is to enable a search that will locate all the instances
of a failure, not just the first one. This helps with searches for
loopvar-change breakage, FP differences from fused-multiply-add, and
allows certain semantics queries that can be implemented as compiler
changes (for example, where does integer overflow routinely occur?)
Change-Id: Ic28f1695d47e421c2089d1f3f7c4b40c56db970f
Reviewed-on: https://go-review.googlesource.com/c/go/+/481195
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The wrong type causes the wrong width spill, which corrupts
the value. I tried to write a test for this and did not
succeed, but was able (using gossahash and ssa.html) to
isolate to exact change and spill.
Fixes#59432.
Change-Id: I85ad82c9f8fed7674c69d6a2b0a62e111f690454
Reviewed-on: https://go-review.googlesource.com/c/go/+/482536
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently pages may linger in an idle P's page cache, hiding the memory
from the scavenger precisely when it's useful to return memory to the OS
and reduce the application's footprint.
Change-Id: I49fbcd806b6c66991d1ca87949f76a9f06708e70
Reviewed-on: https://go-review.googlesource.com/c/go/+/453622
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently the memory limit is left uninitialized before gcinit, and
allocations may happen. The result is that the span allocation path
might try to scavenge memory unnecessarily. Prevent this by setting the
memory limit up early to its default value.
Change-Id: I886d9a8fa645861e4f88e0d54af793418426f520
Reviewed-on: https://go-review.googlesource.com/c/go/+/450736
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
When taking over the goroutine stack in the panic or preemption signal
handlers on arm64, the frame pointer should be saved on the stack (like
the link register) so that frame-pointer unwinding from a panic stack
works properly. Otherwise, tests like TestStackWrapperStackPanic will
fail with the frame pointer check in adjustframe (enabled with
debugCheckBP) when checking the sigpanic frame.
Updates #39524, #58432
Change-Id: I8b89e6fc4877af29b1b81e55e591e6398159855c
Reviewed-on: https://go-review.googlesource.com/c/go/+/481635
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Nick Ripley <nick.ripley@datadoghq.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Tests in package context cannot depend directly on package testing due to an import cycle.
We resolved this by having test functions in package context_test (x_test.go) forward to
test functions in package context (context_test.go). This is fragile, since it's easy
to add a test to context_test.go and forget to add the forwarding function, and tests
written in this way cannot easily use testing package features like t.Run for subtests.
It turns out that only four test functions actually use unexported members of package
context. This CL moves all except those four to x_test.go and makes them regular tests.
It also updates TestCause to use t.Run and t.Parallel to parallelize its test cases.
It also adds documentation indicating when tests should be added to each file.
Change-Id: Ic60bae32a7a44e07831b5388c9af219d53ba9af3
Reviewed-on: https://go-review.googlesource.com/c/go/+/480375
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Sameer Ajmani <sameer@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
The posix_fallocate syscall returns the result in r1 rather than in
errno:
> If successful, posix_fallocate() returns zero. It returns an error on failure, without
> setting errno.
Source: https://man.freebsd.org/cgi/man.cgi?query=posix_fallocate&sektion=2&n=1
Adjust the PosixFallocate wrappers on freebsd to account for that.
Also, CL 479715 used the same syscall wrapper for 386 and arm. However,
on arm the syscall argument order is different. The wrapper was
generated using mksyscall.go from the golang.org/x/sys/unix package,
adjusting the r1 check correspondingly.
Fixes#59352
Change-Id: I9a4e8e4546237010bc5e730c4988a2a476264cf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/481621
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Yuval Pavel Zholkover <paulzhol@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Since the first client connection is explicitly closed before making
the second request, we cannot in general assume that the second
request uses a different port (it is equally valid to open the new
connection on the same port as the old one that was closed).
Fixes#59438.
Change-Id: I52d5fe493bd8b1b49270d3996d2019d38d375ce9
Reviewed-on: https://go-review.googlesource.com/c/go/+/482175
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Instead, do the cycle checking in recompileForTest once the test
variant packages have been poked in the right places in the dependency
tree(graph?).
(Pair programming with bcmills@.)
For #59157.
Change-Id: I0c644cb9f2c0dac3a5b0189e2aa0eef083c669f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/482237
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Fix a regression caused by CL 463835. Unlike most platforms, solaris and
illumos don't use a libc_read_trampoline, so we need to skip one frame
less when using frame pointer unwinding in traceGoSysCall.
The solution is a bit hacky, so it might make sense to implement
gp.syscallbp if this causes more test failures in the future.
Fixes#59350
Change-Id: I0f0b08f36efe8a492eb4a535e752c03636857057
Reviewed-on: https://go-review.googlesource.com/c/go/+/481336
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
ECMAScript 6 introduced template literals[0][1] which are delimited with
backticks. These need to be escaped in a similar fashion to the
delimiters for other string literals. Additionally template literals can
contain special syntax for string interpolation.
There is no clear way to allow safe insertion of actions within JS
template literals, as handling (JS) string interpolation inside of these
literals is rather complex. As such we've chosen to simply disallow
template actions within these template literals.
A new error code is added for this parsing failure case, errJsTmplLit,
but it is unexported as it is not backwards compatible with other minor
release versions to introduce an API change in a minor release. We will
export this code in the next major release.
The previous behavior (with the cavet that backticks are now escaped
properly) can be re-enabled with GODEBUG=jstmpllitinterp=1.
This change subsumes CL471455.
Thanks to Sohom Datta, Manipal Institute of Technology, for reporting
this issue.
Fixes CVE-2023-24538
Fixes#59234
[0] https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-template-literals
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802457
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Change-Id: Ia221fefdb273bd0f066dffc2abcf2a616801d2f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/482079
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
The parsed forms of MIME headers and multipart forms can consume
substantially more memory than the size of the input data.
A malicious input containing a very large number of headers or
form parts can cause excessively large memory allocations.
Set limits on the size of MIME data:
Reader.NextPart and Reader.NextRawPart limit the the number
of headers in a part to 10000.
Reader.ReadForm limits the total number of headers in all
FileHeaders to 10000.
Both of these limits may be set with with
GODEBUG=multipartmaxheaders=<values>.
Reader.ReadForm limits the number of parts in a form to 1000.
This limit may be set with GODEBUG=multipartmaxparts=<value>.
Thanks for Jakob Ackermann (@das7pad) for reporting this issue.
For CVE-2023-24536
For #59153
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802455
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Change-Id: I08dd297bd75724aade4b0bd6a7d19aeca5bbf99f
Reviewed-on: https://go-review.googlesource.com/c/go/+/482077
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
A parsed MIME header is a map[string][]string. In the common case,
a header contains many one-element []string slices. To avoid
allocating a separate slice for each key, ReadMIMEHeader looks
ahead in the input to predict the number of keys that will be
parsed, and allocates a single []string of that length.
The individual slices are then allocated out of the larger one.
The prediction of the number of header keys was done by counting
newlines in the input buffer, which does not take into account
header continuation lines (where a header key/value spans multiple
lines) or the end of the header block and the start of the body.
This could lead to a substantial amount of overallocation, for
example when the body consists of nothing but a large block of
newlines.
Fix header key count prediction to take into account the end of
the headers (indicated by a blank line) and continuation lines
(starting with whitespace).
Thanks to Jakob Ackermann (@das7pad) for reporting this issue.
For #58975
Fixes CVE-2023-24534
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802452
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Change-Id: Iacc1c2b5ea6509529845a972414199f988ede1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/481994
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Growing by one is a simpler, and often cheaper,
operation compared to appending one (newly created) zero value.
The method was introduced in Go 1.20.
growSlice in dec_helpers.go is left alone,
as it grows using the builtin append instead of reflect.Append.
No noticeable performance difference on any of our benchmarks,
as this code only runs for slices large enough to not fit in
saferio.SliceCap, and none of our benchmarks use data that large.
goos: linux
goarch: amd64
pkg: encoding/gob
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
DecodeBytesSlice-8 11.37µ ± 1% 11.46µ ± 4% ~ (p=0.315 n=10)
DecodeInterfaceSlice-8 96.49µ ± 1% 95.75µ ± 1% ~ (p=0.436 n=10)
geomean 33.12µ 33.12µ +0.01%
│ old │ new │
│ B/op │ B/op vs base │
DecodeBytesSlice-8 22.39Ki ± 0% 22.39Ki ± 0% ~ (p=1.000 n=10)
DecodeInterfaceSlice-8 80.25Ki ± 0% 80.25Ki ± 0% ~ (p=0.650 n=10)
geomean 42.39Ki 42.39Ki +0.00%
│ old │ new │
│ allocs/op │ allocs/op vs base │
DecodeBytesSlice-8 169.0 ± 0% 169.0 ± 0% ~ (p=1.000 n=10) ¹
DecodeInterfaceSlice-8 3.178k ± 0% 3.178k ± 0% ~ (p=1.000 n=10) ¹
geomean 732.9 732.9 +0.00%
Change-Id: I468aebf4ae6f197a1fd35f6fee809ca591c1788f
Reviewed-on: https://go-review.googlesource.com/c/go/+/481376
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Add new helper macros to further simplify the transition from
the host's ABI to Go. Fortunately the same one should work for
all PPC64 targets.
Update the other site which uses these wrappers to further
consolidate. Also, update the call to runtime.sigtrampgo to
call the ABIInternal version directly.
Also, update the SAVE/RESTORE_VR macros to accept R0.
Change-Id: I0046176029e1e1b25838688e4b7bf57805b01bd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/476297
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Skip one of the testpoints that verifies inlining, since it
no longer passes as a result of reverting CL 479095. Once we
roll forward with a new version of CL 479095 we can re-enable
this testpoint.
Change-Id: I41f6fb3fce78f31e60c5f0ed2856be0e66865149
Reviewed-on: https://go-review.googlesource.com/c/go/+/481755
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This reapplies CL 392854, with the followup fixes in CL 479255,
CL 479915, and CL 481057 incorporated.
CL 392854, by doujiang24 <doujiang24@gmail.com>, speed up C to Go
calls by binding the M to the C thread. See below for its
description.
CL 479255 is a followup fix for a small bug in ARM assembly code.
CL 479915 is another followup fix to address C to Go calls after
the C code uses some stack, but that CL is also buggy.
CL 481057, by Michael Knyszek, is a followup fix for a memory leak
bug of CL 479915.
[Original CL 392854 description]
In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls.
So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call.
Instead, we only dropm while the C thread exits, so the extra M won't leak.
When invoking a Go function from C:
Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor.
And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits.
When returning back to C:
Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C.
This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows.
This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread.
For the newly added BenchmarkCGoInCThread, some benchmark results:
1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
[CL 479915 description]
Currently, when C calls into Go the first time, we grab an M
using needm, which sets m.g0's stack bounds using the SP. We don't
know how big the stack is, so we simply assume 32K. Previously,
when the Go function returns to C, we drop the M, and the next
time C calls into Go, we put a new stack bound on the g0 based on
the current SP. After CL 392854, we don't drop the M, and the next
time C calls into Go, we reuse the same g0, without recomputing
the stack bounds. If the C code uses quite a bit of stack space
before calling into Go, the SP may be well below the 32K stack
bound we assumed, so the runtime thinks the g0 stack overflows.
This CL makes needm get a more accurate stack bound from
pthread. (In some platforms this may still be a guess as we don't
know exactly where we are in the C stack), but it is probably
better than simply assuming 32K.
Fixes#51676.
Fixes#59294.
Change-Id: I9bf1400106d5c08ce621d2ed1df3a2d9e3f55494
Reviewed-on: https://go-review.googlesource.com/c/go/+/481061
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: DeJiang Zhu (doujiang) <doujiang24@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Casting to a *uintptr is not ok if there isn't at least 8 bytes of
data backing that pointer (on 64-bit archs).
So although we end up making a slice of 0 length with that pointer,
the cast itself doesn't know that.
Instead, bail early if the result is going to be 0 length.
Fixes#59334
Change-Id: Id3c0e09d341d838835c0382cccfb0f71dc3dc7e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/480575
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
There are many tests in internal/gcimporter that are skipped on
Windows because they build a test program that needs the -D flag
when invoking the Go compiler.
This flag is already passed since CL 442303, so there is no need to
skip those tests.
Change-Id: I877e670194048bda9a52ad2568650cf33eacfb5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/480415
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This adds the three functions from #56102 to the sync package. These
provide a convenient API for the most common uses of sync.Once.
The performance of these is comparable to direct use of sync.Once:
$ go test -run ^$ -bench OnceFunc\|OnceVal -count 20 | benchstat -row .name -col /v
goos: linux
goarch: amd64
pkg: sync
cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
│ Once │ Global │ Local │
│ sec/op │ sec/op vs base │ sec/op vs base │
OnceFunc 1.3500n ± 6% 2.7030n ± 1% +100.22% (p=0.000 n=20) 0.3935n ± 0% -70.86% (p=0.000 n=20)
OnceValue 1.3155n ± 0% 2.7460n ± 1% +108.74% (p=0.000 n=20) 0.5478n ± 1% -58.35% (p=0.000 n=20)
The "Once" column represents the baseline of how code would typically
express these patterns using sync.Once. "Global" binds the closure
returned by OnceFunc/OnceValue to global, which is how I expect these
to be used most of the time. Currently, this defeats some inlining
opportunities, which roughly doubles the cost over sync.Once; however,
it's still *extremely* fast. Finally, "Local" binds the returned
closure to a local variable. This unlocks several levels of inlining
and represents pretty much the best possible case for these APIs, but
is also unlikely to happen in practice. In principle the compiler
could recognize that the global in the "Global" case is initialized in
place and never mutated and do the same optimizations it does in the
"Local" case, but it currently does not.
Fixes#56102
Change-Id: If7355eccd7c8de7288d89a4282ff15ab1469e420
Reviewed-on: https://go-review.googlesource.com/c/go/+/451356
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Caleb Spare <cespare@gmail.com>
Auto-Submit: Austin Clements <austin@google.com>
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Change-Id: Ie9e38104fed5689a94c368288653fd7cb4b7a35e
Reviewed-on: https://go-review.googlesource.com/c/go/+/479095
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
For f()() call, the compiler rewrite it roughly to:
autotmp := f()
autotmp()
However, if f() were inlined, escape analysis will confuse about the
lifetime of autotmp, leading to bad escaping decision.
This CL fixes this issue by rewriting f()() to:
var autotmp
autotmp = f()
autotmp()
This problem also happens with Unified IR, until CL 421821 land.
Fixes#57434
Change-Id: I159a7e4c93bbc172f0eae60e7d40fc64ba70b236
Reviewed-on: https://go-review.googlesource.com/c/go/+/459295
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
There is currently no support for GOARCH=loong32, so the Optab.family
field is unused so far. Remove it to simplify the optab; the loong
assembler backend would likely already be overhauled into a sufficiently
different shape by the time we start to care for loong32, that the data
we have today would be useless anyway.
While at it, add a operand class slot for the 3rd source operand
(support for which will arrive in later commits), and rename the other
operand class fields to be self-documenting. The changes are being
merged into this patch for sake of reducing code churn.
Change-Id: Icf0988e34ff1c0f762c8e0708cfcef2e7954760c
Reviewed-on: https://go-review.googlesource.com/c/go/+/477715
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Run-TryBot: Ben Shi <powerman1st@163.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Wayne Zuo <wdvxdr@golangcn.org>
LoongArch (except for the extremely reduced LA32 Primary subset) has
dedicated beqz/bnez instructions as alternative encodings for beq/bne
with one of the source registers being R0, that allow the offset field
to occupy 5 more bits, giving 21 bits in total (equal to the FP
branches). Make use of them instead of beq/bne if one source operand is
omitted in asm, or if one of the registers being compared is R0.
Multiple go1 benchmark runs indicate the change is not perf-sensitive.
Change-Id: If6267623c82092e81d75578091fb4e013658b9f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/478377
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Run-TryBot: Ben Shi <powerman1st@163.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Wayne Zuo <wdvxdr@golangcn.org>
Currently, when C calls into Go the first time, we grab an M
using needm, which sets m.g0's stack bounds using the SP. We don't
know how big the stack is, so we simply assume 32K. Previously,
when the Go function returns to C, we drop the M, and the next
time C calls into Go, we put a new stack bound on the g0 based on
the current SP. After CL 392854, we don't drop the M, and the next
time C calls into Go, we reuse the same g0, without recomputing
the stack bounds. If the C code uses quite a bit of stack space
before calling into Go, the SP may be well below the 32K stack
bound we assumed, so the runtime thinks the g0 stack overflows.
This CL makes needm get a more accurate stack bound from
pthread. (In some platforms this may still be a guess as we don't
know exactly where we are in the C stack), but it is probably
better than simply assuming 32K.
For #59294.
Change-Id: Ie52a8f931e0648d8753e4c1dbe45468b8748b527
Reviewed-on: https://go-review.googlesource.com/c/go/+/479915
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Introduce a new m.incgocallback field that is true while C code calls
into Go code. Use it in the tracer in order to fallback to the default
unwinder instead of frame pointer unwinding for this scenario. The
existing fields (incgo, ncgo) were not sufficient to detect the case
where a thread created in C calls into Go code.
Motivation:
1. Take advantage of a cgo symbolizer, if registered, to unwind through
C stacks without frame pointers.
2. Reduce the chance of crashes. It seems unsafe to follow frame
pointers when there could be C code that was compiled without frame
pointers.
Removing the curgp.m.incgocallback check in traceStackID shows the
following minor differences between frame pointer unwinding and the
default unwinder when there is no cgo symbolizer involved.
trace_test.go:60: "goCalledFromCThread": got stack:
main.goCalledFromCThread
/src/runtime/testdata/testprogcgo/trace.go:58
_cgoexp_45c15a3efb3a_goCalledFromCThread
_cgo_gotypes.go:694
runtime.cgocallbackg1
/src/runtime/cgocall.go:318
runtime.cgocallbackg
/src/runtime/cgocall.go:236
runtime.cgocallback
/src/runtime/asm_amd64.s:998
crosscall2
/src/runtime/cgo/asm_amd64.s:30
want stack:
main.goCalledFromCThread
/src/runtime/testdata/testprogcgo/trace.go:58
_cgoexp_45c15a3efb3a_goCalledFromCThread
_cgo_gotypes.go:694
runtime.cgocallbackg1
/src/runtime/cgocall.go:318
runtime.cgocallbackg
/src/runtime/cgocall.go:236
runtime.cgocallback
/src/runtime/asm_amd64.s:998
trace_test.go:60: "goCalledFromC": got stack:
main.goCalledFromC
/src/runtime/testdata/testprogcgo/trace.go:51
_cgoexp_45c15a3efb3a_goCalledFromC
_cgo_gotypes.go:687
runtime.cgocallbackg1
/src/runtime/cgocall.go:318
runtime.cgocallbackg
/src/runtime/cgocall.go:236
runtime.cgocallback
/src/runtime/asm_amd64.s:998
crosscall2
/src/runtime/cgo/asm_amd64.s:30
runtime.asmcgocall
/src/runtime/asm_amd64.s:848
main._Cfunc_cCalledFromGo
_cgo_gotypes.go:263
main.goCalledFromGo
/src/runtime/testdata/testprogcgo/trace.go:46
main.Trace
/src/runtime/testdata/testprogcgo/trace.go:37
main.main
/src/runtime/testdata/testprogcgo/main.go:34
want stack:
main.goCalledFromC
/src/runtime/testdata/testprogcgo/trace.go:51
_cgoexp_45c15a3efb3a_goCalledFromC
_cgo_gotypes.go:687
runtime.cgocallbackg1
/src/runtime/cgocall.go:318
runtime.cgocallbackg
/src/runtime/cgocall.go:236
runtime.cgocallback
/src/runtime/asm_amd64.s:998
runtime.systemstack_switch
/src/runtime/asm_amd64.s:463
runtime.cgocall
/src/runtime/cgocall.go:168
main._Cfunc_cCalledFromGo
_cgo_gotypes.go:263
main.goCalledFromGo
/src/runtime/testdata/testprogcgo/trace.go:46
main.Trace
/src/runtime/testdata/testprogcgo/trace.go:37
main.main
/src/runtime/testdata/testprogcgo/main.go:34
For #16638
Change-Id: I95fa27a3170c5abd923afc6eadab4eae777ced31
Reviewed-on: https://go-review.googlesource.com/c/go/+/474916
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Change tracer to use frame pointer unwinding by default on amd64. The
expansion of inline frames is delayed until the stack table is dumped at
the end of the trace. This requires storing the skip argument in the
stack table, which now resides in pcBuf[0]. For stacks that are not
produced by traceStackID (e.g. CPU samples), a logicalStackSentinel
value in pcBuf[0] indicates that no inline expansion is needed.
Add new GODEBUG=tracefpunwindoff=1 option to use the old unwinder if
needed.
Benchmarks show a considerable decrease in CPU overhead when using frame
pointer unwinding for trace events:
GODEBUG=tracefpunwindoff=1 ../bin/go test -run '^$' -bench '.+PingPong' -count 20 -v -trace /dev/null ./runtime | tee tracefpunwindoff1.txt
GODEBUG=tracefpunwindoff=0 ../bin/go test -run '^$' -bench '.+PingPong' -count 20 -v -trace /dev/null ./runtime | tee tracefpunwindoff0.txt
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz
│ tracefpunwindoff1.txt │ tracefpunwindoff0.txt │
│ sec/op │ sec/op vs base │
PingPongHog-32 3782.5n ± 0% 740.7n ± 2% -80.42% (p=0.000 n=20)
For #16638
Change-Id: I2928a2fcd8779a31c45ce0f2fbcc0179641190bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/463835
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This commit addresses a regression caused by commit
43f911b0b6 (CL 472195) which led to frame
pointer cycles, causing frame pointer unwinders (refer to CL 463835) to
encounter repetitive stack frames.
The issue occurs when mcall invokes fn on g0's stack. fn is expected not
to return but to continue g's execution through gogo(&g.sched). To
achieve this, g.sched must hold the sp, pc, and bp of mcall's caller. CL
472195 mistakenly altered g.sched.bp to store mcall's own bp, causing
gogo to resume execution with a bp value that points downwards into the
now non-existent mcall frame. This results in the next function call
executed by mcall's callee pushing a bp that points to itself on the
stack, creating a pointer loop.
Fix this by dereferencing bp before storing it in g.sched.bp to
reinstate the correct behavior. Although this problem could potentially
be resolved by reverting the mcall-related changes from CL 472195, doing
so would hide mcall's caller frame from async frame pointer unwinders
like Linux perf when unwinding during fn's execution.
Currently, there is no test coverage for frame pointers to validate
these changes. However, runtime/trace.TestTraceSymbolize at CL 463835
will add basic test coverage and can be used to validate this change.
Change-Id: Iad3c42908eeb1b0009fcb839d7fcfffe53d13326
Reviewed-on: https://go-review.googlesource.com/c/go/+/476235
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
The comment justifies exporting GOROOT by saying the api test needs it,
which was relevant back when it was added in CL 99870043, but isn't true
by now.
As of Go 1.8, GOPATH can be unset (https://go.dev/doc/go1.8#gopath).
At some point it also became okay to leave GOROOT unset, at least
whenever one is looking to use the default GOROOT tree of the go command
being executed and not intentionally changing it to a custom directory.
It's also not there in the .bat and .rc variants of this script.
Drop it.
Change-Id: Ibcb386c560523fcfbfec8020f90692dcfa5aa686
Reviewed-on: https://go-review.googlesource.com/c/go/+/480376
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
This adds a simple test validating MPTCP Sock for Linux implementation:
- A Listener is created with MPTCP support, accepting new connections in
a new thread.
- A Dialer with MPTCP support connects to this new Listener
- On both sides, MPTCP should be used. Note that at this point, we
cannot check if a fallback to TCP has been done nor if the correct
protocol is being used.
Technically, a localServer from mockserver_test.go is used, similar to
TestIPv6LinkLocalUnicastTCP from tcpsock_test.go. Here with MPTCP, the
Listen step is done manually to force using MPTCP and a post step is
done to verify extra status after the Accept. More checks are going to
be done in the future.
Please note that the test is skipped if the kernel doesn't allow the
creation of an MPTCP socket at all when starting the test.
The test can be executed with this command:
$ ../bin/go test -v net -run "^TestMultiPathTCP$"
The "-race" option has also been checked.
This work has been co-developped by Benjamin Hesmans
<benjamin.hesmans@tessares.net> and Gregory Detal
<gregory.detal@tessares.net>.
Fixes#56539
Change-Id: I4b6b39e9175a20f98497b5ea56934e242da06194
Reviewed-on: https://go-review.googlesource.com/c/go/+/471141
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Specific MPTCP errors could happen but only one is detectable: if
ENOPROTOOPT errno is returned, it likely means MPTCP has been disable
via this sysctl knob: net.mptcp.enabled.
But because MPTCP could be blocked by the administrator using different
techniques (SELinux, etc.) making the socket creation returning other
errors, it looks better to always retry to create a "plain" TCP socket
when any errors are returned.
This work has been co-developed by Gregory Detal
<gregory.detal@tessares.net>.
Updates #56539
Change-Id: I94fb8448dae351e1d3135b4f182570979c6b36d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/471138
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
fieldType is a struct with only a string and an integer,
so its size will barely be three times that of a pointer.
The indirection doesn't save us any memory or append/grow cost,
but it does cause a significant amount of allocations at init time.
goos: linux
goarch: amd64
pkg: encoding/gob
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
EndToEndPipe-16 730.9n ± 5% 741.6n ± 5% ~ (p=0.529 n=10)
EncodingGob 173.7µ ± 0% 171.1µ ± 0% -1.46% (p=0.000 n=10)
geomean 11.27µ 11.26µ -0.01%
│ old │ new │
│ B/op │ B/op vs base │
EndToEndPipe-16 1.766Ki ± 0% 1.766Ki ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 38.27Ki ± 0% 34.30Ki ± 0% -10.38% (p=0.000 n=10)
geomean 8.221Ki 7.782Ki -5.33%
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
EndToEndPipe-16 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 642.0 ± 0% 615.0 ± 0% -4.21% (p=0.000 n=10)
geomean 35.83 35.07 -2.13%
¹ all samples are equal
Change-Id: I852a799834d2e9b7b915da74e871a4052d13892e
Reviewed-on: https://go-review.googlesource.com/c/go/+/479400
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
wireType itself is just a struct with seven pointer fields,
so an indirection doesn't feel necessary to noticeably reduce the amount
of memory that typeInfo takes for each Go type registered in gob.
The indirection does add a small amount of overhead though,
particularly one extra allocation when registering a type,
which is done a number of times as part of init.
For consistency, also update wireTypeUserInfo to not use a pointer.
Measuring via one of the end-to-end benchmarks and benchinit:
goos: linux
goarch: amd64
pkg: encoding/gob
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
EndToEndPipe-16 736.8n ± 5% 733.9n ± 5% ~ (p=0.971 n=10)
EncodingGob 177.6µ ± 0% 173.6µ ± 0% -2.27% (p=0.000 n=10)
geomean 11.44µ 11.29µ -1.34%
│ old │ new │
│ B/op │ B/op vs base │
EndToEndPipe-16 1.766Ki ± 0% 1.766Ki ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 38.47Ki ± 0% 38.27Ki ± 0% -0.50% (p=0.000 n=10)
geomean 8.241Ki 8.220Ki -0.25%
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
EndToEndPipe-16 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 652.0 ± 0% 642.0 ± 0% -1.53% (p=0.000 n=10)
geomean 36.11 35.83 -0.77%
¹ all samples are equal
Change-Id: I528080b7d990ed595683f155a1ae25dcd26394b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/479398
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The reflect method was added in Go 1.13, in 2019.
gob's own version dates all the way back to 2011.
The behavior appears to be the same, and all tests still pass.
gob does have special cases like always encoding arrays even when they
are the zero value, but that is done via the sendZero boolean field.
Change-Id: I9057b7436963e231fdbf2f6c4b1edb58a2b13305
Reviewed-on: https://go-review.googlesource.com/c/go/+/479397
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Doing this work at init time does make the first encode or decode call
slightly faster, but the cost is still paid upfront.
However, not all programs which directly or indirectly import
encoding/gob end up encoding or decoding any values.
For example, a program might only be run with the -help flag,
or it might only use gob encoding when a specific mode is enabled.
Moreover, any work done at init time needs to happen sequentially and
before the main function can start, blocking the entire program.
Using benchinit, we see a moderate saving at init time:
goos: linux
goarch: amd64
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
EncodingGob 188.9µ ± 0% 175.4µ ± 0% -7.15% (p=0.000 n=10)
│ old │ new │
│ B/op │ B/op vs base │
EncodingGob 39.78Ki ± 0% 38.46Ki ± 0% -3.32% (p=0.000 n=10)
│ old │ new │
│ allocs/op │ allocs/op vs base │
EncodingGob 668.0 ± 0% 652.0 ± 0% -2.40% (p=0.000 n=10)
Change-Id: I75a5df18c9b1d02566e5885a966360d8a525913a
Reviewed-on: https://go-review.googlesource.com/c/go/+/479396
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Prior to this change, there was a possibility that the call of ForgetUnshared at line 134 could acquire the lock first.
Then, after ForgetUnshared released the lock, the doCall function could acquire it and complete its call.
This change prevents this situation by ensuring that ForgetUnshared at line 134 only executes after doCall has finished executing and released the lock.
Change-Id: I45cd4040e40ed52ca8e1b3863092886668dfd521
Reviewed-on: https://go-review.googlesource.com/c/go/+/479499
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Similar to dialMPTCP, this listenMPTCP function is called when the user
has requested MPTCP via SetMultipathTCP in the ListenConfig.
This function falls back to listenTCP on operating systems that do not
support MPTCP or if MPTCP is not supported.
On ListenConfig side, MultipathTCP function can be used to know if the
package will try to use MPTCP or not when Listen is called.
Note that this new listenMPTCP function returns a TCPListener object and
not a new MPTCP dedicated one. The reasons are similar as the ones
explained in the parent commit introducing dialTCP: if MPTCP is used by
default later, Listen will return a different object that could break
existing applications expecting TCPListener.
This work has been co-developped by Gregory Detal
<gregory.detal@tessares.net>.
Updates #56539
Change-Id: I010f1d87f921bbac9e157cef2212c51917852353
Reviewed-on: https://go-review.googlesource.com/c/go/+/471137
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This function is called when the user has requested MPTCP via
SetMultipathTCP in the Dialer.
This new function falls back to dialTCP on operating systems that do not
support MPTCP or if MPTCP is not supported.
On Dialer side, MultipathTCP function can be used to know if the package
will try to use MPTCP or not when Dial is called.
Note that this new dialMPTCP function returns a TCPConn object, like
dialTCP. A new MPTCPConn object using the following composition could
have been returned:
type MPTCPConn struct {
*TCPConn
}
But the drawback is that if MPTCP is used by default one day (see #56539
issue on GitHub), Dial will return a different object: this new
MPTCPConn type instead of the previously expected TCPConn. This can
cause issues for apps checking the returned object.
This work has been co-developped by Gregory Detal
<gregory.detal@tessares.net>.
Updates #56539
Change-Id: I0f9b5b81f630b39142bdd553d4f1b4c775f1dff0
Reviewed-on: https://go-review.googlesource.com/c/go/+/471136
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The docs in .github & CONTRIBUTING.md have three different links to the same place. I have picked the one from "10-proposal.md" as the canonical url as it uses the normal go website shortener service (thus centralizing any future maintenance of this location), uses the new public domain (go.dev over golang.org), and also picks up the readme URI fragment from the shortener redirect which allows the doc links to be cleaner, but also the convenience for the reader starting directly at the human readable parsed README.md.
Should also cut down on confusion like I had reading documentation about why there were multiple proposal sites, which turned out all to be the same place.
Update all proposal-process links to the same URL.
Change-Id: I2f2ea3a6ca34a445268285520e1b19570946afb8
GitHub-Last-Rev: eb769089e6
GitHub-Pull-Request: golang/go#59238
Reviewed-on: https://go-review.googlesource.com/c/go/+/479415
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This changes a few references to `+build` into the modern `//go:build`.
It was compiled by editing `cmd/go/internal/list/context.go`, running
`go test cmd/go -v -run=TestDocsUpToDate -fixdocs`, and then editing
list.go and build.go by hand.
Change-Id: I00fec55e098bf5100f5a186dd975a6628e15beb8
GitHub-Last-Rev: e0eb9be77e
GitHub-Pull-Request: golang/go#59245
Reviewed-on: https://go-review.googlesource.com/c/go/+/479417
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The cast is proceeded by a bounds check. If the bounds check passes
then we know the pointer in the slice is non-nil.
... except casts to pointers of 0-sized arrays. They are strange, as
the bounds check can pass for a nil input.
Change-Id: Ic01cf4a82d59fbe3071d4b271c94efca9cafaec1
Reviewed-on: https://go-review.googlesource.com/c/go/+/479335
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL implements type inference for generic functions used in
assignments: variable init expressions, regular assignments, and
return statements, but (not yet) function arguments passed to
functions. For instance, given a generic function
func f[P any](x P)
and a variable of function type
var v func(x int)
the assignment
v = f
is valid w/o explicit instantiation of f, and the missing type
argument for f is inferred from the type of v. More generally,
the function f may have multiple type arguments, and it may be
partially instantiated.
This new form of inference is not enabled by default (it needs
to go through the proposal process first). It can be enabled
by setting Config.EnableReverseTypeInference.
The mechanism is implemented as follows:
- The various expression evaluation functions take an additional
(first) argument T, which is the target type for the expression.
If not nil, it is the type of the LHS in an assignment.
- The method Checker.funcInst is changed such that it uses both,
provided type arguments (if any), and a target type (if any)
to augment type inference.
Change-Id: Idfde61078e1ee4f22abcca894a4c84d681734ff6
Reviewed-on: https://go-review.googlesource.com/c/go/+/476075
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
json.Marshal doesn't do what one might hope on many Go error values.
Errors created with errors.New marshal as "{}". So JSONHandler treats
errors specially, calling the Error method instead of json.Marshal.
However, if the error happens to implement json.Marshaler, then
JSONHandler should call json.Marshal after all. This CL makes
that change.
Change-Id: I2154246b2ca8fa13d4f6f1256f7a16aa98a8c24a
Reviewed-on: https://go-review.googlesource.com/c/go/+/480155
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
WithoutCancel returns a copy of parent that is not canceled when parent is canceled.
The returned context returns no Deadline or Err, and its Done channel is nil.
Calling Cause on the returned context returns nil.
API changes:
+pkg context, func WithoutCancel(Context) Context
Fixes#40221
Change-Id: Ide29631c08881176a2c2a58409fed9ca6072e65d
Reviewed-on: https://go-review.googlesource.com/c/go/+/479918
Run-TryBot: Sameer Ajmani <sameer@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL updates the linker to support
IMAGE_REL_[I386|AMD64|ARM|ARM64]_ADDR32NB relocations via the new
R_PEIMAGEOFF relocation type. This relocation type references symbols
using RVAs instead of VA, so it can use 4-byte offsets to reference
symbols that would normally require 8-byte offsets.
This new relocation is still not used, but will be useful when
generating Structured Exception Handling (SEH) metadata, which
needs to reference functions only using 4-byte addresses, thus
using RVAs instead of VA is of great help.
Updates #57302
Change-Id: I28d73e97d5cb78a3bc7194dc7d2fcb4a03f9f4d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/461737
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Davis Goodin <dagood@microsoft.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Loong64's R22-R31 and F24-F31 are callee saved registers, which
should be saved in the beginning of sigtramp, and restored at
the end.
In reviewing comments about sigtramp in sys_linux_arm64 it was
noted that a previous issue in arm64 due to missing callee save
registers could also be a problem on loong64, so code was added
to save and restore those.
Updates #31827
Change-Id: I3ae58fe8a64ddb052d0a89b63e82c01ad328dd15
Reviewed-on: https://go-review.googlesource.com/c/go/+/426356
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Auto-Submit: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change the Checker.use/useLHS functions to report if all "used"
expressions evaluated without error. Use that information to
control whether to report an assignment mismatch error or not.
This will reduce the number of errors reported per assignment,
where the assignment mismatch is only one of the errors.
Change-Id: Ia0fc3203253b002e4e1d5759d8d5644999af6884
Reviewed-on: https://go-review.googlesource.com/c/go/+/478756
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
unsafe.SliceData can return pointers which are nil. That function gets
lowered to the SSA OpSlicePtr, which the compiler assumes is non-nil.
This used to be the case as OpSlicePtr was only used in situations
where the bounds check already passed. But with unsafe.SliceData that
is no longer the case.
There are situations where we know it is nil. Use Bounded() to
indicate that.
I looked through all the uses of OSPTR and added SetBounded where it
made sense. Most OSPTR results are passed directly to runtime calls
(e.g. memmove), so even if we know they are non-nil that info isn't
helpful.
Fixes#59293
Change-Id: I437a15330db48e0082acfb1f89caf8c56723fc51
Reviewed-on: https://go-review.googlesource.com/c/go/+/479896
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
As with changes in prior CLs, we don't suppress legitimate
"declared but not used" errors anymore simply because the
respective variables are used in incorrect assignments,
unrelated to the variables in question.
Adjust several (ancient) tests accordingly.
Change-Id: I5826393264d9d8085c64777a330d4efeb735dd2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/478716
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
When external linking with -buildmode=c-archive, the Go linker
eventually invokes the "ar" tool to create the final archive library.
Prior to this patch, if the '-extar' flag was not in use, we would
just run "ar". This works well in most cases but breaks down if we're
doing cross-compilation targeting Windows (macos system "ar"
apparently doesn't create the windows symdef section correctly). To
fix the problem, capture the output of "cc --print-prog-name ar" and
invoke "ar" using the path returned by that command.
Fixes#59221.
Change-Id: I9de66e98947c42633b16fde7208c2958d62fe7cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/479775
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rather than using exprList and handle all cases together, split
apart the cases of n:n assignments and the cases of n:1 assignments.
For the former, the lhs types may (in a future CL) be used to infer
types on the rhs. This is a preparatory step.
Because the two cases are handled separately, the code is longer
(but also more explicit).
Some test cases were adjusted to avoifd (legitimate, but previously
supressed) "declared but not used" errors.
Change-Id: Ia43265f84e423b0ad5594612ba5a0ddce31a4a37
Reviewed-on: https://go-review.googlesource.com/c/go/+/478256
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
We avoid allocating registers when we know they may have a fixed use
later (arg/return value, or the CX shift argument to SHRQ, etc.) But
it isn't worth avoiding that register if it requires moving another
register.
A move we may have to do later is not worth a move we definitely have
to do now.
Fixes#59288
Change-Id: Ibbdcbaea9caee0c5f3e0d6956a1a084ba89757a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/479895
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
In the worst case (x.mode != invalid but x.typ == Typ[Invalid]) we
may get unexpected additional errors; but we don't seem to have
any such situations, at least in the existing tests.
Change-Id: I86ae607b4ac9b926264bb6a967627c40e5a86ade
Reviewed-on: https://go-review.googlesource.com/c/go/+/478715
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL re-introduces useLHS because we don't want to suppress
correct "declared but not used" errors for variables that only
appear on the LHS of an assignment (using Checker.use would mark
them as used).
This CL also adjusts a couple of places where types2 differed
from go/types (and suppressed valid "declared and not used"
errors). Now those errors are surfaced. Adjusted a handful of
tests accordingly.
Change-Id: Ia555139a05049887aeeec9e5221b1f41432c1a57
Reviewed-on: https://go-review.googlesource.com/c/go/+/478635
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
This is a cleanup to allow a consistent definitions of a function
descriptor on code shared between AIX and Linux. They need to be
declared in slightly different ways, but we can hide that in one
macro.
And, update all usage.
Change-Id: I10f3580473db555b4fb4d2597b856f3a67d01a53
Reviewed-on: https://go-review.googlesource.com/c/go/+/478917
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
We now require Go 1.17.13 to bootstrap via make.bash,
and since reflect.Value.IsZero was added in Go 1.13,
we can now use it directly to save a bit of copy pasting.
Change-Id: I77eef782cbbf86c72a4505c8b4866c9658914a24
Reviewed-on: https://go-review.googlesource.com/c/go/+/479395
Reviewed-by: Matthew Dempsky <mdempsky@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: Daniel Martí <mvdan@mvdan.cc>
Comparing two Values with == is sensitive to the internal
representation of Values, and may not correspond to
equality on the Go values they represent. For example,
StringValue("X") != StringValue(strings.ToUpper("x"))
because Go ends up doing a pointer comparison on the data
stored in the Values.
So make Values non-comparable by adding a non-comparable field.
Updates #56345.
Change-Id: Ieedbf454e631cda10bc6fcf470b57d3f1d2182cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/479516
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the Sizes API, recognize an overflow (to a negative value) as a
consequence of an oversize value, and specify as such in the API.
Adjust the various size computations to take overflow into account.
Recognize a negative size or offset as an error and report it rather
than panicking.
Use the same protocol for results provided by the default (StdSizes)
and external Sizes implementations.
Add a new error code TypeTooLarge for the new errors.
Fixes#59190.
Fixes#59207.
Change-Id: I8c33a9e69932760275100112dde627289ac7695b
Reviewed-on: https://go-review.googlesource.com/c/go/+/478919
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
If a panicking signal (e.g. SIGSEGV) happens on a g0 stack, we're
either in the runtime or running C code. Either way we cannot
recover and sigpanic will immediately throw. Further, injecting a
sigpanic could make the C stack unwinder and the debugger fail to
unwind the stack. So don't inject a sigpanic.
If we have cgo traceback and symbolizer attached, if it panics in
a C function ("CF" for the example below), previously it shows
something like
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x45f1ef]
runtime stack:
runtime.throw({0x485460?, 0x0?})
.../runtime/panic.go:1076 +0x5c fp=0x7ffd77f60f58 sp=0x7ffd77f60f28 pc=0x42e39c
runtime.sigpanic()
.../runtime/signal_unix.go:821 +0x3e9 fp=0x7ffd77f60fb8 sp=0x7ffd77f60f58 pc=0x442229
goroutine 1 [syscall]:
CF
/tmp/pp/c.c:6 pc=0x45f1ef
runtime.asmcgocall
.../runtime/asm_amd64.s:869 pc=0x458007
runtime.cgocall(0x45f1d0, 0xc000053f70)
.../runtime/cgocall.go:158 +0x51 fp=0xc000053f48 sp=0xc000053f10 pc=0x404551
main._Cfunc_CF()
_cgo_gotypes.go:39 +0x3f fp=0xc000053f70 sp=0xc000053f48 pc=0x45f0bf
Now it shows
SIGSEGV: segmentation violation
PC=0x45f1ef m=0 sigcode=1
signal arrived during cgo execution
goroutine 1 [syscall]:
CF
/tmp/pp/c.c:6 pc=0x45f1ef
runtime.asmcgocall
.../runtime/asm_amd64.s:869 pc=0x458007
runtime.cgocall(0x45f1d0, 0xc00004ef70)
.../runtime/cgocall.go:158 +0x51 fp=0xc00004ef48 sp=0xc00004ef10 pc=0x404551
main._Cfunc_CF()
_cgo_gotypes.go:39 +0x3f fp=0xc00004ef70 sp=0xc00004ef48 pc=0x45f0bf
I think the new one is reasonable.
For #57698.
Change-Id: I4f7af91761374e9b569dce4c7587499d4799137e
Reviewed-on: https://go-review.googlesource.com/c/go/+/462437
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
It happens with tests that only call lookupWithFake, and before them no-one calls resolverConf.tryUpdate. running alone one of these: TestIssue8434, TestIssueNoSuchHostExists cause a nil dereference panic.
Change-Id: I3fccd96dff5b3c77b5420a7f73742acbafa80142
GitHub-Last-Rev: 7456fd16a7
GitHub-Pull-Request: golang/go#56759
Reviewed-on: https://go-review.googlesource.com/c/go/+/450856
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Give an example illustrating the problem with dots inside groups
or keys. Clarify that to fix it in general, you need to do more
than escape the keys, since that won't distinguish the group "a.b"
from the two groups "a" and "b".
Updates #56345.
Change-Id: Ide301899c548d50b0a1f18e93e93d6e11ad485cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/478199
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
By changing the signature to accept a slice rather than an
array, we can avoid creating the array in the first place.
Functionally, we now also record comma-ok types if the
corresponding assignment was incorrect. But this change
provides more (not less) information through the API and
only so if the program is incorrect in the first place.
Change-Id: I0d629441f2f890a37912171fb26ef0e75827ce23
Reviewed-on: https://go-review.googlesource.com/c/go/+/478218
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In order to identify the sigreturn function, gdb looks for
"__restore_rt". However because that symbol is sometimes missing from
the symbol table, it also performs the same instruction matching as
libgcc, but only in symbols containing "sigaction" (it expects sigaction
to preceed __restore_rt).
To match this heuristic, we add __sigaction to the sigreturn symbol
name.
Fixes#25218.
Change-Id: I09cb231ad23f668d451f31dd5633f782355fc91d
Reviewed-on: https://go-review.googlesource.com/c/go/+/479096
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
This GODEBUG flag disables the freezetheworld call during fatal panic.
freezetheworld asks the scheduler to stop running goroutines on all Ms.
This is normally useful, as it ensures we can collect a traceback from
every goroutine. However, it can be frustrating when debugging the
scheduler itself, as it significantly changes the scheduler state from
when the panic started.
Setting this flag has some disadvantages. Most notably, running
goroutines will not traceback in the standard output (though they may be
included in the final SIGQUIT loop). Additionally, we may missing
concurrently created goroutines when looping over allgs (CL 270861 made
this safe, but still racy). The final state of all goroutines will also
be further removed from the time of panic, as they continued to run for
a while.
One unfortunate part of this flag is the final SIGQUIT loop in the
runtime leaves every thread in the signal handler at exit. This is a bit
frustrating in gdb, which doesn't understand how to step beyond
sigtramp. The data is still there, but you must manually walk.
Change-Id: Ie6bd3ac521fcababea668196b60cf225a0be1a00
Reviewed-on: https://go-review.googlesource.com/c/go/+/478975
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This currently defines an internal function supportsMultipathTCP which
reports whether MPTCP[1] is supported on the current platform.
Only Linux is supported here.
The check on Linux is performed once by attemting to create an MPTCP
socket and look at the returned error:
- If the protocol is not supported, EINVAL (kernel < 5.6) or
EPROTONOSUPPORT (kernel >= 5.6) is returned and there is no point to
try again.
- Other errors can be returned:
- ENOPROTOOPT: the sysctl knob net.mptcp.enabled is set to 0
- Unpredictable ones: if MPTCP is blocked using SELinux, eBPF, etc.
These other errors are due to modifications that can be reverted during
the session: MPTCP can be available again later. In this case, it is
fine to always try to create an MPTCP socket and fallback to TCP in case
of error.
This work has been co-developped by Gregory Detal
<gregory.detal@tessares.net>.
[1] https://www.rfc-editor.org/rfc/rfc8684.html
Updates #56539
Change-Id: Ic84fe85aad887a2be4556a898e649bf6b6f12f03
Reviewed-on: https://go-review.googlesource.com/c/go/+/471135
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls.
So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call.
Instead, we only dropm while the C thread exits, so the extra M won't leak.
When invoking a Go function from C:
Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor.
And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits.
When returning back to C:
Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C.
This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows.
This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread.
For the newly added BenchmarkCGoInCThread, some benchmark results:
1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
Fixes#51676
Change-Id: I380702fe2f9b6b401b2d6f04b0aba990f4b9ee6c
GitHub-Last-Rev: 93dc64ad98
GitHub-Pull-Request: golang/go#51679
Reviewed-on: https://go-review.googlesource.com/c/go/+/392854
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: thepudds <thepudds1460@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The runtime.etext symbol is a marker symbol that marks the end of
(Go's) text section. Currently it has 0 size on some platforms.
Especially in external linking mode, this may cause the next
symbol (e.g. a C function) to have the same address as
runtime.etext, which may confuse some symbolizer. Add some padding
bytes to avoid address collision.
Change-Id: Ic450bab72e4ac79a3b6b891729831d4148b89234
Reviewed-on: https://go-review.googlesource.com/c/go/+/479075
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Nicolas Hillegeer <aktau@google.com>
Run-TryBot: Nicolas Hillegeer <aktau@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This new type will be used in the following commits.
The goal is to have a tristate, an enum with three values:
- system default (0)
- enabled
- disabled
The system default value is linked to defaultMPTCPEnabled: disabled by
default for the moment. Users will be able to force enabling/disabling
MPTCP or use the default behaviour.
This work has been co-developped by Gregory Detal
<gregory.detal@tessares.net>.
Updates #56539
Change-Id: I8fa0cad7a18ca967508799fc828ef060b27683d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/477735
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Under the right conditions we can optimize cmp comparisons to cmn
comparisons, such as:
func foo(a, b int) int {
var c int
if a + b < 0 {
c = 1
}
return c
}
Previously it's compiled as:
ADD R1, R0, R1
CMP $0, R1
CSET LT, R0
With this CL it's compiled as:
CMN R1, R0
CSET MI, R0
Here we need to pay attention to the overflow situation of a+b, the MI
flag means N==1, which doesn't honor the overflow flag V, its value
depends only on the sign of the result. So it has the same semantic of
the Go code, so it's correct.
Similarly, this CL also optimizes the case of >= comparison
using the PL conditional flag.
Change-Id: I47179faba5b30cca84ea69bafa2ad5241bf6dfba
Reviewed-on: https://go-review.googlesource.com/c/go/+/476116
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL combines some rules with the same structure.
In order to avoid extremely long rules, this CL does not merge some
rules. In addition, this CL aligned the components of some rules for
better reading.
Change-Id: I4ba1493251ace00b10591e3c8eef4b6277a4b226
Reviewed-on: https://go-review.googlesource.com/c/go/+/476115
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, net/http replaces the Referer header with the URL of the
previous request, regardless of its status. This CL changes this
behavior, respecting the Referer header for secure connections, if it is
set.
Fixes#44160
Change-Id: I2d7fe37dd681549136329e832188294691584870
Reviewed-on: https://go-review.googlesource.com/c/go/+/291636
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Nick Craig-Wood <nickcw@gmail.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The -test.v=test2json flag causes the testing package to inject extra
control characters in the output to allow the JSON parser to more
gracefully handle extraneous writes to os.Stdout and/or os.Stderr in
the package under test (see CL 443596). However, it doesn't filter out
those control characters because almost no real-world tests will
output them.
It turns out that testing.TestFlag is one of the rare tests that does
output those control characters, because it tests the
-test.v=test2json flag itself.
Fixes#59181.
Change-Id: I35ca6748afcd3d4333563028817caac946f5e86a
Reviewed-on: https://go-review.googlesource.com/c/go/+/479035
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
The vendor_import test lists packages that are known bad (e.g.
bad.go, invalid.go). Pass -e to permit error.
The mod_vendor_auto test includes a package that imports a main
package, which should be an error. Pass -e to permit error.
Updates #59186.
Change-Id: I3b63025c3935f55feda1a95151d4c688d0394644
Reviewed-on: https://go-review.googlesource.com/c/go/+/477838
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Currently it uses "go list ...", which includes all packages in
the known universe, and may include unresolved dependencies. The
test for issue #8181 is specifically for that the test dependency
of package b is downloaded. Test that specifically.
Change-Id: Icfbd7e197698b10ae4bc7c8aa3b0f2c477ca6b8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/477837
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
- Log the actual addresses reported, in case that information is relevant.
- Keep going after the first error, so that we report more information
about the idle connections after they have been used. (Was the first
connection dropped completely, or did it later show up as idle?)
- Remove the third request at the end of the test. It had been
assuming that the address for a new connection would always be
different from the address for the just-closed connection; however,
that assumption does not hold in general.
Removing the third request addresses one of the two failure modes seen
in #55195. It may help in investigating the other failure mode, but I
do not expect it to fix the failures entirely. (I suspect that the
other failure mode is a synchronization bug in returning the idle
connection from the first request.)
For #55195.
Change-Id: If9604ea68db0697268288ce9812dd57633e83fbd
Reviewed-on: https://go-review.googlesource.com/c/go/+/478515
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
In #59155, we observed that the IdleConnStrsForTesting_h2 helper
function sometimes reported extra connections after a
"client conn not usable" failure and retry. It turns out that that
state corresponds exactly to the
http2clientConnIdleState.canTakeNewRequest field, so (with a bit of
extra nethttpomithttp2 plumbing) we can use that field in the helper
to filter out the unusable connections.
Fixes#59155.
Change-Id: Ief6283c9c8c5ec47dd9f378beb0ddf720832484e
Reviewed-on: https://go-review.googlesource.com/c/go/+/477856
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Also add code to replace the vendor directory in the prefix-map in
vendored modules. We weren't doing that before because in vendored
modules, the module's Dir field was set to empty, so nothing was being
replaced. Instead when Dir is not set, so we are in vendor mode,
replace the entire vendor directory's path.
Change-Id: I910499c74237699fd36d18049909a72e2b6705d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/478455
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Delete the set of bytes that need quoting in TextHandler, because it
is almost identical to the set for JSON. Use JSONHandler's safeSet
with a few exceptions.
Updates #56345.
Change-Id: Iff6d309c067affef2e5ecfcebd6e1bb8f00f95b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/478198
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Truncate() a non existent file on Windows currently creates a new blank
file. This behavior is not consistent with other OSes where a file not
found error would instead be returned. This change makes Truncate on
Windows return a file-not-found error when the specified file doesn't
exist, bringing the behavior consistent.
New test cases have been added to prevent a regression.
Fixes#58977
Change-Id: Iaf7b41fc4ea86a2b2ccc59f8be81be42ed211b5c
GitHub-Last-Rev: 636b6c37c1
GitHub-Pull-Request: golang/go#59085
Reviewed-on: https://go-review.googlesource.com/c/go/+/477215
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
For G[T] that was seen and compiled in imported package, it is not added
to typecheck.Target.Decls, prevent wasting compile time re-creating
DUPOKS symbols. However, the linker do not support a type symbol
referencing a method symbol across DSO boundary. That causes unreachable
sym error when building under -linkshared mode.
To fix it, always re-compile generic methods in linkshared mode.
Fixes#58966
Change-Id: I894b417cfe8234ae1fe809cc975889345df22cef
Reviewed-on: https://go-review.googlesource.com/c/go/+/477375
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
- Remove the norace_test.go files, moving their contents elsewhere.
- Rename the internal/testutil package to internal/slogtest.
- Remove value_unsafe.go, moving its contents to value.go.
Updates golang/go#56345.
Change-Id: I2a24ace5aea47f7a3067cd671f606c4fb279d744
Reviewed-on: https://go-review.googlesource.com/c/go/+/478197
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
For ++/-- statements, we know that syntax.AssignStmt.Lhs is a
single expression. Avoid unpacking (and allocating a slice) in
that case. Minor optimization.
Change-Id: I6615fd12277b1cd7d4f8b86e0b9d39f27708c13e
Reviewed-on: https://go-review.googlesource.com/c/go/+/477915
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
We can just use Checker.use, as long as we take care of blank (_)
identifiers that may appear of the LHS of assignments. It's ok to
"use" non-blank variables in case of an error, even on the LHS.
This makes this code match the types2 implementation.
Change-Id: Ied9b9802ecb63912631bbde1dc6993ae855a691b
Reviewed-on: https://go-review.googlesource.com/c/go/+/477895
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Step towards disentangling assignment checking functionality.
In preparation for reverse inference of function type arguments,
but independently helpful in better separating concerns in the code.
Change-Id: I9bac9d8005090c00d9ae6c5cfa13765aacce6b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/477855
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
The changes to exprList (in call.go), made in CL 282193, didn't
get faithfully ported to types2: in the case of operand mode
commaerr, unpacking didn't correctly set the type of the 2nd
value to error. This shouldn't matter for the compiler, but
the code differs from the go/types version. Make them the same.
Change-Id: I6f69575f9ad4f43169b851dffeed85c19588a261
Reviewed-on: https://go-review.googlesource.com/c/go/+/478255
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The runtime/trace package proved useful for investigating go command
performance, and it makes sense (to me) to make this available for
development behind an undocumented flag, at the cost of ~25KB of binary
size. We could of course futher hide this functionality behind an
experiment or build tag, if necessary.
Updates #59157
Change-Id: I612320920ca935f1ee10bb6a803b7952f36c939b
Reviewed-on: https://go-review.googlesource.com/c/go/+/477896
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
On Linux, for a shared object, at least with the Gold linker, the
output file path is recorded in the .gnu.version_d section. When
the output file path is in a temporary directory, it causes
nondeterministic build.
This is similar to #58557, but for Linux with the Gold linker.
Apply the same workaround as in CL 477296.
Should fix the linux-arm64-longtest builder.
Change-Id: Ic703bff32c1bcc40054b89be696e04280855e876
Reviewed-on: https://go-review.googlesource.com/c/go/+/478196
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
The slog structured logging package.
This code was copied from the slog directory of the x/exp repo
at commit 642cacee5cc05231f45555a333d07f1005ffc287, with the
following changes:
- Change import paths.
- Delete unused files list.go, list_test.go.
- Rename example_depth_test.go to example_wrap_test.go and
adjust example output.
- Change the tag safe_values to safe_slog_values.
- Make captureHandler goroutine-safe to fix a race condition
in benchmarks.
- Other small changes as suggested in review comments.
Also, add dependencies to go/build/deps_test.go.
Also, add new API for the API checker.
Updates golang/go#56345.
Change-Id: Id8d720967571ced5c5f32c84a8dd9584943cd7df
Reviewed-on: https://go-review.googlesource.com/c/go/+/477295
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Currently the pacer is designed to pace against the edge. Specifically,
it tries to find the sweet spot at which there are zero assists, but
simultaneously finishes each GC perfectly on time.
This pretty much works, despite the noisiness of the measurement of the
cons/mark ratio, which is central to the pacer's function. (And this
noise is basically a given; the cons/mark ratio is used as a prediction
under a steady-state assumption.) Typically, this means that the GC
might assist a little bit more because it started the GC late, or it
might execute more GC cycles because it started early. In many cases the
magnitude of this variation is small.
However, we can't possibly control for all sources of noise, especially
since some noise can come from the underlying system. Furthermore, there
are inputs to the measurement that have effectively no restrictions on
how they vary, and the pacer needs to assume that they're essentially
static when they might not be in some applications (i.e. goroutine
stacks).
The result of high noise is that the variation in when a GC starts is
much higher, leading to a significant amount of assists in some GC
cycles. While the GC cycle frequency basically averages out in the
steady-state in the face of this variation, starting a GC late has the
significant drawback of reducing application latencies.
This CL thus biases the pacer toward avoiding assists by picking a
cons/mark smoothing function that takes the maximum measured cons/mark
over 5 cycles total. I picked 5 cycles because empirically this was the
best trade-off between window size and smoothness for a uniformly
distributed jitter in the cons/mark signal. The cost here is that if
there's a significant phase change in the application that makes it less
active with the GC, then we'll be using a stale cons/mark measurement
for 5 cycles. I suspect this is fine precisely because this only happens
when the application becomes less active, i.e. when latency matters
less.
Another good reason for this particular bias is that even though the GC
might start earlier and end earlier on average, resulting in more
frequent GC cycles and potentially worse throughput, it also means that
it uses less memory used on average. As a result, there's a reasonable
workaround in just turning GOGC up slightly to reduce GC cycle
frequency and bringing memory (and hopefully throughput) levels back to
the same baseline. Meanwhile, there should still be fewer assists than
before which is just a clear improvement to latency.
Lastly, this CL updates the GC pacer tests to capture this bias against
assists and toward GC cycles starting earlier in the face of noise.
Sweet benchmarks didn't show any meaningful difference, but real
production applications showed a reduction in tail latencies of up
to 45%.
Updates #56966.
Change-Id: I8f03d793f9a1c6e7ef3524d18294dbc0d7de6122
Reviewed-on: https://go-review.googlesource.com/c/go/+/467875
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
This is relatively easy using the new traceback iterator.
Ancestor tracebacks are now limited to 50 frames. We could keep that
at 100, but the fact that it used 100 before seemed arbitrary and
unnecessary.
Fixes#7181
Updates #54466
Change-Id: If693045881d84848f17e568df275a5105b6f1cb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/475960
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
When compiling Go programs to WebAssembly, the memory allocation
strategy was neither releasing memory to the OS nor reusing blocks freed
by calls to runtime.sysFreeOS.
This CL unifies the plan9 and wasm memory management strategy
since both platforms use a linear memory space and do not have a
mechanism for returning memory blocks to the OS.
Fixes#59061
Change-Id: I282ba93c0fe1a0961a31c0825b2a7e0478b8713d
GitHub-Last-Rev: 1c485be4fb
GitHub-Pull-Request: golang/go#59065
Reviewed-on: https://go-review.googlesource.com/c/go/+/476717
Reviewed-by: Julien Fabre <ju.pryz@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Evan Phoenix <evan@phx.io>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is a roll-forward of CL 477395 which was rolled back in CL 477736.
The earlier CL failed because we didn't account for the fact that
on some targets PIE is the default. That is now fixed.
Change-Id: I3e93faa9506033d27040cc9920836f010e05cd26
Reviewed-on: https://go-review.googlesource.com/c/go/+/477919
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Before this CL, the code checked whether external linking was
required for -buildmode=pie. This CL changes it to also consider
whether external linking is required if PIE is the default build mode.
Change-Id: I5ac62fc027622576a152a8b7b5d97bc1d112adb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/477917
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
On Windows we default to PIE, except in race mode.
Pass isRace to platform.DefaultPIE to centralize that decision.
This is in preparation for adding another call to DefaultPIE.
Change-Id: I91b75d307e7d4d260246a934f98734ddcbca372a
Reviewed-on: https://go-review.googlesource.com/c/go/+/477916
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Restore CL 477195, which was reverted in CL 477795.
This version includes CL 477397, which fixes the test problems
with CL 477195. CL 477397 was not submitted because it had an
unrelated failure on darwin-amd64. That failure is fixed by CL 477736.
Fixes#31544
Change-Id: I3a2258cd0ca295cede3511ab212e56fd0114f94a
Reviewed-on: https://go-review.googlesource.com/c/go/+/477839
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The Go linker has always used IMAGE_SYM_TYPE_NULL as COFF symbol
type [1] when external linking and array of structs
(IMAGE_SYM_DTYPE_ARRAY<<4+IMAGE_SYM_TYPE_STRUCT) when internal linking.
This behavior seems idiosyncratic, and looking at the git history it
seems that it has probably been cargo culted from earlier toolchains.
This CL updates the Go linker to use IMAGE_SYM_DTYPE_FUNCTION<<4 for
those symbols representing functions, and IMAGE_SYM_TYPE_NULL otherwise.
This new behavior better represents the symbol types, and can help
other tools interpreting the intent of each symbol, e.g. debuggers or
tools extracting debug info from Go binaries. It also mimics what other
toolchains do, i.e. MSVC, LLVM, and GCC.
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#type-representation
Change-Id: I6b39b2048e95f0324b2eb90c85802ce42db455d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/475856
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Add the following common local transformations
(t + x) - (t + y) == x - y
(t + x) - (y + t) == x - y
(x + t) - (y + t) == x - y
(x + t) - (t + y) == x - y
(x - t) + (t + y) == x + y
(x - t) + (y + t) == x + y
The compiler itself matches such patterns many times. This also aligns with other popular compilers.
Fixes#59111
Change-Id: Ibdfdb414782f8fcaa20b84ac5d43d0d9ae2c7b60
GitHub-Last-Rev: 1aad82e62e
GitHub-Pull-Request: golang/go#59119
Reviewed-on: https://go-review.googlesource.com/c/go/+/477555
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Rather than implying that all ppc64 GOARCHs use function descriptors,
provide a define for platforms that make use of function descriptors.
Condition on GO_PPC64X_HAS_FUNCDESC when choosing whether or not
to load the entry address from the first slot of the function
descriptor.
Updates #56001.
Change-Id: I9cdc788f2de70a1262c17d8485b555383d1374b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/476117
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
There is already a case that when buildmode=shared passes only the
basename of the -o argument to the link command to the linker (and
runs in the directory of that argument) to avoid having that
(temporary) directory of the file be included in the LC_ID_DYLIB load
command. Extend the case to buildmode=plugin, because the same thing
can happen there.
This can only happen on darwin: the -o command can be embedded into
Mach-O and PE binaries, but plugin isn't supported on Windows.
For #58557
Change-Id: I7a4a5627148e77c6906ac4583af3d9f053d5b249
Reviewed-on: https://go-review.googlesource.com/c/go/+/477296
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
For the following description, consider the following basic block graph:
b1 ───┐┌──── b2
││
││
▼▼
b3
For register allocator transitions between basic blocks, there are two
key passes (significant paraphrasing):
First, each basic block is visited in some predetermined visit order.
This is the core visitOrder range loop in regAllocState.regalloc. The
specific ordering heuristics aren't important here, except that the
order guarantees that when visiting a basic block at least one of its
predecessors has already been visited.
Upon visiting a basic block, that block sets its expected starting
register state (regAllocState.startRegs) based on the ending register
state (regAlloc.State.endRegs) of one of its predecessors. (How it
chooses which predecessor to use is not important here.)
From that starting state, registers are assigned for all values in the
block, ultimately resulting in some ending register state.
After all blocks have been visited, the shuffle pass
(regAllocState.shuffle) ensures that for each edge, endRegs of the
predecessor == startRegs of the successor. That is, it makes sure that
the startRegs assumptions actually hold true for each edge. It does this
by adding moves to the end of the predecessor block to place values in
the expected register for the successor block. These may be moves from
other registers, or from memory if the value is spilled.
Now on to the actual problem:
Assume that b1 places some value v1 into register R10, and thus ends
with endRegs containing R10 = v1.
When b3 is visited, it selects b1 as its model predecessor and sets
startRegs with R10 = v1.
b2 does not have v1 in R10, so later in the shuffle pass, we will add a
move of v1 into R10 to the end of b2 to ensure it is available for b3.
This is all perfectly fine and exactly how things should work.
Now suppose that b3 does not use v1. It does need to use some other
value v2, which is not currently in a register. When assigning v2 to a
register, it finds all registers are already in use and it needs to dump
a value. Ultimately, it decides to dump v1 from R10 and replace it with
v2.
This is fine, but it has downstream effects on shuffle in b2. b3's
startRegs still state that R10 = v1, so b2 will add a move to R10 even
though b3 will unconditionally overwrite it. i.e., the move at the end
of b2 is completely useless and can result in code like:
// end of b2
MOV n(SP), R10 // R10 = v1 <-- useless
// start of b3
MOV m(SP), R10 // R10 = v2
This is precisely what happened in #58298.
This CL addresses this problem by dropping registers from startRegs if
they are never used in the basic block prior to getting dumped. This
allows the shuffle pass to avoid placing those useless values into the
register.
There is a significant limitation to this CL, which is that it only
impacts the immediate predecessors of an overwriting block. We can
discuss this by zooming out a bit on the previous graph:
b4 ───┐┌──── b5
││
││
▼▼
b1 ───┐┌──── b2
││
││
▼▼
b3
Here we have the same graph, except we can see the two predecessors of
b1.
Now suppose that rather than b1 assigning R10 = v1 as above, the
assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the
value at all, and simply passes it through to endRegs R10 = v1.
Now the shuffle pass will require both b2 and b5 to add a move to
assigned R10 = v1, because that is specified in their successor
startRegs.
With this CL, b3 drops R10 = v1 from startRegs, but there is no
backwards propagation, so b1 still has R10 = v1 in startRegs, and b5
still needs to add a useless move.
Extending this CL with such propagation may significantly increase the
number of useless moves we can remove, though it will add complexity to
maintenance and could potentially impact build performance depending on
how efficiently we could implement the propagation (something I haven't
considered carefully).
As-is, this optimization does not impact much code. In bent .text size
geomean is -0.02%. In the container/heap test binary, 18 of ~2500
functions are impacted by this CL. Bent and sweet do not show a
noticeable performance impact one way or another, however #58298 does
show a case where this can have impact if the useless instructions end
up in the hot path of a tight loop.
For #58298.
Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f
Reviewed-on: https://go-review.googlesource.com/c/go/+/471158
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Previously, the reverse proxy is unable to detect
the support for hijack or flush if those things
are residing in the response writer in a wrapped
manner.
The reverse proxy now makes use of the new http
response controller as the means to discover
the underlying flusher and hijacker associated
with the response writer, allowing wrapped flusher
and hijacker become discoverable.
Change-Id: I53acbb12315c3897be068e8c00598ef42fc74649
Reviewed-on: https://go-review.googlesource.com/c/go/+/468755
Run-TryBot: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Looks like CL 475735 contained a not-quite-up-to-date version
of the generated file. Maybe ABSFL was in an earlier version of the CL
and was removed before checkin without regenerating the generated file?
In any case, update the generated file. Shouldn't cause a problem, as
that field isn't used in x86/ssa.go.
Change-Id: I3f0b7d41081ba3ce2cdcae385fea16b37d7de81b
Reviewed-on: https://go-review.googlesource.com/c/go/+/477096
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
If the -url flag is provided, when encountering a type checking error,
the compiler will also print a URL to a more detailed description of
the error and an example, if available.
Example uses:
go tool compile -url filename.go
go build -gcflags=-url pkg/path
For instance, a duplicate declaration of an identifier will report
https://pkg.go.dev/internal/types/errors#DuplicateDecl
We may refine the provided URL over time.
Change-Id: Iabe3008a49d9dd88bf690f99e4a4a5432dc08786
Reviewed-on: https://go-review.googlesource.com/c/go/+/476716
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When corpusEntryData failed in workerClient.fuzz and
workerClient.minimize, the shared memory mutex wasn't properly given up,
which would cause a deadlock when worker.cleanup was called.
This was tickled by #59062, wherein the fuzz cache directory would be
removed during operation of the fuzzer, causing corpusEntryData to fail
because the entry files no longer existed.
Updates #51484
Change-Id: Iea284041c20d1581c662bddbbc7e12191771a364
Reviewed-on: https://go-review.googlesource.com/c/go/+/476815
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
I think I confused myself in CL 476335. The TTY check did fix the
problem with os.Stdout, but it was still possible to get the same
problem in other ways. I fixed that by making the splice call blocking,
but it turns out that doing that is enough to fix the TTY problem also.
So we can just remove the TTY check.
Fixes#59041
Change-Id: I4d7ca9dad8361001edb4cfa96bb29b1badb54df0
Reviewed-on: https://go-review.googlesource.com/c/go/+/477035
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@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>
but this time, correctly.
children of Returns can have For/Range loops in them,
and those must be visited.
Includes test to verify that the optimization occurs,
and also that the problematic case that broke the original
optimization is now correctly handled.
Change-Id: If5a94fd51c862d4bfb318fec78456b7b202f3fcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/472355
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
As suggested by Bryan, also update (Errno).Is on windows to include the
missing oserror cases that are covered on other platforms.
Quoting Bryan:
> Windows syscalls don't actually return those errors, but the dummy Errno
> constants defined on Windows should still have the same meaning as on
> Unix.
Updates #41198
Change-Id: I15441abde4a7ebaa3c6518262c052530cd2add4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/476875
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The LoongArch ELF psABI v2.00 revamped the relocation design, largely
moving to using the `pcalau12i + addi/ld/st` pair for PC-relative
addressing within +/- 32 bits. The "pcala" in `pcalau12i` stands for
"PC-aligned add"; the instruction's semantics happen to coincide with
arm64's `adrp`.
Add support for emitting this instruction as part of the relevant
addressing ops, for use with new reloc types later.
Updates #58784
Change-Id: Ic1747cd9745aad0d1abb9bd78400cd5ff5978bc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/455016
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Auto-Submit: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
The fuzzing cache for interesting inputs is shared across all
invocations of scripts by default. When 'go clean -fuzzcache' is called,
or fuzz targets in different scripts have the same names, we can get
race-y unexpected behavior.
Since there isn't a easy way to set just the fuzz cache directory (test
has the flag -test.fuzzcachedir, but it requires setting it on each call
to 'go test'), instead we just consistently set GOCACHE to point to a
directory in the WORK dir. As a byproduct this also prevents usage of a
shared build cache, so we see an increase in build time for these tests.
Updates #59062
Change-Id: Ie78f2943b94f3302c5bdf1f8a1e93b207853666a
Reviewed-on: https://go-review.googlesource.com/c/go/+/476755
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In CL 466099, we accidentally stopped tracking callees while unwinding
inlined frames during traceback printing. The effect is that if you
have a call stack like:
f -> wrapper -> inlined into wrapper -> panic
when considering whether to print the frame for "wrapper", we'll think
that wrapper called panic, rather than the inlined function.
Fix this in the traceback code and add a test.
Change-Id: I30ec836cc316846ce93de94e28a650e23dca184e
Reviewed-on: https://go-review.googlesource.com/c/go/+/476579
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Also enable debugging information in TestScript/test_fuzz_cov, which
hits a deadlock on builders, but I am unable to trigger locally. This
should make it somewhat easier to track down where the issue actually
is.
Updates #51484
Change-Id: I98124f862242798f2d9eba15cacefbd02924cfe2
Reviewed-on: https://go-review.googlesource.com/c/go/+/476595
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This change is a no-op, but makes the acquire-release pair
traceAcquireBuffer / traceReleaseBuffer more explicit, since the former
does acquirem and the latter releasm.
Change-Id: If8a5b1ba8709bf6f39c8ff27b2d3e0c0b0da0e58
Reviewed-on: https://go-review.googlesource.com/c/go/+/476575
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
As soon as the test server closes its listener, its port may be reused
for another test server. On some platforms port reuse takes a long
time, because they cycle through the available ports before reusing an
old one. However, other platforms reuse ports much more aggressively.
net/http shouldn't know or care which kind of platform it is on —
dialing wild connections is risky and can interfere with other tests
no matter what platform we do it on.
Instead of making the second request after the server has completely
shut down, we can start (and finish!) the entire request while we are
certain that the listener has been closed but the port is still open
serving an existing request. If everything synchronizes as we expect,
that should guarantee that the second request fails.
Fixes#56421.
Change-Id: I56add243bb9f76ee04ead8f643118f9448fd1280
Reviewed-on: https://go-review.googlesource.com/c/go/+/476036
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Tweak the code in trampoline generation that determines if a given
call branch will reach, changing the lower limit guard from "x <
-0x800000" to "x <= -0x800000". This is to resolve linking failures
when the computed displacement is exactly -0x800000, which results in
errors of the form
.../ld.gold: internal error in arm_branch_common, at ../../gold/arm.cc:4079
when using the Gold linker, and
...:(.text+0x...): relocation truncated to fit: R_ARM_CALL against `runtime.morestack_noctxt'
when using the bfd linker.
Fixes#59034.
Updates #58425.
Change-Id: I8a76986b38727df1b961654824c2af23f06b9fcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/475957
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
In CL 393354 the os package was changed to raise the open file rlimit
at program start. That code is not inherently tied to the os package.
This CL moves it into the syscall package.
This is in preparation for future changes to restore the original
soft rlimit when exec'ing a new program.
For #46279
Change-Id: I981401b0345d017fd39fdd3dfbb58069be36c272
Reviewed-on: https://go-review.googlesource.com/c/go/+/476096
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 475935 fixed the the ELFv2 ABI violations, but in the process created a
Go ABI violation by failing to allocate stack space for arguments.
Allocate this space while keeping the frame 16 byte aligned.
Updates #58953
Change-Id: I9942d9a433118b391ef8cd7bcea5808695cf94d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/476296
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
As the comment on CodePad goes, we "might want to pad with a trap
instruction to catch wayward programs". The current behavior of
zero-padding is equivalent to padding with an instruction of 0x00000000,
which is invalid according to the LoongArch manuals nevertheless, but
rumor has it that some early and/or engineering samples of Loongson
3A5000 recognized it (maybe behaving like NOP). It is better to avoid
undocumented behavior and ensure execution flow would not overflow the
pads.
Change-Id: I531b1eabeb355e9ad4a2d5340e61f2fe71349297
Reviewed-on: https://go-review.googlesource.com/c/go/+/475616
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The canonical LoongArch NOP instruction form is "andi r0, r0, 0", as
described in the LoongArch Reference Manual Volume 1, Section 2.2.1.10.
We currently use NOR instead, which may or may not change anything (e.g.
performance on less capable micro-architectures) but is deviation from
upstream standards nevertheless. Fix them to use the explicit hardware
NOP which happens to be supported as `NOOP`.
Change-Id: I0a799a1da959e9c3b582feb88202df2bab0ab23a
Reviewed-on: https://go-review.googlesource.com/c/go/+/475615
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
In order to avoid a recursive call to ReadFrom, we were converting
a *File to an io.Writer. But all we really need to do is hide
the ReadFrom method. In particular, this gives us the option of
adding a WriteTo method.
For #58808
Change-Id: I20d3a45749d528c93c23267c467e607fc17dc83f
Reviewed-on: https://go-review.googlesource.com/c/go/+/475535
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This removes an allocation in Conn.grabConn that, while not super
important, was distracting me when optimizing code elsewhere.
While here, convert an atomic that was forgotten when this package was
earlier updated to use the new Go 1.19 typed atomics.
Change-Id: I4666256b4c0512e2162bd485c389130699f9d5ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/475415
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
The tsan13 test highlighted a few bugs.
The first being runtime.sigprofNonGoWrapper was being
called from C code and violating the C ABI.
The second was a missed tsan acquire/release after
thread creation.
The third was runtime.cgoSigtramp violating ELFv2
ABI constraints when loading g. It is reworked to
avoid clobbering R30 and R31 via runtime.load_g.
Change-Id: Ib2d98047fa1b4e72b8045767e86457a8ddfe492e
Reviewed-on: https://go-review.googlesource.com/c/go/+/475935
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This patch changes the Go command to examine the set of compiler
flags feeding into the C compiler when packages that use cgo are built.
If any of a specific set of strange/dangerous flags are in use,
then the Go command generates a token file ("preferlinkext") and
embeds it into the compiled package's archive.
When the Go linker reads the archives of the packages feeding into the
link and detects a "preferlinkext" token, it will then use external
linking for the program by default (although this default can be
overridden with an explicit "-linkmode" flag).
The intent here is to avoid having to teach the Go linker's host object
reader to grok/understand the various odd symbols/sections/types that
can result from boutique flag use, but rather to just boot the objects
in question over to the C linker instead.
Updates #58619.
Updates #58620.
Updates #58848.
Change-Id: I56382dd305de8dac3841a7a7e664277826061eaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/475375
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The problem requiring a revert was creation (somehow) of /-containing
paths in compiler messages on Windows. The new code deals with this
existing-but-unexpected behavior.
original was CL 465805
revert was CL 473795
this is the original, plus a correction for unexpected paths on Windows.
Change-Id: I786e875e704c2d7018c8248960f2ff7188cac3ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/474015
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: David Chase <drchase@google.com>
This CL add support for instrinsifying the TrialingZeros{8,32,64}
functions for 386 architecture. We need handle the case when the input
is 0, which could lead to undefined output from the BSFL instruction.
Next CL will remove the assembly code in runtime/internal/sys package.
Change-Id: Ic168edf68e81bf69a536102100fdd3f56f0f4a1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/475735
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Lowercase letters occur more frequently than uppercase letters
in English text. In IsWordChar, evaluate the most common case
(lowercase letters) first to minimize the expected value of its
execution time. Code clarity does not suffer by rearranging the
order of the checks.
Add a benchmark on a sentence demonstrating the performance
improvement.
name old time/op new time/op delta
IsWordChar-10 122ns ± 0% 114ns ± 1% -6.68% (p=0.000 n=8+10)
Change-Id: Ieee8126a4bd8ee8703905b4f75724623029f6fa2
Reviewed-on: https://go-review.googlesource.com/c/go/+/404100
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: thepudds <thepudds1460@gmail.com>
Currently, in -N mode we skip the tighten pass. However, for very
large functions, many values live across blocks can cause
pathological behavior in the register allocator, which could use
a huge amount of memory or cause the program to hang. For
functions that large, debugging using a debugger is unlikely to be
very useful (the function is probably generated anyway). So we do
a little optimization to make fewer values live across blocks and
make it easier for the compiler.
Fixes#52180.
Change-Id: I355fe31bb87ea5d0870bb52dd06405dd5d791dab
Reviewed-on: https://go-review.googlesource.com/c/go/+/475339
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Creates x509.RevocationListEntry, a new type representing a single
revoked certificate entry in a CRL. Like the existing Certificate and
RevocationList types, this new type has a field for its Raw bytes, and
exposes its mostly-commonly-used extension (ReasonCode) as a top-level
field. This provides more functionality to the user than the existing
pkix.RevokedCertificate type.
Adds a RevokedCertificateEntries field which is a []RevocationListEntry
to RevocationList. This field deprecates the RevokedCertificates field.
When the RevokedCertificates field is removed in a future release, this
will remove one of the last places where a pkix type is directly exposed
in the x509 package API.
Updates the ParseRevocationList function to populate both fields for
now, and updates the CreateRevocationList function to prefer the new
field if it is populated, but use the deprecated field if not. Finally,
also updates the x509 unit tests to use the new .ReasonCode field in
most cases.
Fixes#53573
Change-Id: Ia6de171802a5bd251938366508532e806772d7d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/468875
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
CLONE_NEWTIME can only be used with the clone3 and unshare system calls,
see 769071ac9f:
> All available clone flags have been used, so CLONE_NEWTIME uses the highest
> bit of CSIGNAL. It means that it can be used only with the unshare() and
> the clone3() system calls.
The clone3 syscall was added in Linux kernel version 5.3 and
CLONE_NEWTIME was added in version 5.6. However, it was non-functional
until version 6.3 (and stable versions with the corresponding fix [1]).
[1] https://lore.kernel.org/lkml/20230308105126.10107-1-tklauser@distanz.ch/
In case CLONE_NEWTIME is set in SysProcAttr.Cloneflags on an unsupported
kernel version, the fork/exec call will fail.
Fixes#49779
Change-Id: Ic3ecfc2b601bafaab12b1805d7f9512955a8c7e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/474356
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The assumptions of some of the assembly functions were still scarcely
documented and even disregarded: p256ScalarMult was relying on the fact
that the "undefined behavior" of p256PointAddAsm with regards to
infinity inputs was returning the infinity.
Aside from expanding comments, moving the bit window massaging into a
more easily understood p256OrdRsh function, and fixing the above, this
change folds the last iteration of p256ScalarMult into the loop to
reduce special cases and inverts the iteration order of p256BaseMult so
it matches p256ScalarMult for ease of comparison.
Updates #58647
Change-Id: Ie5712ea778aadbe5adcdb478d111c2527e83caa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/471256
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
This adds a new Buffer.AvailableBuffer method that returns
an empty buffer with a possibly non-empty capacity for use
with append-like APIs.
The typical usage pattern is something like:
b := bb.AvailableBuffer()
b = appendValue(b, v)
bb.Write(b)
It allows logic combining append-like APIs with Buffer
to avoid needing to allocate and manage buffers themselves and
allows the append-like APIs to directly write into the Buffer.
The Buffer.Write method uses the builtin copy function,
which avoids copying bytes if the source and destination are identical.
Thus, Buffer.Write is a constant-time call for this pattern.
Performance:
BenchmarkBufferAppendNoCopy 2.909 ns/op 5766942167.24 MB/s
This benchmark should only be testing the cost of bookkeeping
and never the copying of the input slice.
Thus, the MB/s should be orders of magnitude faster than RAM.
Fixes#53685
Change-Id: I0b41e54361339df309db8d03527689b123f99085
Reviewed-on: https://go-review.googlesource.com/c/go/+/474635
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The vast majority of users of Go toolchains have no need for
binaries like the go command and compiler to include DWARF
information, and the DWARF information is 34% of the size of
the overall Go toolchain zip files (14% when the toolchain is
unzipped on disk, because other parts get bigger).
To save network and disk, disable DWARF in build release binaries.
DWARF remains enabled when developing in the main branch
(signaled by no VERSION file existing), for better debuggability
when actually working on the compiler and go command.
Note that removing DWARF does not break the backtraces shown
when a binary panics, nor does it break other uses of stack traces
from within a Go program, such as runtime.Callers.
To build a release toolchain with DWARF included, people can use
GO_LDFLAGS=-w=0 ./make.bash
Change-Id: Ib0bbe1446adca4599066b2fb2f2734e6825c1106
Reviewed-on: https://go-review.googlesource.com/c/go/+/475378
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fix a few lingering reproducibility problems.
- Do not set CC during go install std if it is unset,
so that the automatic disabling of cgo in cmd/go can run.
- Since CC is not necessary, remove code insisting on it.
- Use a fixed quoting algorithm instead of %q from the
bootstrap toolchain, which can differ from release to release.
- Remove go_bootstrap tool successfully on Windows.
For #24904.
Change-Id: I5c29ba6a8592e93bfab37f123b69f55c02f12ce3
Reviewed-on: https://go-review.googlesource.com/c/go/+/475377
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL removes the NOFRAME flag from runtime.asmcgocall,
runtime.systemstack and runtime.mcall so the compiler can place
the frame pointer on the stack.
This will help unwinding cgo stack frames, and might be all what's
needed for tools that only use the frame pointer to unwind the stack.
That's not the case for gdb, which uses DWARF CFI, and windbg,
which uses SEH. Yet, having the frame pointer correctly set lays
the foundation for supporting cgo unwinding with DWARF CFI and SEH.
Updates #58378
Change-Id: I7655363b3fb619acccd9d5a7f0e3d3dec953cd52
Reviewed-on: https://go-review.googlesource.com/c/go/+/472195
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This CL moves the usleep2HighRes from assembly to good old Go.
This is safe because since CL 288793 usleep is always called with
a g, else one wold have to call usleep_no_g. This condition was
not enforced when high resolution timers were first implemented
on Windows (CL 248699), so the implementation was done in assembly.
Other than removing a bunch of obscure assembly code, this CL makes
high resolution timers work on windows arm/arm64 by free, as the
system calls are the same in all windows platforms.
Change-Id: I41ecf78026fd7e11e85258a411ae074a77e8c7fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/471142
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
The test unconditionally calls testenv.GoToolPath, which will skip the
test anyway. Moving the skip earlier gets this test out of goroutine
dumps if the test process fails or times out, making it easier to
diagnose failures in the remaining tests.
Change-Id: Ibd39546708a83b6f15616b2c4ae7af420e2401f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/475455
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Many of the tests skipped platforms that build PIE binaries by
default, but (still) lack a central function to report which platforms
those are.
Some of the tests assumed (but did not check for) internal linking
support, or invoked `go tool link` directly without properly
configuring the external linker.
A few of the tests seem to be triggering latent bugs in the linker.
For #58806.
For #58807.
For #58794.
Change-Id: Ie4d06b1597f404590ad2abf978d4c363647407ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/472455
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Pass type checker error codes to base.ErrorfAt function calls
in the compiler (but don't do anything yet with the code).
Also, provide error codes to base.ErrorfAt calls in the
compiler as needed.
This opens the door towards reporting the error code and/or
providing a link/reference to more detailed explanations
(see internal/types/errors/codes.go).
Change-Id: I0ff9368d8163499ffdac6adfe8331fdc4a19b4b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/475198
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Printing is the only remaining functionality of gentraceback. Move
this into the traceback printing code and eliminate gentraceback. This
lets us simplify the logic, which fixes at least one minor bug:
previously, if inline unwinding pushed the total printed count over
_TracebackMaxFrames, we would print extra frames and then fail to
print "additional frames elided".
The cumulative performance effect of the series of changes starting
with "add a benchmark of Callers" (CL 472956) is:
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz
│ baseline │ unwinder │
│ sec/op │ sec/op vs base │
Callers/cached-48 1.464µ ± 1% 1.684µ ± 1% +15.03% (p=0.000 n=20)
Callers/inlined-48 1.391µ ± 1% 1.536µ ± 1% +10.42% (p=0.000 n=20)
Callers/no-cache-48 10.50µ ± 1% 11.11µ ± 0% +5.82% (p=0.000 n=20)
StackCopyPtr-48 88.74m ± 1% 81.22m ± 2% -8.48% (p=0.000 n=20)
StackCopy-48 80.90m ± 1% 70.56m ± 1% -12.78% (p=0.000 n=20)
StackCopyNoCache-48 2.458m ± 1% 2.209m ± 1% -10.15% (p=0.000 n=20)
StackCopyWithStkobj-48 26.81m ± 1% 25.66m ± 1% -4.28% (p=0.000 n=20)
geomean 518.8µ 512.9µ -1.14%
The performance impact of intermediate CLs in this sequence varies a
lot as we went through many refactorings. The slowdown in Callers
comes primarily from the introduction of unwinder because that doesn't
get inlined and results in somewhat worse code generation in code
that's extremely hot in those microbenchmarks. The performance gains
on stack copying come mostly from replacing callbacks with direct use
of the unwinder.
Updates #54466.
Fixes#32383.
Change-Id: I4970603b2861633eecec30545e852688bc7cc9a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/468301
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, filling PC traceback buffers is one of the jobs of
gentraceback. This moves it into a new function, tracebackPCs, with a
simple API built around unwinder, and changes all callers to use this
new API.
Updates #54466.
Change-Id: Id2038bded81bf533a5a4e71178a7c014904d938c
Reviewed-on: https://go-review.googlesource.com/c/go/+/468300
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Currently, gentraceback's loop ends with a call to tracebackCgoContext
to process cgo frames. This requires spreading various parts of the
printing and pcbuf logic across these two functions.
Clean this up by moving cgo unwinding into unwinder and then lifting
the printing and pcbuf logic from tracebackCgoContext into
gentraceback along with the other printing and pcbuf logic.
Updates #54466.
Change-Id: Ic71afaa5ae110c0ea5be9409e267e4284e36a8c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/468299
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Many compiler-generated panics are dynamically changed to a "throw"
when they happen in the runtime. One effect of this is that they are
allowed in nowritebarrierrec contexts. Currently, the unsafe.Slice
panics don't have this treatment.
We're about to expose more code that uses unsafe.Slice to the write
barrier checker (it's actually already there and it just can't see
through an indirect call), so give these panics the dynamic check.
Very indirectly updates #54466.
Change-Id: I65cb96fa17eb751041e4fa25a1c1bd03246c82ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/468296
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently, all stack walking logic is in one venerable, large, and
very, very complicated function: runtime.gentraceback. This function
has three distinct operating modes: printing, populating a PC buffer,
or invoking a callback. And it has three different modes of unwinding:
physical Go frames, inlined Go frames, and cgo frames. It also has
several flags. All of this logic is very interwoven.
This CL reimplements the monolithic gentraceback function as an
"unwinder" type with an iterator API. It moves all of the logic for
stack walking into this new type, and gentraceback is now a
much-simplified wrapper around the new unwinder type that still
implements printing, populating a PC buffer, and invoking a callback.
Follow-up CLs will replace uses of gentraceback with direct uses of
unwinder.
Exposing traceback functionality as an iterator API will enable a lot
of follow-up work such as simplifying the open-coded defer
implementation (which should in turn help with #26813 and #37233),
printing the bottom of deep stacks (#7181), and eliminating the small
limit on CPU stacks in profiles (#56029).
Fixes#54466.
Change-Id: I36e046dc423c9429c4f286d47162af61aff49a0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/458218
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Currently, gentraceback consumes the gp.cgoCtxt slice by copying the
slice header and then sub-slicing it as it unwinds. The code for this
is nice and clear, but we're about to lift this state into a structure
and mutating it is going to introduce write barriers that are
disallowed in gentraceback.
This CL replaces the mutable slice header with an index into
gp.cgoCtxt.
For #54466.
Change-Id: I6b701bb67d657290a784baaca34ed02d8247ede2
Reviewed-on: https://go-review.googlesource.com/c/go/+/466863
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We're about to rewrite this code and it has almost no test coverage
right now.
This test is also more complete than the existing
TestTracebackInlineExcluded, so we delete that test.
For #54466.
Change-Id: I144154282dac5eb3798f7d332b806f44c4a0bdf6
Reviewed-on: https://go-review.googlesource.com/c/go/+/466098
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Since srcFunc can represent information for either an real text
function or an inlined function, this means we no longer have to
synthesize a fake _func just to call showframe on an inlined frame.
This is cleaner and also eliminates the one case where _func values
live in the heap. This will let us mark them NotInHeap, which will in
turn eliminate pesky write barriers in the traceback rewrite.
For #54466.
Change-Id: Ibf5e24d01ee4bf384c825e1a4e2922ef444a438e
Reviewed-on: https://go-review.googlesource.com/c/go/+/466097
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We've replicated the code to expand inlined frames in many places in
the runtime at this point. This CL adds a simple iterator API that
abstracts this out.
We also use this to try out a new idea for structuring tests of
runtime internals: rather than exporting this whole internal data type
and API, we write the test in package runtime and import the few bits
of std we need. The idea is that, for tests of internals, it's easier
to inject public APIs from std than it is to export non-public APIs
from runtime. This is discussed more in #55108.
For #54466.
Change-Id: Iebccc04ff59a1509694a8ac0e0d3984e49121339
Reviewed-on: https://go-review.googlesource.com/c/go/+/466096
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Currently, gentraceback resolves the funcInfo of the caller prior to
processing the current frame (calling the callback, printing it, etc).
As a result, if this lookup fails in a verbose context, it will print
the failure before printing the frame that it's already resolved.
To fix this, move the resolution of LR to a funcInfo to after current
frame processing.
This also has the advantage that we can reduce the scope of "flr" (the
caller's funcInfo) to only the post-frame part of the loop, which will
make it easier to stack-rip gentraceback into an iterator.
For #54466.
Change-Id: I8be44d4eac598a686c32936ab37018b8aa97c00b
Reviewed-on: https://go-review.googlesource.com/c/go/+/458217
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
We're about to make major changes to tracebacks. We have benchmarks of
stack copying, but not of PC buffer filling, so add some that we can
track through these changes.
For #54466.
Change-Id: I3ed61d75144ba03b61517cd9834eeb71c99d74df
Reviewed-on: https://go-review.googlesource.com/c/go/+/472956
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
If there was a execution limit enabled, and a result put us beyond that
limit, but the result expanded coverage *and* was a duplicate of an
entry already in the cache, the check if we were passed the limit would
be skipped. Since this check was inside the result check body, and we
would no longer send any new inputs, we'd never get to that check again,
causing the coordinator to just sit in an infinite loop.
This moves the check up to the top of the coordinator loop, so that it
is checked after every result is processed. Also add a cmd/go TestScript
regression test which triggered this case much more frequently.
Updates #51484
Change-Id: I7a2181051177acb853c1009beedd334a40796177
Reviewed-on: https://go-review.googlesource.com/c/go/+/475196
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This patch changes the relative order of "CanInline" and "InlineCalls"
operations within the inliner for clumps of functions corresponding to
strongly connected components in the call graph. This helps increase
the amount of inlining within SCCs, particularly in Go's runtime
package, which has a couple of very large SCCs.
For a given SCC of the form { fn1, fn2, ... fnk }, the inliner would
(prior to this point) walk through the list of functions and for each
function first compute inlinability ("CanInline") and then perform
inlining ("InlineCalls"). This meant that if there was an inlinable
call from fn3 to fn4 (for example), this call would never be inlined,
since at the point fn3 was visited, we would not have computed
inlinability for fn4.
We now do inlinability analysis for all functions in an SCC first,
then do actual inlining for everything. This results in 47 additional
inlines in the Go runtime package (a fairly modest increase
percentage-wise of 0.6%).
Updates #58905.
Change-Id: I48dbb1ca16f0b12f256d9eeba8cf7f3e6dd853cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/474955
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The test had been assuming that any 'gcc' or 'clang' command found in
$PATH could be used to compile cgo dependencies for the target GOARCH
and GOOS. That assumption does not hold in general: for example,
the GOARCH/GOOS configuration may be cross-compiling, which will cause
the test to fail if the native 'gcc' and/or 'clang' is not configured
for the target architecture.
Instead, leave the 'CC' variable unset and assume only that the user
has configured it appropriate to the environment in which they are
running the test.
For #58829.
Change-Id: I9a1269ae3e0b4af281702114dabba844953f74bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/475155
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On darwin, the external linker generally supports CALL relocations
with addend. One exception is that for a very large binary when it
decides to insert a trampoline, instead of applying the addend to
the call target (in the trampoline), it applies the addend to the
CALL instruction in the caller, i.e. generating a call to
trampoline+addend, which is not the correct address and usually
points to unreloated functions.
To work around this, we use label symbols so the CALL is targeting
a label symbol without addend. To make things simple we always use
label symbols for CALLs with addend (in external linking mode on
darwin/arm64), even for small binaries.
Fixes#58935.
Change-Id: I38aed6b62a0496c277c589b5accbbef6aace8dd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/474620
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Remove the compiler's "-wrapglobalmapinit" flag; it is potentially
confusing for users and isn't appropriate as a top level flag. Move
the enable/disable control to the "wrapglobalmapctl" debug flag
(values: 0 on by default, 1 disabled, 2 stress mode). No other changes
to compiler functionality.
Change-Id: I0d120eaf90ee34e29d5032889e673d42fe99e5dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/475035
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
A previous iteration of the tracer's user annotation API had different
names for tasks and regions, and used to return functions for ending
them rather than types with End methods. This CL updates the doc
comments to reflect those changes, and also fixes up the internal
documentation of the events (similar to go.dev/cl/465335, the stack
argument was in the wrong place in the list).
The User Log event internal documentation might also look wrong since
the value argument follows the stack argument. However, the User Log
event is a special case where the log message is appended immediately
following the normal event, including the stack argument. There isn't
much room to clarify this next to the event type definitions, so this CL
clarifies the comment where the event is encoded.
Change-Id: I846c709f6026ef01c0a272557d6390b2c17074e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/472955
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Nick Ripley <nick.ripley@datadoghq.com>
This small PR allows optimizations made in io.Copy (like the use of
io.WriterTo) to be used in one possible path of http.ServeContent
(in case of a non-Range request).
This, in turn, allows us to skip the buffer allocation in io.Copy.
Change-Id: Ifa2ece206ecd4556aaaed15d663b65e95e00bb0a
GitHub-Last-Rev: 94fc031814
GitHub-Pull-Request: golang/go#56480
Reviewed-on: https://go-review.googlesource.com/c/go/+/446276
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Currently we fail to print errors from os.Open and profile.Parse of the
PGO profile, losing context useful to understand these errors.
In fixing this, cleanup error use overall to return an error from
pgo.New and report the problematic file at the top level.
Change-Id: Id7e9c781c4b8520eee96b6f5fe8a0b757d947f7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/474995
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Because each M in Plan 9 runs in a separate OS process with its
own current working directory, a Chdir call in one goroutine needs
to be propagated to other goroutines before a subsequent syscall
with a local pathname (see #9428). This is done by function
syscall.Fixwd, but there is still a race if a goroutine is
preempted and rescheduled on a different M between calling Fixwd
and executing the syscall which it protects. By locking the
goroutine to its OS thread from the start of Fixwd to the end of
the protected syscall, this race can be prevented.
Fixes#58802.
Change-Id: I89c0e43ef4544b5bfb5db7d2158f13f24b42e1f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/474055
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
buildinfo did not check for fat magic, which caused go version to report
unrecognized file format.
This change reads the fat file and passes the first arch file to machoExe.
Fixes#58796
Change-Id: I45cd26729352e46cc7ecfb13f2e9a8d96d62e0a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/473615
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: Carlos Amedee <carlos@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Add support for concurrently reading from an HTTP/1 request body
while writing the response.
Normally, the HTTP/1 server automatically consumes any remaining
request body before starting to write a response, to avoid deadlocking
clients which attempt to write a complete request before reading the
response.
Add a ResponseController.EnableFullDuplex method which disables this
behavior.
For #15527
For #57786
Change-Id: Ie7ee8267d8333e9b32b82b9b84d4ad28ab8edf01
Reviewed-on: https://go-review.googlesource.com/c/go/+/472636
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Also annotate calls to tooSlow with specific reasons.
This will somewhat reduce test coverage on the 'darwin' builders until
we have darwin 'longtest' builders (#35678,#49055), but still seems
worthwhile to avoid alert fatigue from tests that really shouldn't be
running in the short configurations.
Fixes#58918.
Fixes#58919.
Change-Id: I0000f0084b262beeec3eca3e9b8a45d61fab4313
Reviewed-on: https://go-review.googlesource.com/c/go/+/474137
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Original version of TestWindowsStackMemory did not consider sysmon and
other threads running during the test. Allow for 5 extra threads in this
test - this should cover any new threads in the future.
Fixes#58570
Change-Id: I215790f9b94ff40a32ddd7aa54af715d1dc391c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/473415
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On ARM64, in -dynlink mode (building a shared library or a plugin),
accessing global variable is made using the GOT. Currently, the
GOT accessing instruction sequence our assembler generates doesn't
handle large offset well, so we don't fold the offset into loads
and stores in the compiler. Currently, the rewrite rules are
guarded with the -shared flag. However, the GOT access
instructions are only generated in the -dynlink mode (which
implies -shared, but not the other direction).
CL 445535 attempted to remove the guard althgether. But that
causes build failure for -dynlink mode for the reason above. This
CL changes it to guard specifically on -dynlink mode, allowing
the optimization in more cases (-shared but not -dynlink build
modes).
Updates #58826.
Change-Id: I1391db6a33e8d0455a304e7cae7fcfdeb49bfdab
Reviewed-on: https://go-review.googlesource.com/c/go/+/473999
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously if PrivateKey.Sign was called for Ed25519ctx with a context
longer than 255 bytes, the error message would mention Ed25519ph.
For Ed25519ph, the order of message length vs context length errors now
matches VerifyWithOptions. A message length error will be surfaced in
preference to a context length error. It also preferences hash errors
ahead of context length errors which also matches the behaviour of
VerifyWithOptions.
Change-Id: Iae380b3d879e0a9877ea057806fcd1e0ef7f7376
Reviewed-on: https://go-review.googlesource.com/c/go/+/473595
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
If a method is not found on a type V, for better error messages we
report if the method is on *V. There's no need to do a 2nd lookup
for that because the relevant information is readily returned by
lookupFieldOrMethod already.
Simplifies code and removes a long-standing TODO.
Change-Id: Ibdb2269b04c0db61bfe4641404ab1df330397b2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/473655
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This avoids a very large memory allocation if corrupt data says that
we need to read a very long string.
No test case because the problem can only happen for invalid data. Let
the fuzzer find cases like this.
For #47653Fixes#58886
Change-Id: I4e80ba62a6416d010c8804e4f49ae81bdafaadb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/473657
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In -pgo=auto mode, a package may be built multiple times. E.g. for
go build -pgo=auto cmd/a cmd/b
and both cmd/a and cmd/b imports package p, p may be built twice,
one using a's profile, one using b's. If we need to print p, e.g.
in "go list -deps" or when there is a build failure, p will be
printed twice, and currently we don't distinguish them.
We have a precedence for a similar case: for testing, there is the
original package, and the (internal) test version of the package
(which includes _test.go files). Packages that import the package
under testing may also have two versions (one imports the original,
one imports the testing version). In printing, the go command
distinguishes them by adding a "[p.test]" suffix for the latter,
as they are specifically built for the p.test binary.
We do the similar. When a package needs to be compiled multiple
times for different main packages, we attach the main package's
import path, like "p [cmd/a]" for package p built specifically
for cmd/a.
For #58099.
Change-Id: I4a040cf17e1dceb5ca1810c217f16e734c858ab6
Reviewed-on: https://go-review.googlesource.com/c/go/+/473275
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
In -pgo=auto mode, the go command finds a profile named
default.pgo in the main package's directly, and if found, use it
as the profile for the build. Currently we only support a single
main package when -pgo=auto is used.
When multiple main packages are included in a build, they may
have different default profiles (or some have profiles whereas
some don't), so a common dependent package would need to be built
multiple times, with different profiles (or lack of). This CL
handles this. To do so, we need to split (unshare) the dependency
graph so they can attach different profiles.
Fixes#58099.
Change-Id: I1ad21361967aafbf5089d8d5e89229f95fe31276
Reviewed-on: https://go-review.googlesource.com/c/go/+/472358
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Currently, the PGO profile path is global for a single go command
invocation, as it applies to all packages being built (or none).
With -pgo=auto mode with multiple main packages, packages from a
single go command invocation could have different profiles. So it
is necessary that the PGO profile path is per package, which is
this CL does.
For #58099.
Change-Id: I148a15970ec907272db85b4b27ad6b08c41d6c0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/472357
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
The previous code only shortened the directory name for files
in the directory being compiled (and $WORK and runtime/std).
This extends the shortening to all file names.
Change-Id: I6abef6141d57036d893420b82e01ed0fbb637788
Reviewed-on: https://go-review.googlesource.com/c/go/+/465805
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
This modifies the loopvar change to be tied to the
package if it is specified that way, and preserves
the change across inlining.
Down the road, this will be triggered (and flow correctly)
if the changed semantics are tied to Go version specified
in go.mod (or rather, for the compiler, by the specified
version for compilation).
Includes tests.
Change-Id: If54e8b6dd23273b86be5ba47838c90d38af9bd1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/463595
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Adds:
GOEXPERIMENT=loopvar (expected way of invoking)
-d=loopvar={-1,0,1,2,11,12} (for per-package control and/or logging)
-d=loopvarhash=... (for hash debugging)
loopvar=11,12 are for testing, benchmarking, and debugging.
If enabled,for loops of the form `for x,y := range thing`, if x and/or
y are addressed or captured by a closure, are transformed by renaming
x/y to a temporary and prepending an assignment to the body of the
loop x := tmp_x. This changes the loop semantics by making each
iteration's instance of x be distinct from the others (currently they
are all aliased, and when this matters, it is almost always a bug).
3-range with captured iteration variables are also transformed,
though it is a more complex transformation.
"Optimized" to do a simpler transformation for
3-clause for where the increment is empty.
(Prior optimization of address-taking under Return disabled, because
it was incorrect; returns can have loops for children. Restored in
a later CL.)
Includes support for -d=loopvarhash=<binary string> intended for use
with hash search and GOCOMPILEDEBUG=loopvarhash=<binary string>
(use `gossahash -e loopvarhash command-that-fails`).
Minor feature upgrades to hash-triggered features; clients can specify
that file-position hashes use only the most-inline position, and/or that
they use only the basenames of source files (not the full directory path).
Most-inlined is the right choice for debugging loop-iteration change
once the semantics are linked to the package across inlining; basename-only
makes it tractable to write tests (which, otherwise, depend on the full
pathname of the source file and thus vary).
Updates #57969.
Change-Id: I180a51a3f8d4173f6210c861f10de23de8a1b1db
Reviewed-on: https://go-review.googlesource.com/c/go/+/411904
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In assignments and return statements, if we have the wrong number
of LHS or return values, we report the pattern that we have and
the pattern that we want. For untyped constants we use "number"
(to be not overly specific). For unknown types (due to earlier
errors), now use "unknown type" rather than the (cryptic) "<T>".
Fixes#58742.
Change-Id: I69c84ee29fb64badb0121e26a96f003b381024aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/473255
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Also, renamed lookupFieldOrMethod to lookupFieldOrMethodImpl to make
a clearer distinction between this function and the exported version
LookupFieldOrMethod.
Except for the rename, all changes are to comments only.
Change-Id: If7d1465c9cf659ea86bbbbcba8b95f16d2170fcc
Reviewed-on: https://go-review.googlesource.com/c/go/+/473075
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes revive linter receiver-naming warnings:
- receiver name f should be consistent with previous receiver name e for fileListEntry
- receiver name r should be consistent with previous receiver name z for Reader
- receiver name f should be consistent with previous receiver name h for FileHeader
Change-Id: Ibfa14b97f6ca7adc86e3a1df919c5bb5de9716dc
GitHub-Last-Rev: dd7315b09d
GitHub-Pull-Request: golang/go#58477
Reviewed-on: https://go-review.googlesource.com/c/go/+/467519
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
These directives affect the next declaration, so the existing form is
valid, but can be confusing because it is easy to miss. Move then
directly above the declaration for improved readability.
CL 69120 previously moved the Gosched nosplit away to hide it from
documentation. Since CL 224737, directives are automatically excluded
from documentation.
Change-Id: I8ebf2d47fbb5e77c6f40ed8afdf79eaa4f4e335e
Reviewed-on: https://go-review.googlesource.com/c/go/+/472957
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Use a state to exactly track lookup results. In case of lookup failure,
use the state to directly report the cause instead of trying to guess
from the missing and alternative method.
Addresses a TODO (incorrect error message).
Change-Id: I50902752deab741f8199a09fd1ed29286cf5be42
Reviewed-on: https://go-review.googlesource.com/c/go/+/472637
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
internal/platform.MustLinkExternal is used in various places to
determine whether external linking is required. It should always
match what the linker actually requires, but today does not match
because the linker imposes additional constraints.
Updates #31544.
Change-Id: I0cc6ad587e95c607329dea5d60d29a5fb2a9e722
Reviewed-on: https://go-review.googlesource.com/c/go/+/472515
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
After CL 235820 all references to FD.rtimedout and FD.wtimedout
are guarded by mutexes. Therefore they can safely be changed
from type atomic.Bool to bool.
Change-Id: I7ab921d1ad5c7ccc147feb2b0fba58a66b031261
Reviewed-on: https://go-review.googlesource.com/c/go/+/472435
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Go programs can now use the //go:wasmimport module_name function_name
directive to import functions from the WebAssembly runtime.
For now, the directive is restricted to the runtime and syscall/js
packages.
* Derived from CL 350737
* Original work modified to work with changes to the IR conversion code.
* Modification of CL 350737 changes to fully exist in Unified IR path (emp)
* Original work modified to work with changes to the ABI configuration code.
* Fixes#38248
Co-authored-by: Vedant Roy <vroy101@gmail.com>
Co-authored-by: Richard Musiol <mail@richard-musiol.de>
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Change-Id: I740719735d91c306ac718a435a78e1ee9686bc16
Reviewed-on: https://go-review.googlesource.com/c/go/+/463018
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
This CL allows missingMethod (and with it the assertableTo methods)
to provide an error cause without an extra external (and messy) call
of missingMethodCause. This latter function is now only called by
missingMethod and can be eliminated eventually in favor of more
precise error causes generated directly by missingMethod.
The change requires that missingMethod (and the assertableTo methods)
accept general types for both relevant argument types (rather than a
Type and a *Interface) so that error causes can report the appropriate
(possibly defined) type rather than the underlying interface type.
Change-Id: Ic31508073fa138dd5fa27285b06cf232ee638685
Reviewed-on: https://go-review.googlesource.com/c/go/+/472395
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
An inferred type argument must implement its type parameter's constraint's
methods whether or not a core type exists. This allows us to infer type
parameters used in method signatures.
Fixes#51593.
Change-Id: I1fddb05a71d442641b4311d8e30a13ea9bdb4db5
Reviewed-on: https://go-review.googlesource.com/c/go/+/472298
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This allows us to use missingMethod with different type comparers,
such as the global Identical predicate, or a unifier.
Preparation for the next CL.
Change-Id: I237fd9dd7feb3708847ae6d9a112bcdd0aa1ecb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/472297
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Because we rename type parameters to avoid problems with self-recursive
function calls, there's no need anymore for special (and hard to follow)
logic for pointer-identical types. If they are identical, we have a
match. Simplify the code accordingly.
Change-Id: I2e1838a43e90fa4abfae3ab9e4f7da6463508966
Reviewed-on: https://go-review.googlesource.com/c/go/+/471018
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The primary change is that type inference now always reports
an error if a unification step fails (rather than ignoring that
case, see infer2.go). This brings the implementation closely to
the description in #58650; but the implementation is more direct
by always maintaining a simple (type parameter => type) mapping.
To make this work, there are two small but subtle changes in the
unifier:
1) When deciding whether to proceed with the underlying type of
a defined type, we also use the underlying type if the other
type is a basic type (switch from !hasName(x) to isTypeLit(x)
in unifier.go). This makes the case in issue #53650 work out.
See the comment in the code for a detailed explanation of this
change.
2) When we unify against an unbound type parameter, we always
proceed with its core type (if any).
Again, see the comment in the code for a detailed explanation
of this change.
The remaining changes are comment and test adjustments. Because
the new logic now results in failing type inference where it
succeeded before or vice versa, and then instatiation or parameter
passing failed, a handful of error messages changed.
As desired, we still have the same number of errors for the same
programs.
Also, because type inference now produces different results, we
cannot easily compare against infer1 anymore (also infer1 won't
work correctly anymore due to the changes in the unifier). This
comparison (together with infer1) is now disabled.
Because some errors and their positions have changed, we need a
slightly larger error position tolerance for types2 (which produces
less accurate error positions than go/types). Hence the change in
types2/check_test.go.
Finally, because type inference is now slightly more relaxed,
issue #51139 doesn't produce a type unification failure anymore
for a (previously correctly) inferred type argument.
Fixes#51139.
Change-Id: Id796eea42f1b706a248843ad855d9d429d077bd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/470916
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The assertion here was to make sure the newly constructed and
typechecked expression selected the same receiver-qualified method,
but in the case of anonymous receiver types we can actually end up
with separate types.Field instances corresponding to each types.Type
instance. In that case, the assertion spuriously failed.
The fix here is to relax and assertion and just compare the method's
name and type (including receiver type).
Fixes#58563.
Change-Id: I67d51ddb020e6ed52671473c93fc08f283a40886
Reviewed-on: https://go-review.googlesource.com/c/go/+/471676
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The -T flag actually means the start address of text symbols, not
the text sections, which may differ by the header size. It has
been behaving like this since at least 2009. Make it clear in the
documentation.
Also remove the -D flag from the doc. The flag doesn't actually
exist in the implementation.
Fixes#58727.
Change-Id: Ic5b7e93adca3f1ff9f0de33dbb6089f46cdf4738
Reviewed-on: https://go-review.googlesource.com/c/go/+/472356
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Convert TestUnknownAuthorityError to use subtests, avoiding continuing
the test after an unrecoverable failure.
Skip TestIssue51759 on pre-macOS 11 builders, which don't enforce the
behavior we were testing for.
Updates #58791Fixes#58812
Change-Id: I4e3e5bc371aa139d38052184c8232f8cb564138f
Reviewed-on: https://go-review.googlesource.com/c/go/+/472496
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The existing runtime/coverage API set includes a "ClearCounters()"
function that zeros out the counter values in a running process so as
enable capturing of a coverage profile from a specific execution time
segment. Calling this function is only permitted if the program is
built with "-covermode=atomic", due (in part) to concerns about
processors with relaxed memory models in which normal stores can be
reordered.
In the bug in question, a test that stresses a different set of
counter-related APIs was hitting an invalid counter segment when
running on a machine (ppc64) which does indeed have a relaxed memory
consistency model.
From a post-mortem examination of the counter array for the harness
from the ppc64 test run, it was clear that the thread reading values
from the counter array was seeing the sort of inconsistency that could
result from stores being reordered (specifically the prolog
"packageID" and "number-of-counters" stores).
To preclude the possibility of future similar problems, this patch
extends the "atomic mode only" restriction from ClearCounters to the
other APIs that deal with counters (WriteCounters, WriteCountersDir).
Fixes#56197.
Change-Id: Idb85d67a84d69ead508e0902ab46ab4dc82af466
Reviewed-on: https://go-review.googlesource.com/c/go/+/463695
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
A build constraint reports whether the test binary was compiled with
cgo enabled, but that doesn't necessarily imply that cgo can be used
in the environment in which the test binary is run.
In particular, cross-compiled builders (such as Android) may compile
the test binaries on the host with CGO enabled but not provide a C
toolchain on the device that runs the test.
For #58775.
Change-Id: Ibf2f44c9e956cd3fa898c3de67af4449e8ef2dd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/472215
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This CL marks some plan9 assembly functions as NOFRAME to avoid
relying on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions
without stack were also marked as NOFRAME.
Updates #58378
Change-Id: Ic8c9ab5c1a0897bebc6c1419ddc903a7492a1b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/466457
TryBot-Bypass: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL removes some NOFRAME flags on Windows assembly files
for several reasons:
- windows/386 does not use a frame pointer
- Leaf frameless functions already skip the frame pointer
- Some non-leaf functions do not contain enough dragons to justify
not using the frame pointer
Updates #58378
Change-Id: I31e71bf7f769e1957a4adba91778da5af66ce1e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/466835
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
On Windows, replace tests which rely on a root that expired last year.
On Darwin fix an test which wasn't testing the expected behavior, and
fix the behavior which was broken.
Fixes#58791
Change-Id: I771175b9e123b8bb0e4efdf58cc2bb93aa94fbae
Reviewed-on: https://go-review.googlesource.com/c/go/+/472295
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
In the past, we planned to implement asynchronous preemption using
precise register pointer maps. In this strategy, conversions between
unsafe.Pointer and uintptr would need to be marked as unsafe points,
as if a pointer value is temporarily converted to uintptr (and not
live otherwise), the GC would not be able to see it when scanning
the stack (and registers).
But now we actually implemented asynchronous preemption with inner
frame conservative scan. So even if a pointer value lives as an
integer the GC can still see it. There is no need to mark the
conversion as unsafe points. This allows more places to be
preempted, as well as for debugger to inject a call.
Fixes#57719.
Change-Id: I375ab820d8d74d122b565cf72ecc7cdb225dbc01
Reviewed-on: https://go-review.googlesource.com/c/go/+/461696
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
This was noticed while testing hash-search debugging
of the loopvar experiment.
The change is incomplete -- it only addresses local
variables, not parameters. The code to log/search
changes in loop variable semantics depends on this,
so that will be the test.
Change-Id: I0f84ab7696c6cab43486242cacaba6a0bfc45475
Reviewed-on: https://go-review.googlesource.com/c/go/+/464315
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Workspace mode is specifically for working with modules;
it doesn't make sense in GOPATH mode.
This also fixes a panic in (*modload.MainModuleSet).GoVersion
when go.work is present in GOPATH mode.
For #58767.
Change-Id: Ic6924352afb486fecc18e009e6b517f078e81094
Reviewed-on: https://go-review.googlesource.com/c/go/+/471600
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Because "CopyN" will read one more byte, which will cause us
to overflow when calling "Reader.ReadForm(math.MaxInt64)".
So we should check if the parameter exceeds "math.MaxInt64"
to avoid returning no data.
Fixes#58384.
Change-Id: I30088ce6468176b21e4a9a0b8b6080f2986dda23
Reviewed-on: https://go-review.googlesource.com/c/go/+/467557
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: hopehook <hopehook@golangcn.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The compiler used to generate ONAME node with nil Func for them, so the
inliner can still analyze, but could not generate inline call for them
anyway.
CL 436961 attempts to create ONAME node with non-nil Func, causing the
inliner complains about missing body reader.
This CL makes inliner recognize type eq/hash functions, and mark them as
non-inlineable. Longer term, if we do want to inline these functions, we
need to integrate the code generation into Unified IR frontend.
Updates #58572
Change-Id: Icdd4dda03711929faa3d48fe2d9886568471f0bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/469017
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
testGo is currently only configured if testenv.HasGoBuild returns
true, which implies that a complete toolchain is present.
Since setting up testGo now only uses the test binary itself, it does
not actually require 'go build', but fixing that will be a bit more
involved. For now, just skip the test when it isn't set up.
Fixes#58775.
Change-Id: I6487b47b44c87aa139ae11cfa44ce6f0f5f84bd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/472095
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
As background, Power10 adds prefixed load, store, and add immediate
instructions which encode 34b signed displacements. Likewise, they
also give the option to compute addresses against the PC. This enables
using simpler PC relative (PC-rel) relocations instead of maintaining a
dedicated pointer (the TOC) to the code/data blob on PPC64/linux.
Similary, there are several Go opcodes where it can be advantageous to
use prefixed instructions instead of composite sequences like oris/ori/add
to implement "MOVD <big const>, Rx" or "ADD <big const>, Rx, Ry", or
large offset load/stores like "MOVD <big constant>(Rx), Ry" using the same
framework which dynamically configures optab.
When selecting prefixed instruction forms, the assembler must also use
new relocations. These new relocations are always PC-rel by design, thus
code assembled as such has no implicit requirement to maintain a TOC
pointer when assembling shared objects. Thus, we can safely avoid
situations where some Go objects use a TOC pointer, and some do not. This
greatly simplifies linking Go objects. For more details about the
challenges of linking TOC and PC-rel compiled code, see the PPC64 ELFv2
ABI.
The TOC pointer in R2 is still maintained in those build configurations
which previously required it (e.x buildmode=pie). However, Go code built
with PC-rel relocations does not require the TOC pointer. A future
change could remove the overhead of maintaining a TOC pointer in those
build configurations.
This is enabled only for power10/ppc64le/linux.
A final noteworthy difference between the prefixed and regular load/store
instruction forms is the removal of the DS/DQ form restrictions. That
is, the immediate operand does not need to be aligned.
Updates #44549
Change-Id: If59c216d203c3eed963bfa08855e21771e6ed669
Reviewed-on: https://go-review.googlesource.com/c/go/+/355150
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
On Arm64, all 32-bit instructions will ignore the upper 32 bits and
clear them to zero for the result. No need to do an unsign extend before
a 32 bit op.
This CL removes the redundant unsign extension only for the existing
32-bit opcodes, and also omits the sign extension when the upper bit of
the result can be predicted.
Fixes#42162
Change-Id: I61e6670bfb8982572430e67a4fa61134a3ea240a
CustomizedGitHooks: yes
Reviewed-on: https://go-review.googlesource.com/c/go/+/427454
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Eric Fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that the bare minimum change to make the run.go test runner into
a normal go test is done, there remain many opportunities to simplify,
modernize and generally clean up the test code.
Of all the opportunities available, this change tries to fit somewhere
between doing "not enough" and "way too much". This ends up including:
• replace verbose flag with testing.Verbose()
• replace custom temporary directory creation, removal, -keep flag
with testing.T.TempDir
• replace custom code to find the go command with testenv.GoToolPath
• replace many instances of "t.err = err; return" with "return err",
or with t.Fatal when it's clearly a test infrastructure error
• replace reliance on changing working directory to GOROOT/test to
computing and using absolute paths
• replace uses of log.Fatal with t.Fatal
• replace uses of deprecated ioutil package with their replacements
• add some missing error checks, use more idiomatic identifier names
For #56844.
Change-Id: I5b301bb83a8e5b64cf211d7f2f4b14d38d48fea0
Reviewed-on: https://go-review.googlesource.com/c/go/+/466155
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
As motivated on the issue, we want to move the functionality of the
run.go program to happen via a normal go test. Each .go test case in
the GOROOT/test directory gets a subtest, and cmd/go's support for
parallel test execution replaces run.go's own implementation thereof.
The goal of this change is to have fairly minimal and readable diff
while making an atomic changeover. The working directory is modified
during the test execution to be GOROOT/test as it was with run.go,
and most of the test struct and its run method are kept unchanged.
The next CL in the stack applies further simplifications and cleanups
that become viable.
There's no noticeable difference in test execution time: it takes around
60-80 seconds both before and after on my machine. Test caching, which
the previous runner lacked, can shorten the time significantly.
For #37486.
Fixes#56844.
Change-Id: I209619dc9d90e7529624e49c01efeadfbeb5c9ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/463276
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The misc/cgo/life and misc/cgo/stdio tests started out as fairly simple
test cases when they were added, but the machinery to execute them has
grown in complexity over the years.
They currently reuse the test/run.go runner and its "run" action without
needing much of the additional flexibility that said runner implements.
Given that runner isn't well documented, it makes it harder to see that
ultimately these tests just do 'go run' on a few test programs and check
that the output matches a golden file.
Maybe these test cases should move out of misc to be near similar tests,
or the machinery to execute them can made available in a package that is
easier and safer to reuse. I'd rather not block the refactor of the test
directory runner on that, so for now rewrite these to be self-contained.
Also delete misc/cgo/stdio/testdata/run.out which has no effect on the
test. It was seemingly accidentally kept behind during the refactor in
CL 6220049.
For #56844.
Change-Id: I5e2f542824925092cdddb03b44b6295a4136ccb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/465755
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
When inlining functions that contain function literals, we need to be
careful about position information. The OCLOSURE node should use the
inline-adjusted position, but the ODCLFUNC and its body should use the
original positions.
However, the same problem can arise with certain generic constructs,
which require the compiler to synthesize function literals to insert
dictionary arguments.
go.dev/cl/425395 fixed the issue with user-written function literals
in a somewhat kludgy way; this CL extends the same solution to
synthetic function literals.
This is all quite subtle and the solutions aren't terribly robust, so
longer term it's probably desirable to revisit how we track inlining
context for positions. But for now, this seems to be the least bad
solution, esp. for backporting to 1.20.
Updates #54625.
Fixes#58513.
Change-Id: Icc43a70dbb11a0e665cbc9e6a64ef274ad8253d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/468415
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
goos: linux
goarch: amd64
pkg: net/http
cpu: DO-Premium-Intel
│ old │ new │
│ sec/op │ sec/op vs base │
HexEscapeNonASCII-4 469.6n ± 20% 371.1n ± 9% -20.98% (p=0.000 n=10)
│ old │ new │
│ B/op │ B/op vs base │
HexEscapeNonASCII-4 192.0 ± 0% 192.0 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
HexEscapeNonASCII-4 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
Change-Id: Ic8d2b3ddcf2cf724dec3f51a2aba205f2c6e4fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/425786
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
mkalldocs.sh required a Unix shell, making it less accessible for
contributors on Windows. It also used a substantially different
codepath to regenerate the file than the one used to check the file
for staleness, making failures in TestDocsUpToDate more complex to
diagnose.
We can solve both of those problems by using the same technique as in
checkScriptReadme: use the test itself as the generator to update the
file. The test is already written in Go, the test binary already knows
how to mimic the 'go' command, and this approach brings the difference
between the test and the generator down to a single flag check.
Updates #26735.
Change-Id: I7c6f65cb0e0c29e334e38a45412e0a73c4d31d42
Reviewed-on: https://go-review.googlesource.com/c/go/+/468636
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Some integer comparisons with 1 and -1 can be rewritten as comparisons
with 0. For example, x < 1 is equivalent to x <= 0. This is an
advantageous transformation on riscv64 because comparisons with zero
do not require a constant to be loaded into a register. Other
architectures will likely benefit too and the transformation is
relatively benign on architectures that do not benefit.
Change-Id: I2ce9821dd7605a660eb71d76e83a61f9bae1bf25
Reviewed-on: https://go-review.googlesource.com/c/go/+/350831
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Munday <mike.munday@lowrisc.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The runtime-gdb.py script needs procid to be set in order to
map a goroutine ID with an OS thread. The Go runtime is not currently
setting that variable on Windows, so TestGdbPython (and friends) can't
succeed.
This CL initializes procid and unskips gdb tests on Windows.
Fixes#22687
Updates #21380
Updates #22021
Change-Id: Icd1d9fc1764669ed1bf04f53d17fadfd24ac3f30
Reviewed-on: https://go-review.googlesource.com/c/go/+/470596
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
If -c is set while testing multiple packages, then allow
to build testing binary executables to the current directory
or to the directory that -o refers to.
$ go test -c -o /tmp ./pkg1 ./pkg2 ./pkg2
$ ls /tmp
pkg1.test pkg2.test pkg3.test
Fixes#15513.
Change-Id: I3aba01bebfa90e61e59276f2832d99c0d323b82e
Reviewed-on: https://go-review.googlesource.com/c/go/+/466397
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This CL marks some solaris assembly functions as NOFRAME to avoid
relying on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions
without stack were also marked as NOFRAME.
While here, I've reduced the stack usage of runtime·sigtramp by
16 bytes to compensate the additional 8 bytes from the stack-allocated
frame pointer. There were two unused 8-byte slots on the stack, one
at 24(SP) and the other at 80(SP).
Updates #58378
Change-Id: If9230e71a8b3c72681ffc82030ade6ceccf824db
Reviewed-on: https://go-review.googlesource.com/c/go/+/466456
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
One major reason to avoid binary.BigEndian is because
the binary package includes a transitive dependency on reflect.
See #54097.
Given that writer.go already depends on the binary package,
embrace use of it consistently where sensible.
We should either embrace use of binary or fully avoid it.
Change-Id: I5f2d27d0ed8cab5ac54be02362c7d33276dd4b9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/452176
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The mutexes added by CL 235820 aren't sufficient to prevent a race when
an i/o deadline timer fires just as the deadline is being reset to zero.
Consider this possible sequence when goroutine S is clearing the
deadline and goroutine T has been started by the timer:
1. S locks the mutex
2. T blocks on the mutex
3. S sets the timedout flag to false
4. S calls Stop on the timer (and fails, because the timer has fired)
5. S unlocks the mutex
6. T locks the mutex
7. T sets the timedout flag to true
Now all subsequent I/O will timeout, although the deadline has been
cleared.
The fix is for the timeout goroutine to skip setting the timedout
flag if the timer pointer has been cleared, or reassigned by
another SetDeadline operation.
Fixes#57114
Change-Id: I4a45d19c3b4b66cdf151dcc3f70536deaa8216a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/470215
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This patch backs out CL 467715 (written to fix 58425), now that we
have a better fix for the "relocation doesn't fit" problem in the
trampoline generation phase (send in a previous CL).
Updates #58428.
Updates #58425.
Change-Id: Ib0d966fed00bd04db7ed85aa4e9132382b979a44
Reviewed-on: https://go-review.googlesource.com/c/go/+/471596
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The folded name logic (despite all attempts to optimize it)
was fundamentally an O(n) operation where every field in a struct
needed to be linearly scanned in order to find a match.
This made unmashaling of unknown fields always O(n).
Instead of optimizing the comparison for each field,
make it such that we can look up a name in O(1).
We accomplish this by maintaining a map keyed by pre-folded names,
which we can pre-calculate when processing the struct type.
Using a stack-allocated buffer, we can fold the input name and
look up its presence in the map.
Also, instead of mapping from names to indexes,
map directly to a pointer to the field information.
The memory cost of this is the same and avoids an extra slice index.
The new logic is both simpler and faster.
Performance:
name old time/op new time/op delta
CodeDecoder 2.47ms ± 4% 2.42ms ± 2% -1.83% (p=0.022 n=10+9)
UnicodeDecoder 259ns ± 2% 248ns ± 1% -4.32% (p=0.000 n=10+10)
DecoderStream 150ns ± 1% 149ns ± 1% ~ (p=0.516 n=10+10)
CodeUnmarshal 3.13ms ± 2% 3.09ms ± 2% -1.37% (p=0.022 n=10+9)
CodeUnmarshalReuse 2.50ms ± 1% 2.45ms ± 1% -1.96% (p=0.001 n=8+9)
UnmarshalString 67.1ns ± 5% 64.5ns ± 5% -3.90% (p=0.005 n=10+10)
UnmarshalFloat64 60.1ns ± 4% 58.4ns ± 2% -2.89% (p=0.002 n=10+8)
UnmarshalInt64 51.0ns ± 4% 49.2ns ± 1% -3.53% (p=0.001 n=10+8)
Issue10335 80.7ns ± 2% 79.2ns ± 1% -1.82% (p=0.016 n=10+8)
Issue34127 28.6ns ± 3% 28.8ns ± 3% ~ (p=0.388 n=9+10)
Unmapped 177ns ± 2% 177ns ± 2% ~ (p=0.956 n=10+10)
Change-Id: I478b2b958f5a63a69c9a991a39cd5ffb43244a2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/471196
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Use append for HTMLEscape similar to Indent and Compact.
Move it to indent.go alongside Compact, as it shares similar logic.
In a future CL, we will modify appendCompact to be written in terms
of appendHTMLEscape, but we need to first move the JSON decoder logic
out of the main loop of appendCompact.
Change-Id: I131c64cd53d5d2b4ca798b37349aeefe17b418c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/471198
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
This patch provides a fix for a problem linking large arm32 binaries
with external linking, specifically R_CALLARM relocations against
runtime.duff* routines being flagged by the external linker as not
reaching.
What appears to be happening in the bug in question is that the Go
linker and the external linker are using slightly different recipes to
decide whether a given R_CALLARM relocation will "fit" (e.g. will not
require a trampoline). The Go linker is taking into account the addend
on the call reloc (which for calls to runtime.duffcopy or
runtime.duffzero is nonzero), whereas the external linker appears to
be ignoring the addend.
Example to illustrate:
Addr Size Func
----- ----- -----
...
XYZ 1024 runtime.duffcopy
...
ABC ... mypackge.MyFunc
+ R0: R_CALLARM o=8 a=848 tgt=runtime.duffcopy<0>
Let's say that the distance between ABC (start address of
runtime.duffcopy) and XYZ (start of MyFunc) is just over the
architected 24-bit maximum displacement for an R_CALLARM (let's say
that ABC-XYZ is just over the architected limit by some small value,
say 36). Because we're calling into runtime.duffcopy at offset 848,
however, the relocation does in fact fit, but if the external linker
isn't taking into account the addend (assuming that all calls target
the first instruction of the called routine), then we'll get a
"doesn't fit" error from the linker.
To work around this problem, revise the ARM trampoline generation code
in the Go linker that computes the trampoline threshold to ignore the
addend on R_CALLARM relocations, so as to harmonize the two linkers.
Updates #58428.
Updates #58425.
Change-Id: I56e580c05b7b47bbe8edf5532a1770bbd700fbe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/469275
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
The external linker will need to support the new PC relative relocations
when they are generated by Go in a future patch. If it does not, many
unhelpful relocation errors will be generated by the external linker.
Use the -mcpu=power10 option as a surrogate for -mpcrel. It most cases,
it should indicate whether the underlying linker has support for
resolving PC relative relocations.
Change-Id: I84b151ce04512ccaeb17835aaf44105a5f6b515b
Reviewed-on: https://go-review.googlesource.com/c/go/+/469576
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
'RedirectEdges' may range over an out-edge slice under modification, leading to out-of-index
panic, and reuse an IREdge object by mistake if there are multiple inlining call-sites.
Fix by rewriting part of the redirecting operation.
Remove 'redirectEdges' as it's not used now and not working as expected in case of multiple
inlining call-sites.
Fixes#58437.
Change-Id: Ic344d4c262df548529acdc9380636cb50835ca51
Reviewed-on: https://go-review.googlesource.com/c/go/+/466915
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The Grow method is generally a more efficient way to grow a slice.
The older approach of using reflect.MakeSlice has to
waste effort zeroing the elements overwritten by the older slice
and has to allocate the slice header on the heap.
Performance:
name old time/op new time/op delta
CodeDecoder 2.41ms ± 2% 2.42ms ± 2% ~
CodeUnmarshal 3.12ms ± 3% 3.13ms ± 3% ~
CodeUnmarshalReuse 2.49ms ± 3% 2.52ms ± 3% ~
name old alloc/op new alloc/op delta
CodeDecoder 2.00MB ± 1% 1.99MB ± 1% ~
CodeUnmarshal 3.05MB ± 0% 2.92MB ± 0% -4.23%
CodeUnmarshalReuse 1.68MB ± 0% 1.68MB ± 0% -0.32%
name old allocs/op new allocs/op delta
CodeDecoder 77.1k ± 0% 77.0k ± 0% -0.09%
CodeUnmarshal 92.7k ± 0% 91.3k ± 0% -1.47%
CodeUnmarshalReuse 77.1k ± 0% 77.0k ± 0% -0.07%
The Code benchmarks (which are the only ones that uses slices)
are largely unaffected. There is a slight reduction in allocations.
A histogram of slice lengths from the Code testdata is as follows:
≤1: 392
≤2: 256
≤4: 252
≤8: 152
≤16: 126
≤32: 78
≤64: 62
≤128: 46
≤256: 18
≤512: 10
≤1024: 8
A bulk majority of slice lengths are 8 elements or under.
Use of reflect.Value.Grow performs better for larger slices since
it can avoid the zeroing of memory and has a faster growth rate.
However, Grow grows starting from 1 element,
with a 2x growth rate until some threshold (currently 512),
Starting from 1 ensures better utilization of the heap,
but at the cost of more frequent regrowth early on.
In comparison, the previous logic always started
with a minimum of 4 elements, which leads to a wasted capacity
of 75% for the highly frequent case of a single element slice.
The older code always had a growth rate of 1.5x,
and so wastes less memory for number of elements below 512.
All in all, there are too many factors that hurt or help performance.
Rergardless, the simplicity of favoring reflect.Value.Grow
over manually managing growth rates is a welcome simplification.
Change-Id: I62868a7f112ece3c2da3b4f6bdf74d397110243c
Reviewed-on: https://go-review.googlesource.com/c/go/+/471175
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
CL 461275 uses testing.Short to skip this kind of tests. But it may lead
to false positive, because testing.Short may not always set. For
example, the normal workflow when testing changes in net package is
running:
go test -v net
in local machine, that will cause the test failed.
Using testenv.Builder is better, since when it's the standard way to
check whether the test is running on builder or local machine.
Change-Id: Ia5347eb76b4f0415dde8fa3d6c89bd0105f15aa7
Reviewed-on: https://go-review.googlesource.com/c/go/+/471437
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The original comment examples didn't pass the correct number
of function arguments. Rather than fixing that, use a simpler
example and adjust prose a bit.
Change-Id: I2806737a2b8f9c4b876911b214f3d9e28213fc27
Reviewed-on: https://go-review.googlesource.com/c/go/+/470918
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
We started emitting this segment in 2012 in CL 6326054 for #47.
It disabled three kinds of protection: mprotect, randexec, and emutramp.
The randexec protection was deprecated some time ago, replaced by PIE.
The emutramp and mprotect protection was because we used to rely on being
able to create writable executable memory to implement function closures,
but that is not true since https://go.dev/s/go11func was implemented.
Change-Id: I5e3a5279d76d642b0423d26195b891479a235763
Reviewed-on: https://go-review.googlesource.com/c/go/+/471199
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Unlike the rest of nistec, the P-256 assembly doesn't use complete
addition formulas, meaning that p256PointAdd[Affine]Asm won't return the
correct value if the two inputs are equal.
This was (undocumentedly) ignored in the scalar multiplication loops
because as long as the input point is not the identity and the scalar is
lower than the order of the group, the addition inputs can't be the same.
As part of the math/big rewrite, we went however from always reducing
the scalar to only checking its length, under the incorrect assumption
that the scalar multiplication loop didn't require reduction.
Added a reduction, and while at it added it in P256OrdInverse, too, to
enforce a universal reduction invariant on p256OrdElement values.
Note that if the input point is the infinity, the code currently still
relies on undefined behavior, but that's easily tested to behave
acceptably, and will be addressed in a future CL.
Fixes#58647
Fixes CVE-2023-24532
(Filed with the "safe APIs like complete addition formulas are good" dept.)
Change-Id: I7b2c75238440e6852be2710fad66ff1fdc4e2b24
Reviewed-on: https://go-review.googlesource.com/c/go/+/471255
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
As part of the effort to rely less on bytes.Buffer,
switch most operations to use more natural append-like operations.
This makes it easier to swap bytes.Buffer out with a buffer type
that only needs to support a minimal subset of operations.
As a simplification, we can remove the use of the scratch buffer
and use the available capacity of the buffer itself as the scratch.
Also, declare an inlineable mayAppendQuote function to conditionally
append a double-quote if necessary.
Performance:
name old time/op new time/op delta
CodeEncoder 405µs ± 2% 397µs ± 2% -1.94% (p=0.000 n=20+20)
CodeEncoderError 453µs ± 1% 444µs ± 4% -1.83% (p=0.000 n=19+19)
CodeMarshal 559µs ± 4% 548µs ± 2% -2.02% (p=0.001 n=19+17)
CodeMarshalError 724µs ± 3% 716µs ± 2% -1.13% (p=0.030 n=19+20)
EncodeMarshaler 24.9ns ±15% 22.9ns ± 5% ~ (p=0.086 n=20+17)
EncoderEncode 14.0ns ±27% 15.0ns ±20% ~ (p=0.365 n=20+20)
There is a slight performance gain across the board due to
the elimination of the scratch buffer. Appends are done directly
into the unused capacity of the underlying buffer,
avoiding an additional copy. See #53685
Updates #27735
Change-Id: Icf6d612a7f7a51ecd10097af092762dd1225d49e
Reviewed-on: https://go-review.googlesource.com/c/go/+/469558
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
This is part of the effort to reduce direct reliance on bytes.Buffer
so that we can use a buffer with better pooling characteristics.
Unify these two methods as a single version that uses generics
to reduce duplicated logic. Unfortunately, we lack a generic
version of utf8.DecodeRune (see #56948), so we cast []byte to string.
The []byte variant is slightly slower for multi-byte unicode since
casting results in a stack-allocated copy operation.
Fortunately, this code path is used only for TextMarshalers.
We can also delete TestStringBytes, which exists to ensure
that the two duplicate implementations remain in sync.
Performance:
name old time/op new time/op delta
CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9)
CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10)
CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10)
CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10)
EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10)
EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10)
name old speed new speed delta
CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9)
CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10)
CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10)
CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10)
name old alloc/op new alloc/op delta
CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10)
CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7)
CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10)
CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10)
EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal)
EncoderEncode 0.00B 0.00B ~ (all equal)
name old allocs/op new allocs/op delta
CodeEncoder 0.00 0.00 ~ (all equal)
CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal)
CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal)
CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal)
EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal)
EncoderEncode 0.00 0.00 ~ (all equal)
There is a very slight performance degradation for CodeEncoder
due to an increase in allocation sizes. However, the number of allocations
did not change. This is likely due to remote effects of the growth rate
differences between bytes.Buffer and the builtin append function.
We shouldn't overly rely on the growth rate of bytes.Buffer anyways
since that is subject to possibly change in #51462.
As the benchtime increases, the alloc/op goes down indicating
that the amortized memory cost is fixed.
Updates #27735
Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/469556
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
This is part of the effort to reduce direct reliance on bytes.Buffer
so that we can use a buffer with better pooling characteristics.
Avoid direct use of bytes.Buffer in Compact and Indent and
instead modify the logic to rely only on append.
This avoids reliance on the bytes.Buffer.Truncate method,
which makes switching to a custom buffer implementation easier.
Performance:
name old time/op new time/op delta
EncodeMarshaler 25.5ns ± 8% 25.7ns ± 9% ~ (p=0.724 n=10+10)
name old alloc/op new alloc/op delta
EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal)
name old allocs/op new allocs/op delta
EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal)
Updates #27735
Change-Id: I8cded03fab7651d43b5a238ee721f3472530868e
Reviewed-on: https://go-review.googlesource.com/c/go/+/469555
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Bryan Mills <bcmills@google.com>
Factor out and simplify code that generates the addition of a 12 bit immediate
(the addition of a negative value is still handled via subtraction). This also
fixes the mishandling of the case where v is 0.
Change-Id: I6040f33d2fec87b772272531b3bf02390ae7f200
Reviewed-on: https://go-review.googlesource.com/c/go/+/461141
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eric Fang <eric.fang@arm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL marks some netbsd assembly functions as NOFRAME to avoid
relying on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions
without stack were also marked as NOFRAME.
While here, and thanks to CL 466355, `asm_netbsd_amd64.s` can
be deleted in favor of `asm9_unix2_amd64.s`, which makes better
use of the frame pointer.
Updates #58378
Change-Id: Iff554b664ec25f2bb6ec198c0f684590b359c383
Reviewed-on: https://go-review.googlesource.com/c/go/+/466396
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
This signature uses the wrong type for the passed function, which
will be saved in the internal runtime map. Since the functions are
likely compatible (uint64 return versus int64), this may work but
should generally be fixed.
This is other instance of #58440.
Change-Id: Ied82e554745ef72eefeb5be540605809ffa06533
Reviewed-on: https://go-review.googlesource.com/c/go/+/470915
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
This reduces unbounded shift latency by one cycle, and may
generate less instructions in some cases.
When there is a choice whether to use doubleword or word shifts, use
doubleword shifts. Doubleword shifts have fewer hardware scheduling
restrictions across P8/P9/P10.
Likewise, rework the shift sequence to allow the compare/shift/overshift
values to compute in parallel, then choose the correct value.
Some ANDCCconst rules also need reworked to ensure they simplify when
used for their flag value. This commonly occurs when prove fails to
identify a bounded shift (e.g foo32<<uint(x&31)).
Change-Id: Ifc6ff4a865d68675e57745056db414b0eb6f2d34
Reviewed-on: https://go-review.googlesource.com/c/go/+/442597
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
insertInlCall mistakenly uses the absolute line number of the call
rather than the relative line number (adjusted by //line). Switch to the
correct line number.
The call filename was already correct.
Fixes#58648
Change-Id: Id8d1848895233e972d8cfe9c5789a88e62d06556
Reviewed-on: https://go-review.googlesource.com/c/go/+/470876
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A later CL will add additional test cases for CallFile and CallLine with
a //line directive. The parameter/variable checks have nothing to do
with line numbers and will only serve to make the test more difficult to
follow, so split this single mega-test into two: one for testing
file/line and the other for testing parameters/variables.
There are a few additional minor changes:
1. A missing AttrName is now an error.
2. Check added for AttrCallLine, which was previously untested.
For #58648.
Change-Id: I35e75ead766bcf910c58eb20541769349841f2b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/470875
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If you run make.bash on an arm system without GOARM set,
we sniff the local system to find the maximum default GOARM
that will actually work on that system. That's fine, and we can
keep doing that.
But the story for cross-compiling is weirder.
If we build a windows/amd64 toolchain and then use it to
cross-compile linux/arm binaries, we get GOARM=7 binaries.
Do the same on a linux/amd64 system and you get GOARM=5 binaries.
This clearly makes no sense, and worse it makes the builds
non-reproducible in a subtle way.
This CL simplifies the logic and improves reproducibility by
defaulting to GOARM=7 any time we wouldn't sniff the local system.
On go.dev/dl we serve a linux-armv6l distribution with a default GOARM=6.
That is built by setting GOARM=6 during make.bash, so it is unaffected
by this CL and will continue to be GOARM=6.
For #24904.
Change-Id: I4331709876d5948fd33ec6e4a7b18b3cef12f240
Reviewed-on: https://go-review.googlesource.com/c/go/+/470695
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #56986, run the new directive analyzer during 'go test',
to diagnose problems that would otherwise be missed,
like //go:debug appearing in the wrong place in a file
or in the wrong files.
Change-Id: I1ac230c3c67e58b5e584128e0ec6ff482cb225f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/464135
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
For #56986, change the go command to compute and set the
default GODEBUG settings for each main package, based on
the work module's go version and the //go:debug lines in the
main package.
Change-Id: I2118cf0ae6d981138138661e02120c05af648872
Reviewed-on: https://go-review.googlesource.com/c/go/+/453605
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #56986, go/build needs to report up to cmd/go
about //go:debug lines found in the source code.
Rather than make a special case for //go:debug,
this change gathers all top-level directives above the
package line and includes them in the result.
The go command's module index must match go/build,
so this CL contains the code to update the index as well.
A future CL will use the //go:debug lines to prepare the default
GODEBUG settings, as well as rejecting such lines in non-main
packages.
Change-Id: I66ab8dc72f9cd65c503b10b744367caca233f8a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/453603
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously, when a program depends on cgo packages in the standard
library (e.g. net, os/user) but not otherwise use cgo, we default
to internal linking mode. As we shipped pre-built cgo-using packages
in Go distributions, we don't require a C compiler to build those
packages. Then, by using internal linking we can link programs
using those packages without requiring a C toolchain.
As of Go 1.20, we stopped shipping those pre-built packages. If a
user doesn't have a C toolchain, they will use the non-cgo version
of the package. If they have a C toolchain, they can get cgo-using
packages but they can link with the external linker as well. So
there is no strong need to be able to link the cgo version of the
packages without a C toolchain. This CL makes it default to
external linking mode.
Fixes#58619.
Fixes#58620.
Change-Id: I62d3744c2b82ce734813c0e303e417d85dd29868
Reviewed-on: https://go-review.googlesource.com/c/go/+/470298
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The current behavior for -mod=vendor is to let QueryPackages run and
fail from queryImport: "cannot query module due to -mod=vendor".
This has the side effect of allowing "go: finding module for package"
to be printed to stderr. Instead of this, return an error before
running QueryPackages.
Fixes#58417
Change-Id: Idc0ed33d1dd1bd185348da3a18ba8eb2dd225909
GitHub-Last-Rev: dd09deec0a
GitHub-Pull-Request: golang/go#58471
Reviewed-on: https://go-review.googlesource.com/c/go/+/467517
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
If a type parameter has the same name as a predeclared type, error
messages can be very confusing. In these rare cases, explicitly
point out where the type parameter is declared (types2) or that it
is a type parameter (go/types).
(We can't point out where the type parameter is declared in go/types
because we don't have access to the file set in the type writer at
the moment.)
Fixes#58611.
Change-Id: I5c150c2b0afae5fad320821e7e5935090dc2ef4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/470075
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The linux build tags were incorrectly removed from these files by CL 460538.
Restore the correct build tags so that they are only included in builds
for linux/mips* platforms.
Change-Id: I21d8802b0252688d8e2228cf904b47d90b253485
Reviewed-on: https://go-review.googlesource.com/c/go/+/469175
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Previously, the write barrier calls themselves did the actual
writes to memory. Instead, move those writes out to a common location
that both the wb-enabled and wb-disabled code paths share.
This enables us to optimize the write barrier path without having
to worry about performing the actual writes.
Change-Id: Ia71ab651908ec124cc33141afb52e4ca19733ac6
Reviewed-on: https://go-review.googlesource.com/c/go/+/447780
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Future CLs will remove the invariant that pointers are always put in
the write barrier in pairs.
The behavior of the assembly code changes a bit, where instead of writing
the pointers unconditionally and then checking for overflow, check for
overflow first and then write the pointers.
Also changed the write barrier flush function to not take the src/dst
as arguments.
Change-Id: I2ef708038367b7b82ea67cbaf505a1d5904c775c
Reviewed-on: https://go-review.googlesource.com/c/go/+/447779
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Keith Randall <khr@golang.org>
cgo is built with -flto the symbols in runtime/cgo is going to include random numbers which would make builds unreproducible.
Settings -frandom-seeds ensures this is consistent across builds, and to ensure we always use a reproducible seed across builds we use the actionID as the seed string.
runtime/cgo built with "-frandom-seed=OFEc9OKoUMJwh3-5yFCH" would output the following:
$ strings --all --bytes=8 $WORK/b055/_pkg_.a | grep "gnu.lto_.profile"
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
.gnu.lto_.profile.8403a797
Change-Id: I3c2d261a94f23c8227a922da9a7f81660905fd71
GitHub-Last-Rev: cec5162316
GitHub-Pull-Request: golang/go#58561
Reviewed-on: https://go-review.googlesource.com/c/go/+/468835
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
For c + nil, we want the result to still be of pointer type.
Fixes ppc64le build failure with CL 468455, in issue33724.go.
The problem in that test is that it requires a nil check to be
scheduled before the corresponding load. This normally happens fine
because we prioritize nil checks. If we have nilcheck(p) and load(p),
once p is scheduled the nil check will always go before the load.
The issue we saw in 33724 is that when p is a nil pointer, we ended up
with two different p's, an int64(0) as the argument to the nil check
and an (*Outer)(0) as the argument to the load. Those two zeroes don't
get CSEd, so if the (*Outer)(0) happens to get scheduled first, the
load can end up before the nilcheck.
Fix this by always having constant arithmetic preserve the pointerness
of the value, so that both zeroes are of type *Outer and get CSEd.
Update #58482
Update #33724
Change-Id: Ib9b8c0446f1690b574e0f3c0afb9934efbaf3513
Reviewed-on: https://go-review.googlesource.com/c/go/+/468615
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Bypass: Keith Randall <khr@golang.org>
CL 416115 added using faccessat2(2) from syscall.Faccessat on Linux
(which is the only true way to implement AT_EACCESS flag handing),
if available. If not available, it uses some heuristics to mimic the
kernel behavior, mostly taken from glibc (see CL 126415).
Next, CL 414824 added using the above call (via unix.Eaccess) to
exec.LookPath in order to check if the binary can really be executed.
As a result, in a very specific scenario, described below,
syscall.Faccessat (and thus exec.LookPath) mistakenly tells that the
binary can not be executed, while in reality it can be. This makes
this bug a regression in Go 1.20.
This scenario involves all these conditions:
- no faccessat2 support available (i.e. either Linux kernel < 5.8,
or a seccomp set up to disable faccessat2);
- the current user is not root (i.e. geteuid() != 0);
- CAP_DAC_OVERRIDE capability is set for the current process;
- the file to be executed does not have executable permission
bit set for either the current EUID or EGID;
- the file to be executed have at least one executable bit set.
Unfortunately, this set of conditions was observed in the wild -- a
container run as a non-root user with the binary file owned by root with
executable permission set for a user only [1]. Essentially it means it
is not as rare as it may seem.
Now, CAP_DAC_OVERRIDE essentially makes the kernel bypass most of the
checks, so execve(2) and friends work the same was as for root user,
i.e. if at least one executable bit it set, the permission to execute
is granted (see generic_permission() function in the Linux kernel).
Modify the code to check for CAP_DAC_OVERRIDE and mimic the kernel
behavior for permission checks.
[1] https://github.com/opencontainers/runc/issues/3715Fixes#58552.
Change-Id: I82a7e757ab3fd3d0193690a65c3b48fee46ff067
Reviewed-on: https://go-review.googlesource.com/c/go/+/468735
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Instead of keeping track of in which blocks write barriers complete,
introduce a new op that marks the exact memory state where the
write barrier completes.
For future use. This allows us to move some of the write barrier code
to between the start of the merging block and the WBend marker.
Change-Id: If3809b260292667d91bf0ee18d7b4d0eb1e929f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/447777
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Use the same allocator for, e.g., []int32 and []int8. Anything with
similar base shapes and be coerced into a single allocator, which helps
reuse memory more often.
There is not much unsafe in the compiler currently. This adds quite a bit,
joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls.
Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99
Reviewed-on: https://go-review.googlesource.com/c/go/+/461084
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
This change introduces the Compare and Compare32 functions
based on the total-ordering predicate in IEEE-754, section 5.10.
In particular,
* -NaN is ordered before any other value
* +NaN is ordered after any other value
* -0 is ordered before +0
* All other values are ordered the usual way
Compare-8 0.4537n ± 1%
Compare32-8 0.3752n ± 1%
geomean 0.4126n
Fixes#56491.
Change-Id: I5c9c77430a2872f380688c1b0a66f2105b77d5ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/467515
Reviewed-by: WANG Xuerui <git@xen0n.name>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In reviewing CL 466875, I noticed that the implementation of
splitPkgConfigOutput from CL 86541 referred to another specific
implementation, and that implementation has had recent changes to fix
deviations from the POSIX specification for shell argument parsing.
Curious about those changes, I decided to fuzz the function to check
whether it agreed in practice with the way a real shell parses
arguments in POSIX mode. It turned out to deviate in several edge
cases, such as backslash-escapes within single quotes, quoted empty
strings, and carriage returns. (We do not expect to see carriage
returns in pkg-config output anyway, but the quote handling might
matter.)
This change updates the implementation to refer to the POSIX
documentation instead of another implementation, and confirms the
behavior with a fuzz test. It may introduce minor deviations from the
pkgconf implementation that was previously used as a reference, but if
so it is plausible that those could be fixed upstream in pkgconf
(like the other recent changes there).
For #35262.
Updates ##23373.
Change-Id: Ifab76e94af0ca9a6d826379f4a6e2028561e615c
Reviewed-on: https://go-review.googlesource.com/c/go/+/466864
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
The sweep assist computation is intentionally racy for performance,
since the specifics of sweep assist aren't super sensitive to error.
However, if overflow occurs when computing the live heap delta, we can
end up with a massive sweep target that causes the sweep assist to sweep
until sweep termination, causing severe latency issues. In fact, because
heapLive doesn't always increase monotonically then anything that
flushes mcaches will cause _all_ allocating goroutines to inevitably get
stuck in sweeping.
Consider the following scenario:
1. SetGCPercent is called, updating sweepHeapLiveBasis to heapLive.
2. Very shortly after, ReadMemStats is called, flushing mcaches and
decreasing heapLive below the value sweepHeapLiveBasis was set to.
3. Every allocating goroutine goes to refill its mcache, calls into
deductSweepCredit for sweep assist, and gets stuck sweeping until
the sweep phase ends.
Fix this by just checking for overflow in the delta live heap calculation
and if it would overflow, pick a small delta live heap. This probably
means that no sweeping will happen at all, but that's OK. This is a
transient state and the runtime will recover as soon as heapLive
increases again.
Note that deductSweepCredit doesn't check overflow on other operations
but that's OK: those operations are signed and extremely unlikely to
overflow. The subtraction targeted by this CL is only a problem because
it's unsigned. An alternative fix would be to make the operation signed,
but being explicit about the overflow situation seems worthwhile.
Fixes#57523.
Change-Id: Ib18f71f53468e913548aac6e5358830c72ef0215
Reviewed-on: https://go-review.googlesource.com/c/go/+/460376
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Message marshalling makes use of BytesOrPanic a lot, under the
assumption that it will never panic. This assumption was incorrect, and
specifically crafted handshakes could trigger panics. Rather than just
surgically replacing the usages of BytesOrPanic in paths that could
panic, replace all usages of it with proper error returns in case there
are other ways of triggering panics which we didn't find.
In one specific case, the tree routed by expandLabel, we replace the
usage of BytesOrPanic, but retain a panic. This function already
explicitly panicked elsewhere, and returning an error from it becomes
rather painful because it requires changing a large number of APIs.
The marshalling is unlikely to ever panic, as the inputs are all either
fixed length, or already limited to the sizes required. If it were to
panic, it'd likely only be during development. A close inspection shows
no paths for a user to cause a panic currently.
This patches ends up being rather large, since it requires routing
errors back through functions which previously had no error returns.
Where possible I've tried to use helpers that reduce the verbosity
of frequently repeated stanzas, and to make the diffs as minimal as
possible.
Thanks to Marten Seemann for reporting this issue.
Fixes#58001
Fixes CVE-2022-41724
Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468125
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reader.ReadForm is documented as storing "up to maxMemory bytes + 10MB"
in memory. Parsed forms can consume substantially more memory than
this limit, since ReadForm does not account for map entry overhead
and MIME headers.
In addition, while the amount of disk memory consumed by ReadForm can
be constrained by limiting the size of the parsed input, ReadForm will
create one temporary file per form part stored on disk, potentially
consuming a large number of inodes.
Update ReadForm's memory accounting to include part names,
MIME headers, and map entry overhead.
Update ReadForm to store all on-disk file parts in a single
temporary file.
Files returned by FileHeader.Open are documented as having a concrete
type of *os.File when a file is stored on disk. The change to use a
single temporary file for all parts means that this is no longer the
case when a form contains more than a single file part stored on disk.
The previous behavior of storing each file part in a separate disk
file may be reenabled with GODEBUG=multipartfiles=distinct.
Update Reader.NextPart and Reader.NextRawPart to set a 10MiB cap
on the size of MIME headers.
Thanks to Jakob Ackermann (@das7pad) for reporting this issue.
Fixes#58006
Fixes CVE-2022-41725
Change-Id: Ibd780a6c4c83ac8bcfd3cbe344f042e9940f2eab
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1714276
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468124
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL is a port of go.dev/cl/465936 from the x/tools importer, which
changes the unified importer to (1) only call Package.SetImports on
the main package being imported (not any transitively imported
packages), and (2) to only populate it with any packages that were
referenced by the exported API.
With these changes, it should behave identically to how the indexed
importer worked in Go 1.19. It will also allow eventually dropping the
serialized import DAG from the export data format, which should help
with export data file sizes somewhat.
Updates #54096.
Updates #58296.
Change-Id: I70d252a19cada3333ed59b16d1df2abc5a4cff73
Reviewed-on: https://go-review.googlesource.com/c/go/+/467896
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For go/defer calls like "defer f(x, y)", the compiler rewrites it to:
x1, y1 := x, y
defer func() { f(x1, y1) }()
However, if "f" needs runtime type information, the "RType" field will
refer to the outer ".dict" param, causing wrong liveness analysis.
To fix this, if "f" refers to outer ".dict", the dict param will be
copied to an autotmp, and "f" will refer to this autotmp instead.
Fixes#58341
Change-Id: I238b6e75441442b5540d39bc818205398e80c94d
Reviewed-on: https://go-review.googlesource.com/c/go/+/466035
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This copies parts of x/exp/slices into the standard library.
We omit all functions that depend on constraints.Ordered,
and the Func variants of all such functions. In particular this
omits the various Sort and Search functions.
Fixes#57433
Change-Id: I3c28f4c2e6bd1e3c9ad70e120a0dd68065388f77
Reviewed-on: https://go-review.googlesource.com/c/go/+/467417
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Fix a problem with trampoline generation for ARM that was causing link
failures when building selected k8s targets. Representative error
(this is coming from the external linker):
go.go:(.text+...): relocation truncated to fit: R_ARM_CALL against `runtime.duffcopy'
The Go linker is supposed to be limiting text section size for ARM to
0x1c00000 bytes, however due to a problem in the tramp generation
phase this limit wasn't being enforced.
Updates #58428.
Fixes#58425.
Change-Id: I4e778bdcbebeab607a6e626b354ca5109e52a1aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/467715
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, access faults on memory mapped files on Windows (e.g.
from the drive the memory mapped file is on being ejected) cause
a runtime fault that can not be caught by debug.SetPanicOnFault.
On Unix systems, on the other hand, this causes a SIGBUS signal,
which can be caught by debug.SetPanicOnFault. Given that the
documentation of debug.SetPanicOnFault mentions handling memory
mapped files, this is arguably the correct behaviour.
Add handling, analogous to SIGBUS, to EXCEPTION_IN_PAGE_ERROR
on Windows, to allow for users to handle this error.
Fixes#58457
Change-Id: Ic7695fc01271f3552782089ac75c403d5279811f
Reviewed-on: https://go-review.googlesource.com/c/go/+/467195
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
#16455 handled escapes in pkg-config output but only for cflags. The fix
for #41400 left a note that we don't need to parse quotes and unescapes,
but it is still necessary to handle spaces in pkg-config output. As cflags
has already been processed correctly, we apply the same logic to ldflags
here.
Fixes#35262
Change-Id: Id01d422b103780f67f89e99ff1df0d8f51a7a137
GitHub-Last-Rev: c67e511213
GitHub-Pull-Request: golang/go#58429
Reviewed-on: https://go-review.googlesource.com/c/go/+/466875
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
The error message when an invalid goroutine state transition is found in
a trace should show the current state, not the next state, when
comparing against the expected current state.
This CL also picks up a gofmt change to the file.
Change-Id: Ic0ce6c9ce79d8a784b73b115b5db76c311b8593d
Reviewed-on: https://go-review.googlesource.com/c/go/+/467416
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This patch detects at which index position profiling samples that have
the value-type samples count are, instead of the previously hard-coded
position of index 1. Runtime generated profiles always generate CPU
profiling data with the 0 index being CPU nanoseconds, and samples count
at index 1, which is why this previously hasn't come up.
This is a redo of CL 465135, now allowing empty profiles. Note that
preprocessProfileGraph will already cause pgo.New to return nil for
empty profiles.
Fixes#58292
Change-Id: Ia6c94f0793f6ca9b0882b5e2c4d34f38e600c1e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/466675
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fix a misuse of bufio.Reader.Read in the helper class
cmd/internal/cov.MReader; the MReader method in question should have
been using io.ReadFull (passing the bufio.Reader) instead of directly
calling Read.
Using the Read method instead of io.ReadFull will result in a "short"
read when processing a specific subset of counter data files, e.g.
those that are short enough to not trigger the mmap-based scheme we
use for larger files, but also with a large args section (something
large enough to exceed the default 4k buffer size used by
bufio.Reader).
Along the way, add some additional defered Close() calls for files
opened by the CovDataReader.visitPod, to enure we don't leave any open
file descriptor following a call to CovDataReader.Visit.
Fixes#58411.
Change-Id: Iea48dc25c0081be1ade29f3a633df02a681fd941
Reviewed-on: https://go-review.googlesource.com/c/go/+/466677
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
In general it seems ok to assume that an open-source module that did
exist will continue to do so — after all, users of open-source modules
already do that all the time. However, we should not assume that those
modules do not publish new versions — that's really up to their
maintainers to decide.
Two existing tests did make that assumption for the module
gopkg.in/natefinch/lumberjack.v2. Let's remove those two tests.
If we need to replace them at some point, we can replace them with
hermetic test-only modules (#54503) or perhaps modules owned by the Go
project.
Fixes#58445.
Change-Id: Ica8fe587d86fc41f3d8445a4cd2b8820455ae45f
Reviewed-on: https://go-review.googlesource.com/c/go/+/466860
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
This reverts CL 456555.
Reason for revert: This seems too likely to exercise race conditions
in code where a Write call continues to access its buffer after
returning. The HTTP/2 ResponseWriter is one such example.
Reverting this change while we think about this some more.
For #57202
Change-Id: Ic86823f81d7da410ea6b3f17fb5b3f9a979e3340
Reviewed-on: https://go-review.googlesource.com/c/go/+/467095
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Small cleanup to remove a couple of needless global variables.
Instead of relying on two instances of emptyCtx having different
addresses, we use different types.
For #26775
Change-Id: I0bc4813e94226f7b3f52bf4b1b3c3a3bbbebcc9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/455455
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Sameer Ajmani <sameer@golang.org>
Darwin needs the osinit_hack call to fix some bugs in the Apple libc
that surface when Go programs call exec. On iOS, the functions that
osinit_hack uses are not available, so signing fails. But on iOS exec
is also unavailable, so the hack is not needed. Disable it there,
which makes signing work again.
Fixes#58323.
Change-Id: I3f1472f852bb36c06854fe1f14aa27ad450c5945
Reviewed-on: https://go-review.googlesource.com/c/go/+/466516
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Dave Anderson <danderson@tailscale.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Update the code that tries to satisfy unresolved references to
"__stack_chk_fail_local" to look for "libssp_nonshared.a" in addition
to "libc_nonshared.a" (the former archive is the correct place on
Alpine).
Updates #52919.
Updates #54313.
Updates #57261.
Fixes#58385.
Change-Id: Id6cd3ebb4d5388df50a838e6efa5e5b683545b01
Reviewed-on: https://go-review.googlesource.com/c/go/+/466936
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add -fno-stack-protector back to the default set of CFLAGS for cgo, so
as to avoid problems with internal linking locating the library
containing the "__stack_chk_fail_local" support function that some
compilers emit (the specific archive can vary based on GOOS).
Updates #52919.
Updates #54313.
Updates #57261.
Updates #58385.
Change-Id: I4591bfb15501f04b7afe1fcd50c4fb93c86db63d
Reviewed-on: https://go-review.googlesource.com/c/go/+/466935
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Issue an error (instead of crashing) when encountering a symbol that
requires dynamic relocations on mips/mips64. The dynimport support is
in progress, but is not done yet, so rather than crashing, print a
message indicating that the feature is not yet implemented and exit.
Fixes#58240.
Change-Id: I9ad64c89e4f7b4b180964b35ad1d72d375f2df7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/466895
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
For unification we only need the handles map.
The type parameter list was stored for reproducible printing only,
but we can achieve the same effect with sorting.
This opens the door to adding type parameters from different
types/functions that we may want to infer together. They may
be added through separate "addTypeParams" calls in the future.
Printing (which is used for debugging only) will remain reproducible.
Change-Id: I23b56c63fa45a7d687761f2efcf558e61b004584
Reviewed-on: https://go-review.googlesource.com/c/go/+/466955
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Rather than referring back to the type parameter list stored with
the unifier, return inferred types for a given list of type parameters.
This decouples the unifier more and opens the door for inference to
consider type parameters from multiple types for inference.
While at it, introduce an internal flag to control whether
inference results of the two inference implementations should
be compared or not.
Change-Id: I23b254c6c1c750f5bd1360aa2bb088cc466434f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/466795
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change introduces the Compare and Compare32 functions
based on the total-ordering predicate in IEEE-754, section 5.10.
In particular,
* -NaN is ordered before any other value
* +NaN is ordered after any other value
* -0 is ordered before +0
* All other values are ordered the usual way
name time/op
Compare-8 0.24ns ± 1%
Compare32-8 0.24ns ± 0%
Fixes#56491.
Change-Id: I9444fbfefe26741794c4436a26d403b8da97bdaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/459435
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The existing runtime_expandFinalInlineFrame implementation doesn't skip trailing wrappers, but
gentraceback does skip wrapper functions.
This change makes runtime_expandFinalInlineFrame handling wrapper functions consistent to gentraceback.
Fixes#58288
Change-Id: I1b0e2c10b0a89bcb1e787b98d27730cb40a34406
Reviewed-on: https://go-review.googlesource.com/c/go/+/465097
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
The tests for cmd/go/internal/test were not running at all due to a
missed call to m.Run in TestMain. That masked two missing vet
analyzers ("directive" and "timeformat") and a missed update to the
generator script in CL 355452.
Fixes#58415.
Change-Id: I7b0315952967ca07a866cdaa5903478b2873eb7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/466635
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Fix a minor buglet in atomic mode fixup that would generate
non-compilable code for a package containing only the "package X"
clause with no trailing newline following the "X".
Fixes#58370.
Change-Id: I0d9bc4f2b687c6bd913595418f6db7dbe50cc5df
Reviewed-on: https://go-review.googlesource.com/c/go/+/466115
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This patch detects at which index position profiling samples that have the value-type samples count are, instead of the previously hard-coded position of index 1. Runtime generated profiles always generate CPU profiling data with the 0 index being CPU nanoseconds, and samples count at index 1, which is why this previously hasn't come up.
Fixes#58292
Change-Id: Idde761d53b02259f3076c4e5dcb4a96a9d53df0e
GitHub-Last-Rev: dabbf9f88c
GitHub-Pull-Request: golang/go#58294
Reviewed-on: https://go-review.googlesource.com/c/go/+/465135
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Blank node must be ignored when building arguments substitued tree.
Otherwise, it could be used to replace other blank node in left hand
side of an assignment, causing an invalid IR node.
Consider the following code:
type S1 struct {
s2 S2
}
type S2 struct{}
func (S2) Make() S2 {
return S2{}
}
func (S1) Make() S1 {
return S1{s2: S2{}.Make()}
}
var _ = S1{}.Make()
After staticAssignInlinedCall, the assignment becomes:
var _ = S1{s2: S2{}.Make()}
and the arg substitued tree is "map[*ir.Name]ir.Node{_: S1{}}". Now,
when doing static assignment, if there is any assignment to blank node,
for example:
_ := S2{}
That blank node will be replaced with "S1{}":
S1{} := S2{}
So constructing an invalid IR which causes the ICE.
Fixes#58325
Change-Id: I21b48357f669a7e02a7eb4325246aadc31f78fb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/465098
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
This CL marks some darwin assembly functions as NOFRAME to avoid relying
on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions
without stack were also marked as NOFRAME.
This is a second attempt after CL 460235 was reverted.
Change-Id: I790f2108fc01ec193aa32b0bc82362c2344a9f3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/466055
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
This patch changes the compiler's pkg init machinery to pick out large
initialization assignments to global maps (e.g.
var mymap = map[string]int{"foo":1, "bar":2, ... }
and extract the map init code into a separate outlined function, which is
then called from the main init function with a weak relocation:
var mymap map[string]int // KEEP reloc -> map.init.0
func init() {
map.init.0() // weak relocation
}
func map.init.0() {
mymap = map[string]int{"foo":1, "bar":2}
}
The map init outlining is done selectively (only in the case where the
RHS code exceeds a size limit of 20 IR nodes).
In order to ensure that a given map.init.NNN function is included when
its corresponding map is live, we add dummy R_KEEP relocation from the
map variable to the map init function.
This first patch includes the main compiler compiler changes, and with
the weak relocation addition disabled. Subsequent patch includes the
requred linker changes along with switching to the call to the
outlined routine to a weak relocation. See the later linker change for
associated compile time performance numbers.
Updates #2559.
Updates #36021.
Updates #14840.
Change-Id: I1fd6fd6397772be1ebd3eb397caf68ae9a3147e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/461315
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
People are using this to get the name of the function from a function type:
runtime.FuncForPC(reflect.ValueOf(fn).Pointer()).Name()
Unfortunately, this technique falls down when the first instruction
of the function is from an inlined callee. Then the expression above
gets you the name of the inlined function instead of the function itself.
To fix this, ensure that the first instruction is never from an inlinee.
Normally functions have prologs so those are already fine. In just the
cases where a function is a leaf with no local variables, and an instruction
from an inlinee appears first in the prog list, add a nop at the start
of the function to hold a non-inlined position.
Consider the nop a "mini-prolog" for leaf functions.
Fixes#58300
Change-Id: Ie37092f4ac3167fe8e5ef4a2207b14abc1786897
Reviewed-on: https://go-review.googlesource.com/c/go/+/465076
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: David Chase <drchase@google.com>
Introduce a flag in the object file indicating whether a given
function corresponds to a compiler-generated (not user-written) init
function, such as "os.init" or "syscall.init". Add code to the
compiler to fill in the correct value for the flag, and add support to
the loader package in the linker for testing the flag. The new loader
API is currently unused, but will be needed in the next CL in this
stack.
Updates #2559.
Updates #36021.
Updates #14840.
Change-Id: Iea7ad2adda487e4af7a44f062f9817977c53b394
Reviewed-on: https://go-review.googlesource.com/c/go/+/463855
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When unifying types, we always consider underlying types if inference
would fail otherwise. If a type parameter has a (non-defined) type
inferred and later matches against a defined type, make sure to keep
that defined type instead.
For #43056.
Change-Id: I24e4cd2939df7c8069e505be10914017c1c1c288
Reviewed-on: https://go-review.googlesource.com/c/go/+/464348
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
The intent was to always append a newline if a newline was missing.
The older logic accidentally only checked the payload for newlines
and forgot to check the prefix as well. Fix it to check both together.
This changes the output of Logger.Output in the situation where
the prefix contains a trailing newline and the output is empty.
This is a very rare combination and unlikely to occur in practice.
Change-Id: Ic04ded6c29a90383e29bf7f59223a808ee1cbdc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/465316
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
This CL adds rules that replaces instances of ISEL that produce
a boolean result based on a condition register by SETBC/SETBCR
operations. On Power10 these are convereted to SETBC/SETBCR
instructions that use one register instead of 3 registers
conventionally used by ISEL and hence reduces register pressure.
On loops written specifically to exercise such instances of ISEL
extensively, a performance improvement of 2.5% is seen on Power10.
Also added verification tests to verify correct generation of
SETBC/SETBCR instructions on Power10.
Change-Id: Ib719897f09d893de40324440a43052dca026e8fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/449795
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Update unicode/tables.go to reflect changes in the Unicode Standard up to
Unicode 15.0.0, released 13 Sept 2022.
In order to accommodate this update, strconv/isPrint has been updated to
reflect changes in printable characters.
Also changed is template/exec_test.go for both text and html packages- in
the test "TestJSEscaping", rune U+FDFF was used as a placeholder for an
unprintable character. This codepoint was assigned and made printable in
Unicode 14.0.0, breaking this test. It has been replaced with the assigned
and never-printable U+FFFE to fix the test and provide resiliency in the
future.
This upgrade bypasses Unicode 14.0.0, but is compatible.
Updates https://github.com/golang/go/issues/48621
Fixes https://github.com/golang/go/issues/55079
Change-Id: I40efd097eb746db0727ebf7437280916d1242e47
GitHub-Last-Rev: c8885cab7a
GitHub-Pull-Request: golang/go#57265
Reviewed-on: https://go-review.googlesource.com/c/go/+/456837
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Since log is already responsible for managing its own buffers
it is unfortunate that it calls fmt.Sprintf, which allocates,
only to append that intermediate string to another buffer.
Instead, use the new fmt.Append variants and avoid the allocation.
We modify Logger.Output to wrap an internal Logger.output,
which can be configured to use a particular append function.
Logger.output is called from all the other functionality instead.
This has the further advantage of simplifying the isDiscard check,
which occurs to avoid the costly fmt.Print call.
We coalesce all 6 checks as just 1 check in Logger.output.
Also, swap the declaration order of Logger.Print and Logger.Printf
to match the ordering elsewhere in the file.
Performance:
name old time/op new time/op delta
Println 188ns ± 2% 172ns ± 4% -8.39% (p=0.000 n=10+10)
PrintlnNoFlags 139ns ± 1% 116ns ± 1% -16.71% (p=0.000 n=9+9)
name old allocs/op new allocs/op delta
Println 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
PrintlnNoFlags 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
Change-Id: I79d0ee404df848beb3626fe863ccc73a3e2eb325
Reviewed-on: https://go-review.googlesource.com/c/go/+/464345
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Logger.Log methods are called in a highly concurrent manner in many servers.
Acquiring a lock in each method call results in high lock contention,
especially since each lock covers a non-trivial amount of work
(e.g., formatting the header and outputting to the writer).
Changes made:
* Modify the Logger to use atomics so that the header formatting
can be moved out of the critical lock section.
Acquiring the flags does not occur in the same critical section
as outputting to the underlying writer, so this introduces
a very slight consistency instability where concurrently calling
multiple Logger.Output along with Logger.SetFlags may cause
the older flags to be used by some ongoing Logger.Output calls
even after Logger.SetFlags has returned.
* Use a sync.Pool to buffer the intermediate buffer.
This approach is identical to how fmt does it,
with the same max cap mitigation for #23199.
* Only protect outputting to the underlying writer with a lock
to ensure serialized ordering of output.
Performance:
name old time/op new time/op delta
Concurrent-24 19.9µs ± 2% 8.3µs ± 1% -58.37% (p=0.000 n=10+10)
Updates #19438
Change-Id: I091beb7431d8661976a6c01cdb0d145e37fe3d22
Reviewed-on: https://go-review.googlesource.com/c/go/+/464344
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This change intrinsifies ReverseBytes{16|32|64} by generating the
corresponding new instructions in Power10: brh, brd and brw and
adds a verification test for the same.
On Power 9 and 8, the .go code performs optimally as it is.
Performance improvement seen on Power10:
ReverseBytes32 1.38ns ± 0% 1.18ns ± 0% -14.2
ReverseBytes64 1.52ns ± 0% 1.11ns ± 0% -26.87
ReverseBytes16 1.41ns ± 1% 1.18ns ± 0% -16.47
Change-Id: I88f127f3ab9ba24a772becc21ad90acfba324b37
Reviewed-on: https://go-review.googlesource.com/c/go/+/446675
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Since CL 454836, cmd/dist has built the packages in 'cmd' with
different settings than those in 'std': namely, for' cmd' we disable
the use of cgo, and (since CL 463740) if GO_BUILDER_NAME is non-empty
or the VERSION file indicates a release version we also set
GOFLAGS=-trimpath.
However, since at least CL 73212 the staleness checks performed by
cmd/dist for the “toolchain” targets (a subset of 'cmd') have included
the package "runtime/internal/sys" (which is in 'std', not 'cmd').
At that time, cmd/go did not have a separate build cache, so it would
not have been possible to check staleness for a 'cmd' build differently
from 'std'. However, now that is possible, and most of the time
"runtime/internal/sys" lives *only* in the build cache (and so is
essentially never stale after building anything that imports it).
But there is one more wrinkle: if GODEBUG=installgoroot=all is set,
the packages in 'std' are still installed to GOROOT/pkg, and can once
again become stale. Since the install with the 'std' configuration does
not match the configuration used to build 'cmd', the staleness check
fails for "runtime/internal/sys" under the 'cmd' configuration.
Since we intentionally build the toolchain with a different
"runtime/internal/sys" stored only in the build cache, there is no
longer a point in checking that package for staleness: if it is stale,
then the toolchain itself will be reported as stale anyway.
So we can simply remove the package from that staleness check,
and unbreak bootstrapping with GODEBUG=installgoroot=all.
I tested this manually using the sequence:
export GODEBUG=installgoroot=all
export GO_BUILDER_NAME=linux-amd64-bcmills
./make.bash
It fails the staleness check before this change, and successfully
builds after.
For #24904.
Change-Id: I376e93e35129694a093c6675e20905a097a8b64b
Reviewed-on: https://go-review.googlesource.com/c/go/+/465155
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Using generics here makes the code easier to understand,
as the contract is clearly specified. It also makes the
code a little more concise, as it's easy to write a wrapper
for the cache that adds an error value, meaning that
a bunch of auxilliary types no longer need to be defined
for this common case.
The load.cachingRepo code has been changed to use a separate
cache for each key-value type combination, which seems a bit less
sleazy, but might have some knock-on effect on memory usage,
and could easily be changed back if desired.
Because there's no longer an unambiguous way to find out
whether there's an entry in the cache, the Cache.Get method
now returns a bool as well as the value itself.
Change-Id: I28443125bab0b3720cc95d750e72d28e9b96257d
Reviewed-on: https://go-review.googlesource.com/c/go/+/463843
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: roger peppe <rogpeppe@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This change implements infer2 which is a drop-in replacement for
infer; it can be enabled by setting the useNewTypeInference flag
in infer2.go. It is currently disabled (but tested manually).
infer2 uses the same machinery like infer but in a simpler approach
that is more amenable to precise description and future extensions.
The goal of type inference is to determine a set of (missing) type
arguments from a set of other given facts. Currently, these other
facts are function arguments and type constraints.
In the following, when we refer to "type parameters", we mean the
type parameters defined by the generic function to which we apply
type inference. More precisely, in the algorithm, these are the
type parameters recorded with the unifier.
The approach is as follows:
- A single unifier is set up which tracks all type parameters and
corresponding inferred types.
- The unifier is then fed all the facts we have. The order is not
relevant (*) except that we use default types of untyped constant
arguments only as a last resort, at the end.
- We start with all function arguments: for each generic function
parameter with a typed function argument, we unify the parameter
and function type.
- We then unify each type parameter with its type constraint.
This step is iterated until nothing changes anymore, because
each unification may enable further unification.
- If there are any type parameters left without inferred types,
and which are used as function parameters with untyped constant
arguments, unify them with the default types of those arguments.
Because of unification with constraints which themselves may contain
type parameters, inferred types may contain type parameters. Thus,
in a final step we substitute type parameters for their inferred types
until there are no type parameters left in the inferred types.
All these individual steps are the same as in infer, but there is no
need to do constraint type inference twice (all the facts have already
been used for inference). Also, we only need a single unifier which
serves as the holder for the inferred type parameter types.
Type inference fails if any unification step fails or if not all
type arguments could be inferred. By always using all available
facts (**) we ensure that order doesn't matter.
By using more facts, type inference can now be extended to become
more powerful.
The code can be split up into smaller components that are more
easily digestable. Because we forsee more simplifications, we
defer such cleanups to later CLs.
(*) We currently have a sorting phase in the beginning such that
function argument types that are named types are used before
any other type. We believe this step can be eliminated by
modifying the unifier slightly.
(**) When unifying constraints, in some cases we don't report
an error if unification fails. We believe we can modify the
unifier and then consistently report an inference failure
in this case as well.
Change-Id: If1640a5461bc102fa7fd31dc6e741be667c97e7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/463746
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Because unification is symmetric, in cases where we have symmetric
code for x and y depending on some property we can swap x and y as
needed and simplify the code.
Also, change u.depth increment/decrement position for slightly
nicer tracing ooutput.
Change-Id: I2e84570d463d1c32f6556108f3cb54062b57c718
Reviewed-on: https://go-review.googlesource.com/c/go/+/464896
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This makes it easier to configure the behavior of identical: we can
simply add fields to the comparer instead of adding more parameters
to identical.
Change-Id: I9a6f5451b3ee5c37e71486060653c5a6e8f24304
Reviewed-on: https://go-review.googlesource.com/c/go/+/464937
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Prior to CL 456116 we had an arbitrary 5-second delay after a test
times out before we kill the test. In CL 456116, I reused that
arbitrary 5-second delay as the WaitDelay as well, but on slower
builders it does not seem to be generous enough.
Instead of hard-coding the delay, for tests with a finite timout we
now use a hard-coded fraction of the overall timeout. That will
probably give delays that are longer than strictly necessary for very
long timeouts, but if the user is willing to wait for a very long
timeout they can probably wait a little longer for I/O too.
Fixes#58230.
Updates #24050.
Change-Id: Ifbf3e576c034c721aa00cd17bf88563474b09955
Reviewed-on: https://go-review.googlesource.com/c/go/+/464555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This test previously failed if running a new pthread took longer than
a hard-coded 100ms. On some slow or heavily-loaded builders, that
scheduling latency is too short.
Since the point of this test is to verify that the background thread
is not reused after it terminates (see #20395), the arbitrary time
limit does not seem helpful: if the background thread fails to
terminate the test will time out on its own, and if the main goroutine
is scheduled on the background thread the test will fail regardless of
how long it takes.
Fixes#58247.
Change-Id: I626af52aac55af7a4c0e7829798573c479750c20
Reviewed-on: https://go-review.googlesource.com/c/go/+/464735
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Instead, have the caller pass in an explicit list of the packages
(if any) they need.
After #47257, a builder running a test does not necessarily have the
entire standard library already cached, especially when running tests
in sharded mode. testenv.WriteImportcfg used to write an importcfg for
the entire standard library — which required rebuilding the entire
standard library — even though most tests need only a tiny subset.
This reduces the time to test internal/abi with a cold build cache on
my workstation from ~16s to ~0.05s.
It somewhat increases the time for 'go test go/internal/gcimporter'
with a cold cache, from ~43s to ~54s, presumably due to decreased
parallelism in rebuilding the standard library and increased overhead
in re-resolving the import map. However, 'go test -short' running time
remains stable (~5.5s before and after).
Fixes#58248.
Change-Id: I9be6b61ae6e28b75b53af85207c281bb93b9346f
Reviewed-on: https://go-review.googlesource.com/c/go/+/464736
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
For a given Addr, ensure there is exactly one invalid representation.
This allows invalid representations to be safely comparable.
To ensure that the zero value of Prefix is invalid,
we modify the encoding of bits to simply be the bit count plus one.
Since Addr is immutable, we check in the PrefixFrom constructor that
the provided Addr is valid and only store a non-zero bits length if so.
IsValid is simplified to just checking whether bitsPlusOne is non-zero.
Fixes#54525
Change-Id: I9244cae2fd160cc9c81d007866992df2e422d3b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/425035
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
If you use an external linker with --gc-sections, nothing refers
to .go.buildinfo, so the section is deleted, which in turns makes
'go version' fail on the binary. It is important for vulnerability
scanning and the like to be able to run 'go version' on any binary.
Fix this by inserting a reference to .go.buildinfo from the rodata
section, which will not be GC'ed.
Fixes#58222.
Change-Id: I1e13e9464acaf2f5cc5e0b70476fa52b43651123
Reviewed-on: https://go-review.googlesource.com/c/go/+/464435
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
When coming from C, the bitwise integer complement (bitwise negation)
operator is ~, but in Go it is ^. Report an error mentioning ^ when
~ is used with an integer operand.
Background: Some articles on the web claim that Go doesn't have a
bitwise complement operator.
Change-Id: I41185cae4a70d528754e44f42c13c013ed91bf27
Reviewed-on: https://go-review.googlesource.com/c/go/+/463747
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Allocate all handles up-front: in a correct program, all type parameters
must be resolved and thus eventually will get a handle.
Also, sharing of handles caused by unified type parameters is rare and
so it's ok to not optimize for that case (and delay handle allocation).
This removes a (premature) optimization whis further simplifies
unification.
Change-Id: Ie1259b86ea5e966538667ab9557676e9be9f6364
Reviewed-on: https://go-review.googlesource.com/c/go/+/463989
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Further simplify the unifier by using a mapping from type parameter
to type (argument) handle, where a handle is just an indirection to
the actual type associated with the type parameter.
If multiple type parameters are "joined", i.e., share the same type
(argument), then they use the same handle. Thus, if one of the type
parameters gets a type, all type parameters sharing the same handle
get the same type.
The handles mapping replaces the indices list (mapping from type
parameter index to types index). Because each handle holds any
associated type directly, we also don't need a types list anymore.
We still keep the incoming type parameter list to maintain the same
order for printing and reporting inferred types. We may be able to
eliminate this list as well in future CLs.
Change-Id: I389527dbb325b828c91050e59902ae546c3d0347
Reviewed-on: https://go-review.googlesource.com/c/go/+/463228
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When scheduling a block, deprioritize values whose results aren't used
until subsequent blocks.
For #58166, this has the effect of pushing the induction variable increment
to the end of the block, past all the other uses of the pre-incremented value.
Do this only with optimizations on. Debuggers have a preference for values
in source code order, which this CL can degrade.
Fixes#58166Fixes#57976
Change-Id: I40d5885c661b142443c6d4702294c8abe8026c4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/463751
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 463975 replaced the use of the NodeJS crypto.randomFillSync API
with a direct call to crypto.getRandomValues. This function rejects
any requests to fill a buffer larger than 65536 bytes, so we need to
batch reads larger than this size. This reuses the batching
functions used on other platforms to perform this batching.
Fixes#58145
Change-Id: Ic0acf3be7c9e994bc345d6614867c9b0c47bd26d
Reviewed-on: https://go-review.googlesource.com/c/go/+/463993
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
This CL removes a fallback that used LoadLibraryA when the runtime
was loading system DLLs on Windows 7, Windows Server 2008 R2,
or earlier.
We can safely remove that fallback now, as go1.21 will require at least
Windows 8 or Server 2012.
This CL also saves some syscall initialization time and bytes:
new:
init syscall @2.3 ms, 0 ms clock, 1000 bytes, 18 allocs
old:
init syscall @3.6 ms, 0.52 ms clock, 1744 bytes, 24 allocs
Updates #57003
Change-Id: I7dcc1173537785b6b580e9f78632c0c74da658d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/463842
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
Adding a file path separator is incorrect for a file path that may be
the root directory on a Unix platform (such as in a container or
chroot).
Adding a path separator is incorrect for a package path prefix that
may be the empty string (as in the "std" module in GOROOT/src).
And in both cases, a Join function is arguably clearer and simpler
anyway.
Fixes#51506 (maybe).
Change-Id: Id816930811ad5e4d1fbd206cddf219ecd4ad39a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/463178
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
In external linking mode, when the external linker fails to handle
something in a host object file, it usually reports the name of
the host object which is a copied file named 000NNN.o. This is
often not helpful to determine what file it is. Add some debug
print so at least in -v mode it is more helpful.
Change-Id: Ibe762bff6a25640d16ee0dc082736ba5161b7522
Reviewed-on: https://go-review.googlesource.com/c/go/+/458735
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The namespace defined by xmlns="value" can be overridden in every included tag
by the empty namespace xmlns="" without a prefix.
Method to calculate indent of XML handles depth of tag and its associated namespace is
still active even when no indent is required.
An XMLName field in a struct means that namespace must be enforced even if empty.
This occurs only on an inner tag as an override of any non-empty namespace of its outer tag.
An attribute is added to have the required namespace display.
Fixes#7113
Change-Id: I57f2308e98c66f04108ab136d350bdc3a6091e98
Reviewed-on: https://go-review.googlesource.com/c/go/+/108796
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
CopyBuffer allocates a 32k buffer when no buffer is available.
Allocate these buffers from a sync.Pool.
This removes an optimization where the copy buffer size was
reduced when the source is a io.LimitedReader (including the
case of CopyN) with a limit less than the default buffer size.
This change could cause a program which only uses io.Copy
with sources with a small limit to allocate unnecessarily
large buffers. Programs which care about the transient
buffer allocation can avoid this by providing their own buffer.
name old time/op new time/op delta
CopyNSmall-10 165ns ± 7% 117ns ± 7% -29.19% (p=0.001 n=7+7)
CopyNLarge-10 7.33µs ±34% 4.07µs ± 2% -44.52% (p=0.001 n=7+7)
name old alloc/op new alloc/op delta
CopyNSmall-10 2.20kB ±12% 1.20kB ± 4% -45.24% (p=0.000 n=8+7)
CopyNLarge-10 148kB ± 9% 81kB ± 4% -45.26% (p=0.000 n=8+7)
name old allocs/op new allocs/op delta
CopyNSmall-10 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.000 n=8+8)
CopyNLarge-10 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.000 n=8+8)
For #57202
Change-Id: I2292226da9ba1dc09a2543f5d74fe5da06080d49
Reviewed-on: https://go-review.googlesource.com/c/go/+/456555
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Thomas Austad <thomas.austad@gmail.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This CL instructs the Go x86 compiler to load the frame pointer address
using a MOV instead of a LEA instruction, being MOV 1 byte shorter:
Before
55 PUSHQ BP
48 8d 2c 24 LEAQ 0(SP), BP
After
55 PUSHQ BP
48 89 e5 MOVQ SP, BP
This reduces the size of the Go toolchain ~0.06%.
Updates #6853
Change-Id: I5557cf34c47e871d264ba0deda9b78338681a12c
Reviewed-on: https://go-review.googlesource.com/c/go/+/463845
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This synchronizes the supported build modes between cmd/dist and
internal/platform, and adds a test to keep them in synch.
In order to do that, this has several changes to cmd/dist, and one
change to internal/platform.
If the build dashboard is green after this is submitted, we can
probably make the functions identical.
Change-Id: Ia78ce76b193399058fde79e38dd9f23818e566a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/463992
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Make all the tests for whether -buildmode=c-archive is supported consistent.
Base this on the historical code, on whether cmd/compile supports -shared,
and whether cmd/link permits the mode.
Change-Id: Ib996546906f698ade4c32b8e6c705838e4ad4b90
Reviewed-on: https://go-review.googlesource.com/c/go/+/463984
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This error dates back to when the method was introduced in CL 6531.
It only matters for the rare case of building tests on one GOOS and
running them on another, and only makes a difference for the rare case
where one GOOS supports external linking and another does not.
Change-Id: I1a7abfb0a5bbec49ddbcd9c1a4f5c0ec43a8095c
Reviewed-on: https://go-review.googlesource.com/c/go/+/463991
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
The strconv docs are not very helpful for people who just want to pick
a reasonable default, for example the one used by the fmt package to
show floats.
Add an example illustrating what the fmt package uses.
Change-Id: Iefefa70dfd4d4bfa9962a20654ee23662818ef38
Reviewed-on: https://go-review.googlesource.com/c/go/+/463980
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Also set it on the Go builders, so that the builders more closely
match releases.
It looks like this change was intended to be included in CL 454836,
but was commented out at some point — perhaps during debugging? —
before that change was merged.
For #24904.
Change-Id: Ib501274520c5de366d4e9d87a1bd3c6ba2d2413f
Reviewed-on: https://go-review.googlesource.com/c/go/+/463740
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
For internal linking, at the point where we finish reading libgcc.a,
if the symbol "__stack_chk_local" is still undefined, then read
in the host archive libc_nonshared.a as well.
Updates #57261.
Change-Id: I0b1e485aa50aa7940db8cabcb3b9a7959bf99ce7
Reviewed-on: https://go-review.googlesource.com/c/go/+/456856
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Certain ios and android configurations do not yet support internal
linking.
On ios, attempting to build without cgo causes tests to fail on
essentially every run (#57961).
On android, it produces a lot of warning spam from the linker,
obscuring real problems.
Since external linking makes the result of `go install` depend on the
installed C toolchain either way, the reproducibility benefit of
disabling cgo seems minimal on these platforms anyway.
Fixes#57961.
For #24904.
Updates #57007.
Change-Id: Ied2454804e958dd670467db3d5e9ab50a40bb899
Reviewed-on: https://go-review.googlesource.com/c/go/+/463739
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Bryan Mills <bcmills@google.com>
This CL changes how the x86 compiler stores and loads the frame pointer
on each function prologue and epilogue, with the goal to reduce the
final binary size without affecting performance.
The compiler is currently using MOV instructions to load and store BP,
which can take from 5 to 8 bytes each.
This CL changes this approach so it emits PUSH/POP instructions instead,
which always take only 1 byte each (when operating with BP). It can also
avoid using the SUBQ/ADDQ to grow the stack for functions that have
frame pointer but does not have local variables.
On Windows, this CL reduces the go toolchain size from 15,697,920 bytes
to 15,584,768 bytes, a reduction of 0.7%.
Example of epilog and prologue for a function with 0x10 bytes of
local variables:
Before
===
SUBQ $0x18, SP
MOVQ BP, 0x10(SP)
LEAQ 0x10(SP), BP
... function body ...
MOVQ 0x10(SP), BP
ADDQ $0x18, SP
RET
===
After
===
PUSHQ BP
LEAQ 0(SP), BP
SUBQ $0x10, SP
... function body ...
MOVQ ADDQ $0x10, SP
POPQ BP
RET
===
Updates #6853
Change-Id: Ice9e14bbf8dff083c5f69feb97e9a764c3ca7785
Reviewed-on: https://go-review.googlesource.com/c/go/+/462300
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
This will be part of the standard library soon and then
cmd/go can use it directly, but I am writing a few more instances
of this pattern today and wanted to clean these up first.
Change-Id: I3a7336039949ffe95a403aed08d79206c91eafb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/464115
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
For #56986, add the new directive analyzer that catches
misplaced //go:debug lines.
Ran 'go mod vendor' after adding the import in vet
to bring in the vendored files.
A followup CL will enable it by default in 'go test'.
Change-Id: I12c46e292b31bdbf5ceb86ba4474545e78a83a47
Reviewed-on: https://go-review.googlesource.com/c/go/+/462201
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
NodeJS 18 introduced support for the fetch API for
making HTTP requests. This broke all wasm tests
that were relying on NodeJS falling back to the fake
network implementation in net_fake.go. Disable
the fetch API on NodeJS to get tests passing.
Fixes#57613
Change-Id: Icb2cce6d5289d812da798e07366f8ac26b5f82cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/463976
Reviewed-by: Evan Phoenix <evan@phx.io>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The purpose of building the host toolchain is so that we can use it to
build and test the target configuration.
The host configuration should already be tested separately (with its
own builder), so we do not need to build the parts of that
configuration that are not relevant to the task of building and
testing the target configuration.
Updates #47257.
Change-Id: I814778d2d65b1f2887c9419232b5bfd4068f58af
Reviewed-on: https://go-review.googlesource.com/c/go/+/461676
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Since packages in "std" no longer have install targets, checking them
for staleness is somewhat meaningless: if they are not cached they
will be rebuilt anyway, and without installed archives against which
we can compare them the staleness check will not detect builder skew.
It would still be meaningful to check "cmd" for staleness, but
(especially on sharded VM-based builders) that is a fairly expensive
operation relative to its benefit. If we are really interested in
detecting builder skew and/or build reproducibility, we could instead
add a "misc" test (similar to "misc/reboot", or perhaps even a part of
that test) that verifies that bootstrapped binaries are reproducible.
For #57734.
Updates #47257.
Updates #56896.
Change-Id: I8683ee81aefe8fb59cce9484453df9729bdc587c
Reviewed-on: https://go-review.googlesource.com/c/go/+/452775
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Austin Clements <austin@google.com>
go get golang.org/x/tools@ff9bea528a4d (CL 462817, 2023-01-19)
go mod tidy
go mod vendor
This sets up for using passes/directive in cmd/vet
(that CL will add those actual files, with a new go mod vendor).
Note that it also brings in golang.org/x/sys@17fce3a (CL 463675, 2023-01-26),
to get v0.4.0 with the bug fixed in that CL to keep the build working.
The update of x/sys is in both std and cmd to keep them in sync.
Change-Id: If8528f4667d14e674b986830abd41a7c733a3969
Reviewed-on: https://go-review.googlesource.com/c/go/+/462200
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
PutAbstractFunc doesn't use FnState.Filesym, so it isn't needed, but
more importantly it is misleading. DwarfAbstractFunc is frequently used
on inlined functions from outside the current compilation unit. For
those function, ctxt.fileSymbol returns nil, meaning it probably isn't
safe to use if the original compilation unit could also generate an
abstract func with the correct file symbol.
Change-Id: I0e6c76e41d75ac9ca07e0f775e49d791249e1c5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/458198
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
This test set is a bit hard to follow due to trying to test both
variable and function declaration location information.
Now that we have additional helpers to avoid duplication, it isn't too
much work to split them up into individually more understandable tests.
Change-Id: I619ac82ac3b5d00683e22a4a2064e2a5b15e8ce9
Reviewed-on: https://go-review.googlesource.com/c/go/+/458197
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Many tests build a program just to analyze it with dwtest.Examiner. Add
gobuildAndExamine, a helper that returns Examiner directly to reduce
duplication in these tests.
Many tests also lookup the DIE for a specific subprogram, which includes
several verification steps. Package those up in findSubprogramDIE.
Change-Id: I72202ba289ae8389b682be525ff7e6cfbfc00ff3
Reviewed-on: https://go-review.googlesource.com/c/go/+/458196
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The two crypto modules are both named "asm". If both are included in a
single go.work (e.g., from `go work use -r .` in the repo), builds break
from "module asm appears multiple times in workspace".
Give these modules fully-qualified names to avoid conflicts. While we
are here, also expand the name of two other testdata modules. Those
modules don't currently conflict, but they have vague names at risk of
future conflicts.
Fixes#57769.
Change-Id: I2bd8a505051e92348d49560ec698ed921f2c81be
Reviewed-on: https://go-review.googlesource.com/c/go/+/461896
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
DW_AT_decl_line provides the line number of function declarations (the
line containing the func keyword). This is the equivalent to CL 429638,
but provided via DWARF.
Note that the file of declarations (DW_AT_decl_file) is already provided
for non-inlined functions. It is omitted for inlined functions because
those DWARF subprograms may be generated outside of their source
compilation unit, where referencing the file table is difficult.
Fixes#57308.
Change-Id: I3ad12e1f366c4465c2a588297988a5825ef7efec
Reviewed-on: https://go-review.googlesource.com/c/go/+/458195
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Zeroing requires a non-K0 mask register be specified.
(gcc enforces this when assembling.)
The non-K0 restriction is already handled by the Yknot0 restriction.
But if the mask register is missing altogether, we misassemble the
instruction.
Fixes#57952
Not sure if this is really worth mentioning in the release notes,
but just in case I'll mark it.
RELNOTE=yes
Change-Id: I8f05d3155503f1f16d1b5ab9d67686fe5b64dfea
Reviewed-on: https://go-review.googlesource.com/c/go/+/463229
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Илья Токарь <tocarip@gmail.com>
Reviewed-by: Iskander Sharipov <quasilyte@gmail.com>
CL 463219 broke TestAllDependencies because zsyscall_windows.go
was not correctly formatted, probably edited by hand.
The failure was not catch by the CL builders because it is
only failing on linux longtests builders, which was not executed.
Windows builders skip that test because it lacks of the `diff` command.
Change-Id: Id02992d71be2db7e9d3d169545679ab957f3be7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/463841
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL sets the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS notification mode
for all udp and tcp networks.
When SetFileCompletionNotificationModes was implemented, back in
go 1.2 [1], it was not possible to enable this mode on udp connections
because it is buggy on Windows 7 and earlier. The bug was fixed on
Windows 8. We can safely enable this mode now, since go 1.21
will require Windows 10 or higher.
While here, I noticed that this mode is only enabled for tcp, but not
for tcp4 nor tcp6. I don't think this restriction makes sense, so I'm
lifting it.
The performance gains are relevant:
name old time/op new time/op delta
ReadWriteMsgUDPAddrPort-12 13.3µs ± 4% 11.2µs ± 8% -15.90% (p=0.000 n=10+9)
WriteToReadFromUDP-12 14.5µs ±18% 11.4µs ± 4% -21.35% (p=0.000 n=10+9)
WriteToReadFromUDPAddrPort-12 13.4µs ± 3% 11.0µs ± 2% -18.00% (p=0.000 n=10+9)
[1] https://codereview.appspot.com/12409044
Change-Id: Idf41c35898beceac39d21decb47910f7d8ac247b
Reviewed-on: https://go-review.googlesource.com/c/go/+/463839
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This generates GetTempPath2. Go now tries to determine if the windows it runs on has GetTempPath2 by finding it only once at the loading time. If GetTempPath2 exists, it sets the flag so that any calls to tempDir will use it. If it doesn't exist, Go then uses GetTempPath.
GetTempPath2 was generated into internal/syscall/windows since syscall is locked down.
Fixes#56899
Change-Id: Iff08502aebc787fde802ee9496c070c982fbdc08
GitHub-Last-Rev: b779389534
GitHub-Pull-Request: golang/go#57980
Reviewed-on: https://go-review.googlesource.com/c/go/+/463219
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
On Windows the registry data type REG_EXPAND_SZ indicates that the string requires expansion
of environment variables. The existing implementation doesn't take that into consideration
and just returns the unexpanded string, ignoring the registry type. This implementation ensures
that environment variables are properly expanded when needed.
Fixes#57576
Change-Id: Ia02c1b05a4cf6eaaffb3be88ce1c9ee100db250f
Reviewed-on: https://go-review.googlesource.com/c/go/+/460535
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
ir.VisitFuncsBottomUp returns recursive==true for functions which
call themselves. It also returns any closures inside that function.
We don't want to report the closures as recursive, as they really
aren't. Only the containing function is recursive.
Fixes#54159
Change-Id: I3b4d6710a389ec1d6b250ba8a7065f2e985bdbe1
Reviewed-on: https://go-review.googlesource.com/c/go/+/463233
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Manually consolidate the remaining ppc64/ppc64le test which
are not so trivial to automatically merge.
The remaining ppc64le tests are limited to cases where load/stores are
merged (this only happens on ppc64le) and the race detector (only
supported on ppc64le).
Change-Id: I1f9c0f3d3ddbb7fbbd8c81fbbd6537394fba63ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/463217
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Use a small python script to consolidate duplicate
ppc64/ppc64le tests into a single ppc64x codegen test.
This makes small assumption that anytime two tests with
for different arch/variant combos exists, those tests
can be combined into a single ppc64x test.
E.x:
// ppc64le: foo
// ppc64le/power9: foo
into
// ppc64x: foo
or
// ppc64: foo
// ppc64le: foo
into
// ppc64x: foo
import glob
import re
files = glob.glob("codegen/*.go")
for file in files:
with open(file) as f:
text = [l for l in f]
i = 0
while i < len(text):
first = re.match("\s*// ?ppc64(le)?(/power[89])?:(.*)", text[i])
if first:
j = i+1
while j < len(text):
second = re.match("\s*// ?ppc64(le)?(/power[89])?:(.*)", text[j])
if not second:
break
if (not first.group(2) or first.group(2) == second.group(2)) and first.group(3) == second.group(3):
text[i] = re.sub(" ?ppc64(le|x)?"," ppc64x",text[i])
text=text[:j] + (text[j+1:])
else:
j += 1
i+=1
with open(file, 'w') as f:
f.write("".join(text))
Change-Id: Ic6b009b54eacaadc5a23db9c5a3bf7331b595821
Reviewed-on: https://go-review.googlesource.com/c/go/+/463220
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We currently check for at least three different permission bits before
running tests that require root permissions: we look for UID 0, lack
of an LXC container, and lack of a Docker container, and probe a
number of distro-specific files in /proc and /sys.
The sheer number of these checks suggests that we have probably missed
at least one. Per Alan J. Perlis, “If you have a procedure with ten
parameters, you probably missed some.” (And, indeed, we definitely
have: a Debian patch¹ adds one more environment check!)
CL 58170 added some of these container checks, but “decided to go this
way instead of just skipping os.IsPermission errors because many of
those tests were specifically written to check false positive
permission errors.” However, we can't in general distinguish between a
false-positive error and a real one caused by a container: if one is
making a change to the syscall package, they should run the tests with
-v and check for unexpected skips.
Notably:
- TestUnshare already skips itself if the command fails with an error
ending in the string "operation not permitted", which could be caused
by a variety of possible bugs.
- The Unshare tests added in CL 38471 will fail with a permission
error if CLONE_NEWNS is not supported, but it seems to me that if
CLONE_NEWNS is supported — sufficient to start the process! — then
Unmount must also be supported, and the test can at least check that
the two are consistent.
- The AmbientCaps tests should fail to start the subprocess with
EINVAL or similar (not produce bogus output) if the kernel does not
support ambient caps for any reason, which we can then detect.
(If the subprocess fails in the way the test is concerned about, it
will exit with status 2, not fail to start in the first place.)
By executing the system calls and checking for permission errors,
this change exposed an existing bug for AmbientCaps (filed as #57208),
which was detected by the linux-arm-aws builder.
For #57208.
Updates #21379.
Updates #14693.
¹https://sources.debian.org/patches/golang-1.19/1.19.3-1/0006-skip-userns-test-in-schroot-as-well.patch/
Change-Id: I9b167661fa1bb823168c8b50d8bbbf9643e49f76
Reviewed-on: https://go-review.googlesource.com/c/go/+/456375
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Alexander Morozov <lk4d4math@gmail.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
hex.Decode never checks the length of dst and triggers a panic
if there are insufficient bytes in the slice.
There isn't document on what the behavior *should* be in this case.
Two possibilities:
1. Error dst has insufficient space (as done in this change)
2. Reduce the length of the decode to min(dst, src)
Option 1 was chosen because it seems the least surprising or
subtle.
Change-Id: I3bf029e3d928202de716830434285e3c165f26dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/461958
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Benjamin Prosnitz <bprosnitz@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
The unifier was written such that it was possible to specify
a different set of type parameters (declared by different
generic declarations) for each type x, y being unified,
to allow for what is called "bidirectional unification"
in the documentation (comments).
However, in the current implementation, this mechanism is
not used:
- For function type inference, we only consider the
type parameter list of the generic function (type parameters
that appear in the arguments are considered stand-alone types).
We use type parameter renaming to avoid any problems in case
of recursive generic calls that rely on type inference.
- For constraint type inference, the type parameters for the
types x and y (i.e., the type parameter and its constraint)
are the same and had to be explicitly set to be identical.
This CL removes the ability to set separate type parameter
lists. Instead a single type parameter list is used during
unification and is provided when we initialize a unifier.
As a consequence, we don't need to maintain the separate
tparamsList data structure: since we have a single list
of type parameters we can keep it directly in the unifier.
Adjust all the unifier code accordingly and update comments.
As an aside, remove the `exact` flag from the unifier as it
was never set. However, keep the functionality for now and
use a constant (exactUnification) instead. This makes it
easy to find the respectice code without incurring any cost.
Change-Id: I969ba6dbbed2d65d06ba4e20b97bdc362c806772
Reviewed-on: https://go-review.googlesource.com/c/go/+/463223
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL simplifies and removes some old noding code, which isn't
necessary any more.
Most notably, we no longer need separate posMaps for each noder,
because noders are only used for parsing now. Before we started using
types2, noders were also responsible for constructed (untyped) IR, so
posMaps were necessary to translate syntax.Pos into src.XPos.
Change-Id: Ic761abcd727f5ecefc71b611635a0f5b088c941f
Reviewed-on: https://go-review.googlesource.com/c/go/+/463738
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
To simplify backend analysis, we normalize variadic and method calls:
variadic calls are rewritten with an explicit slice argument, and
method calls are turned into function calls that pass the receiver
argument as the first parameter.
But because we've been supporting multiple frontends, this
normalization was scattered in various later passes. Now that we're
back to just one frontend, we can move the normalization forward into
typecheck (where most other IR normalization already happens).
Change-Id: Idd05ae231fc180ae3dd1664452414f6b6d578962
Reviewed-on: https://go-review.googlesource.com/c/go/+/463737
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
All the Lookup* methods that resolve hostnames eventually call lookupIP
or lookupHost method. When the order is selected to be hostLookupCGO
then lookupHost calls cgoLookupHost which internally calls cgoLookupIP
(the lookupIP directly calls cgoLookupIP).
When we provide a context that is cancelled after cgo call, then the
cgoLookupIP returns completed == false, which caues the
lookupIP/lookupHost to fallback to the go resolver.
This fallback is unnecessary because our context is already cancelled.
The same thing can happen to LookupAddr.
Change-Id: Ifff7716c461f05d954ef43b5205865103558b410
GitHub-Last-Rev: 2ef2023e8c
GitHub-Pull-Request: golang/go#57042
Reviewed-on: https://go-review.googlesource.com/c/go/+/454696
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Unified IR generates uniform IR for "a, b = f()" to be able to insert
implicit conversion expressions, but the result is somewhat more
verbose and trips up the inliner's naive cost metrics.
The hairyVisitor.doNode method was already adjusted to account for
this, but isBigFunc needs the same adjustment.
Fixes#57563.
Change-Id: Ia8d86a6e314ec60190c78f40ace4fb30dadc4413
Reviewed-on: https://go-review.googlesource.com/c/go/+/460395
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also remove existing special cases that transform "go" into
gorootBinGo, because they make debugging and code-reviews more
difficult: log messages that don't include the full path can mask bugs
like #31567, and the reader of the code has to trace through the
various call chains to verify that the correct "go" is being used.
Instead, we can make the use of the correct "go" command plainly
obvious in the code by using one consistent name for it.
(Prior to this CL, we had three different names for it:
gorootBinGo, "go", and cmdGo. Now we have only one.
Updates #31567.
Change-Id: Ia9ff27e5e800c79af5a4e9f2803c9ea5ccafbf35
Reviewed-on: https://go-review.googlesource.com/c/go/+/452678
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Sym.Def used to be used for symbol resolution during the
old (pre-types2) typechecker. But since moving to types2-based IR
construction, we haven't really had a need for Sym.Def to ever refer
to anything but the package-scope definition, because types2 handles
symbol resolution for us.
This CL finally removes the Markdcl/Pushdcl/Popdcl functions that have
been a recurring source of issues in the past.
Change-Id: I2b012a0f17203efdd724ebd1e9314bd128cc2d61
Reviewed-on: https://go-review.googlesource.com/c/go/+/458625
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This CL removes a handful of features that were only needed for the
pre-unified frontends.
In particular, Type.Pkg was a hack for iexport so that
go/types.Var.Pkg could be precisely populated for struct fields and
signature parameters by gcimporter, but it's no longer necessary with
the unified export data format because we now write export data
directly from types2-supplied type descriptors.
Several other features (e.g., OrigType, implicit interfaces, type
parameters on signatures) are no longer relevant to the unified
frontend, because it only uses types1 to represent instantiated
generic types.
Updates #57410.
Change-Id: I84fd1da5e0b65d2ab91d244a7bb593821ee916e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/458622
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
These were used by the nounified frontend for representing
uninstantiated generic types; however, the unified frontend only needs
types1 to represent instantiated types.
Updates #57410.
Change-Id: Iac417fbf2b86f4e08bd7fdd26ae8ed17395ce833
Reviewed-on: https://go-review.googlesource.com/c/go/+/458621
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the types1 universe under the unified frontend, we never need to
worry about type parameter constraints, so we only see pure
interfaces. However, we might still see interfaces that contain union
types, because of interfaces like "interface{ any | int }" (equivalent
to just "any").
We can handle these without needing to actually represent type unions
within types1 by simply mapping any union to "any".
Updates #57410.
Change-Id: I5e4efcf0339edbb01f4035c54fb6fb1f9ddc0c65
Reviewed-on: https://go-review.googlesource.com/c/go/+/458619
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Before this CL, the comment used the case of a recursive generic
function call as an example for uni-directional unification.
However, such cases are now more generally (and correctly) addressed
through renaming of the type parameters.
Change-Id: I69e94f53418e1fb4ca9431aeb27c639c40d19b09
Reviewed-on: https://go-review.googlesource.com/c/go/+/463735
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL marks some darwin assembly functions as NOFRAME to avoid relying
on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions
without stack were also marked as NOFRAME.
Change-Id: I797f3909bcf7f7aad304e4ede820c884231e54f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/460235
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Now that GOEXPERIMENT=nounified is removed, we can assume InlineCall
and HaveInlineBody will always be overridden with the unified
frontend's implementations. Similarly, we can assume expandDecl will
never be called.
This CL changes the code paths into Fatalfs, so subsequent CLs can
remove all the unreachable code.
Updates #57410.
Change-Id: I2a0c3edb32916c30dd63c4dce4f1bd6f18e07468
Reviewed-on: https://go-review.googlesource.com/c/go/+/458618
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This flag forced the compiler to eagerly type check all available
inline function bodies, which presumably was useful in the early days
of implementing inlining support. However, it shouldn't have any
significance with the unified frontend, since the same code paths are
used for constructing normal function bodies as for inlining.
Updates #57410.
Change-Id: I6842cf86bcd0fbf22ac336f2fc0b7b8fe14bccca
Reviewed-on: https://go-review.googlesource.com/c/go/+/458617
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The use of typecheck.Resolve was previously necessary to interoperate
with the non-unified frontend, because it hooked into iimport. It's no
longer necessary with unified IR, where we can just lookup the
".inittask" symbol and access Def directly.
Updates #57410.
Change-Id: I73bdfd53f65988ececd2b777743cd8b591a6db48
Reviewed-on: https://go-review.googlesource.com/c/go/+/458616
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
When we're compiling a resultInArg0 op, we need to clobber the
register containing the input value. So we first make a register copy
of the input value. We can then clobber either of the two registers
the value is in and still have the original input value in a register
for future uses.
Before this CL, we always clobbered the original, not the copy.
But that's not always the right decision - if the original is already
in a specific register that it needs to be in later (typically, a
return value register), clobber the copy instead.
This optimization can remove a mov instruction. It saves 1376 bytes
of instructions in cmd/go.
Redo of CL 460656, reverted at CL 463475, with a fix for s390x.
The new code just ensures that the copied value is in a register
which is a valid input register for the instruction.
Change-Id: Id570b8a60a6d2da9090de80a90b6bb0266e9e38a
Reviewed-on: https://go-review.googlesource.com/c/go/+/463221
Auto-Submit: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL removes the GOEXPERIMENT=nounified knob, and any conditional
statements that depend on that knob. Further CLs to remove unreachable
code follow this one.
Updates #57410.
Change-Id: I39c147e1a83601c73f8316a001705778fee64a91
Reviewed-on: https://go-review.googlesource.com/c/go/+/458615
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
ExampleWithDeadline and ExampleWithTimeout used an arbitrary 1-second
timeout for a “blocked” select case, which could fail if the test
goroutine happens to be descheduled for over a second, or perhaps if
an NTP synchronization happens to jump by a second at just the right
time.
Either case is plausible, especially on a heavily-loaded or slow
machine (as is often the case for builders for unusual ports).
Instead of an arbitrary timeout, use a “ready” channel that is never
actually ready.
Fixes#57594.
Change-Id: I9ff68f50b041a3382e7b267c28c5259e886a9d23
Reviewed-on: https://go-review.googlesource.com/c/go/+/460999
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Sameer Ajmani <sameer@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
The 1-second timeout on execution of this test is empirically too
short on some platforms. Rather than trying to tune the timeout, allow
the test to time out on its own (and dump goroutines) if it deadlocks.
Fixes#57993.
Fixes#57994.
Change-Id: I69ee86c75034469e4b4cd391b8dc5616b93468b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/463180
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
When we're compiling a resultInArg0 op, we need to clobber the
register containing the input value. So we first make a register copy
of the input value. We can then clobber either of the two registers
the value is in and still have the original input value in a register
for future uses.
Before this CL, we always clobbered the original, not the copy.
But that's not always the right decision - if the original is already
in a specific register that it needs to be in later (typically, a
return value register), clobber the copy instead.
This optimization can remove a mov instruction. It saves 1376 bytes
of instructions in cmd/go.
Change-Id: I162870c84b9a180da6715bb24c296a902974fed3
Reviewed-on: https://go-review.googlesource.com/c/go/+/460656
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
When calling a c library function, you discover that an error has
occurred, typically by looking at the return value of the function. Only
after that can you use errno to figure out the cause of the error.
Nothing about cgo changes that story -- you still have to look at the
result before checking the error that represents errno. If not you can
get false errors if the function happens to leak a non-zero errno.
Fix testpty to check errors correctly.
Change-Id: Idb95f8dd6a8ed63f653190c2e722e742cf50542b
Reviewed-on: https://go-review.googlesource.com/c/go/+/463397
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This also makes path/filepath.Walk more consistent between
Windows and POSIX platforms.
According to
https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/basedefs/V1_chap04.html#tag_04_12
symlinks in a path that includes a trailing slash must be resolved
before a function acts on that path.
POSIX defines an lstat function, whereas the Win32 API does not, so
Go's os.Lstat should follow the (defined) POSIX semantics instead of
doing something arbitrarily different.
CL 134195 added a test for the correct POSIX behavior when os.Lstat is
called on a symlink. However, the test turned out to be broken on Windows,
and when it was fixed (in CL 143578) it was fixed with different Lstat
behavior on Windows than on all other platforms that support symlinks.
In #50807 we are attempting to provide consistent symlink behavior for
cmd/go. This unnecessary platform difference, if left uncorrected,
will make that fix much more difficult.
CL 460595 reworked the implementation of Stat and Lstat on Windows,
and with the new implementation this fix is straightforward.
For #50807.
Updates #27225.
Change-Id: Ia28821aa4aab6cefa021da2d9b803506cdb2621b
Reviewed-on: https://go-review.googlesource.com/c/go/+/463177
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Update race_windows_amd64.syso to latest tsan (V3) runtime.
This version of the runtime depends on libsynchronization.a, so to
use this syso, you need to also be using a sufficiently up to date
version of GCC (notably GCC 5.1, installed on the Go windows builders
right now, does not include this library).
Updates #48231.
Updates #35006.
Fixes#49761.
Change-Id: Ia1e2b1d8fe7e2c99728150734935a2c522006caa
Reviewed-on: https://go-review.googlesource.com/c/go/+/420197
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The various forkAndExecInChild implementations have comments
explaining that they pre-declare variables to force allocations
to occur before forking, but then later use ":=" declarations
for additional variables.
To make it clearer that those ":=" declarations do not allocate,
we move their declarations up to the predeclared blocks.
For #57208.
Change-Id: Ie8cb577fa7180b51b64d6dc398169053fdf8ea97
Reviewed-on: https://go-review.googlesource.com/c/go/+/456516
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This helps simplify the noise when adding ppc codegen tests. ppc64x
is used in other places to indicate something which runs on either
endian.
This helps cleanup existing codegen tests which are mostly
identical between endian variants.
condmove tests are converted as an example.
Change-Id: I2b2d98a9a1859015f62db38d62d9d5d7593435b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/462895
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
https://go.dev/cl/460543 stopped using the "expect" parameter in
bootstrapType, but we forgot to actually remove it.
While here, staticcheck correctly points out that we can use the copy
builtin to fill builtinIdToTypeSlice, now that it and idToType are an
array and slice respectively.
Change-Id: I48078415ab9bdd5633cf41f33ab4dc78eb30b48a
Reviewed-on: https://go-review.googlesource.com/c/go/+/462301
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The existing implementation does a float64 to int64 conversion in order to check whether the number is odd, however it does not check for overflows. If an overflow occurs, the result is implementation-defined and while it happens to work on amd64 and i386, it produces an incorrect result on arm64 and possibly other architectures.
This change fixes that and also avoids calling isOddInt altogether if the base is +0, because it's unnecessary.
(I was considering avoiding the extra check if runtime.GOARCH is "amd64" or "i386", but I can't see this pattern being used anywhere outside the tests. And having separate files with build tags just for isOddInt() seems like an overkill)
Fixes#57465
Change-Id: Ieb243796194412aa6b98fac05fd19766ca2413ef
GitHub-Last-Rev: 3bfbd85c4c
GitHub-Pull-Request: golang/go#57494
Reviewed-on: https://go-review.googlesource.com/c/go/+/459815
Auto-Submit: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Bypass: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The importcycles method has not been useful since April 2016 when a large code deletion was performed.
The compiler itself provides some protection against import cycles, and the linker does import cycle detection in linksetup -> postorder.
For #57400
Change-Id: I3095bdb3f16a82ba25681bf4a20ceaa3c9613921
GitHub-Last-Rev: 87a46153b1
GitHub-Pull-Request: golang/go#57462
Reviewed-on: https://go-review.googlesource.com/c/go/+/459475
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
When -m=N (where N > 1) is in effect, include a note in the trace
output if a given function is considered "big" during inlining
analysis, since this causes the inliner to be less aggressive. If a
small change to a large function happens to nudge it over the large
function threshold, it can be confusing for developers, thus it's
probably worth including this info in the remark output.
Change-Id: Id31a1b76371ab1ef9265ba28a377f97b0247d0a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/460317
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Keith Randall <khr@google.com>
This CL updates File.readdir() on windows so it uses
GetFileInformationByHandleEx with FILE_ID_BOTH_DIR_INFO
instead of Find* APIs. The former is more performant because
it allows us to buffer IO calls and reduces the number of system calls,
passing from 1 per file to 1 every ~100 files
(depending on the size of the file name and the size of the buffer).
This change improve performance of File.ReadDir by 20-30%.
name old time/op new time/op delta
ReadDir-12 562µs ±14% 385µs ± 9% -31.60% (p=0.000 n=9+9)
name old alloc/op new alloc/op delta
ReadDir-12 29.7kB ± 0% 29.5kB ± 0% -0.88% (p=0.000 n=8+10)
name old allocs/op new allocs/op delta
ReadDir-12 399 ± 0% 397 ± 0% -0.50% (p=0.000 n=10+10)
This change also speeds up calls to os.SameFile when using FileStats
returned from File.readdir(), as their file ID can be inferred while
reading the directory.
Change-Id: Id56a338ee66c39656b564105cac131099218fb5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/452995
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL removes badsignal2 function, as it is unused on Windows.
badsignal2 was originally intended to abort the process when
an exception was raised on a non-Go thread, following the same approach
as Linux and others.
Since it was added, back on https://golang.org/cl/5797068, it has caused
several issues on Windows, see #8224 and #50877. That's because we can't
know wether the signal is bad or not, as our trap might not be at the
end of the exception handler chain.
To fix those issues, https://golang.org/cl/104200046 and CL 442896
stopped calling badsignal2, and CL 458135 removed one last incorrect
call on amd64 and 386.
Change-Id: I5bd31ee2672118ae0f1a2c8b46a1bb0f4893a011
Reviewed-on: https://go-review.googlesource.com/c/go/+/463116
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL factors out part of the Windows sigtramp implementation, which
was duplicated in all four architectures. The new common code is
implemented in Go rather than in assembly, which will make Windows
error handling easier to reason and maintain.
While here, implement the control flow guard workaround on
windows/386, which almost comes for free.
Change-Id: I0bf38c28c54793225126e161bd95527a62de05e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/458135
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
EvalSymlinks calls Clean twice, one in walkSymlinks and another in
toNorm. The later is not necessary, as toNorm is only called by
EvalSymlinks and just after walkSymlinks cleans the path without any
path manipulation in between.
Change-Id: Ibdb782c7eed59468f0ebb913e98d2a7db0df010d
Reviewed-on: https://go-review.googlesource.com/c/go/+/454615
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Prior to this change (as of CL 143578), our stat function attempted to
resolve all reparse points as if they were symlinks.
This results in an additional call to CreateFile when statting a
symlink file: we use CreateFile once to obtain the reparse tag and
check whether the file is actually a symlink, and if it is we call
CreateFile again without FILE_FLAG_OPEN_REPARSE_POINT to stat the link
target. Fortunately, since symlinks are rare on Windows that overhead
shouldn't be a big deal in practice.
Fixes#42919.
Change-Id: If453930c6e98040cd6525ac4aea60a84498c9579
Reviewed-on: https://go-review.googlesource.com/c/go/+/460595
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This CL avoids allocating in utf16.Decode for code point sequences
with less than 64 elements. It does so by splitting the function in two,
one that can be inlined that preallocates a buffer and the other that
does the heavy-lifting.
The mid-stack inliner will allocate the buffer in the caller stack,
and in many cases this will be enough to avoid the allocation.
unicode/utf16 benchmarks:
name old time/op new time/op delta
DecodeValidASCII-12 60.1ns ± 3% 16.0ns ±20% -73.40% (p=0.000 n=8+10)
DecodeValidJapaneseChars-12 61.3ns ±10% 14.9ns ±39% -75.71% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
DecodeValidASCII-12 48.0B ± 0% 0.0B -100.00% (p=0.000 n=10+10)
DecodeValidJapaneseChars-12 48.0B ± 0% 0.0B -100.00% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
DecodeValidASCII-12 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
DecodeValidJapaneseChars-12 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
I've also benchmarked os.File.ReadDir with this change applied
to demonstrate that it does make a difference in the caller site, in this
case via syscall.UTF16ToString:
name old time/op new time/op delta
ReadDir-12 592µs ± 8% 620µs ±16% ~ (p=0.280 n=10+10)
name old alloc/op new alloc/op delta
ReadDir-12 30.4kB ± 0% 22.4kB ± 0% -26.10% (p=0.000 n=8+10)
name old allocs/op new allocs/op delta
ReadDir-12 402 ± 0% 272 ± 0% -32.34% (p=0.000 n=10+10)
Change-Id: I65cf5caa3fd3b3a466c0ed837a50a96e975bbe6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/453415
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
This CL redesign how we get the TLS pointer on windows/i386.
It applies the same changes as done in CL 431775 for windows/amd64.
We were previously reading it from the [TEB] arbitrary data slot,
located at 0x14(FS), which can only hold 1 TLS pointer.
With this CL, we will read the TLS pointer from the TEB TLS slot array,
located at 0xE10(GS). The TLS slot array can hold multiple
TLS pointers, up to 64, so multiple Go runtimes running on the
same thread can coexists with different TLS.
Each new TLS slot has to be allocated via [TlsAlloc],
which returns the slot index. This index can then be used to get the
slot offset from GS with the following formula: 0xE10 + index*4.
The slot index is fixed per Go runtime, so we can store it
in runtime.tls_g and use it latter on to read/update the TLS pointer.
Loading the TLS pointer requires the following asm instructions:
MOVQ runtime.tls_g, AX
MOVQ AX(FS), AX
Notice that this approach will now be implemented in all the supported
windows arches.
[TEB]: https://en.wikipedia.org/wiki/Win32_Thread_Information_Block
[TlsAlloc]: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsalloc
Change-Id: If4550b0d44694ee6480d4093b851f4991a088b32
Reviewed-on: https://go-review.googlesource.com/c/go/+/454675
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously TryBot-tested with bucket bits = 4.
Also tested locally with bucket bits = 5.
This makes it much easier to change the size of map
buckets, and hopefully provides pointers to all the
code that in some way depends on details of map layout.
Change-Id: I9f6669d1eadd02f182d0bc3f959dc5f385fa1683
Reviewed-on: https://go-review.googlesource.com/c/go/+/462115
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
If OpArgIntReg is incorrectly scheduled, that causes it to be spilled
incorrectly, which causes the argument to not be considered live
at the start of the function.
This is the test for CL 462858
Add a brief mention of why CL 462858 is needed in the scheduling code.
Change-Id: Id199456f88d9ee5ca46d7b0353a3c2049709880e
Reviewed-on: https://go-review.googlesource.com/c/go/+/462899
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Sort variables before display so that when there are multiple variables
to report, they are in a consistent order.
Otherwise they are ordered in the order they appear in the fn.Dcl list,
which can vary. Particularly, they vary depending on regabi.
Change-Id: I0db380f7cbe6911e87177503a4c3b39851ff1b5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/462898
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Fix a coding error in coverage meta-data decoding in the method
decodemeta.CoverageMetaDataDecoder.ReadFunc. The code was not
unconditionally assigning the "function literal" field of the
coverage.FuncDesc object passed in, resulting in bad values depending
on what the state of the field happened to be in the object.
Fixes#57942.
Change-Id: I6dfd7d7f7af6004f05c622f9a7116e9f6018cf4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/462955
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When walking through the set of coverage data files generated from a
"go test -cover" run, it's possible to encounter pods (clumps of data
files) that were generated by a run from an instrumented Go tool (for
example, cmd/compile). Add a guard to the test reporting code to
ensure that it only processes files created by the currently running
test.
Fixes#57924.
Change-Id: I1bb7dce88305e1088162e3cb1df628486ecee1c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/462756
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Adjust the go/types file generation to run in a test, so that we can
easily reuse the existing logic to verify that the current content of
go/types matches the expected result of generating from types2.
This test will enforce that we don't forget to regenerate go/types when
making changes to types2.
Change-Id: Iee14b1402065f7f0ecbcf28000e07a06c08fa42e
Reviewed-on: https://go-review.googlesource.com/c/go/+/462758
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>
The previous DOS header placed on Windows binaries was incorrect, as it had e_crlc (number of relocations) set to 4, instead of e_cparhdr (size of header in 16-bit words) set to 4. This resulted in execution starting at the beginning of the file, instead of where the DOS stub code actually exists.
Fixes#57834
Change-Id: I8c5966b65c72b2474b771b85aaadb61cad9f5be6
GitHub-Last-Rev: c715ad290a
GitHub-Pull-Request: golang/go#57835
Reviewed-on: https://go-review.googlesource.com/c/go/+/462054
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: Quim Muntal <quimmuntal@gmail.com>
The register allocator doesn't like OpArg coming in between other
OpIntArg operations, as it doesn't put the spills in the right place
in that situation.
This is just a bug in the new scheduler, I didn't copy over the
proper score from the old scheduler correctly.
Change-Id: I3b4ee1754982fb360e99c5864b19e7408d60b5bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/462858
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 381316 documented the memory model of Map's APIs. However, the newly
introduced Swap, CompareAndSwap, and CompareAndDelete are missing from
this documentation as CL 399094 did not add this info.
This CL specifies the defined read/write operations of the new Map APIs.
For #51972
Change-Id: I519a04040a0b429a3f978823a183cd62e42c90ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/459715
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Changkun Ou <mail@changkun.de>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Apply the following regex substitutions, in order:
golang/go#(\d+) => go.dev/issue/$1
issue #?(\d+) => go.dev/issue/$1
Providing a link uniformly makes it easier to find the respective issue.
Change-Id: I9b60ffa1adb95be181f6711c2f171be3afe2b315
Reviewed-on: https://go-review.googlesource.com/c/go/+/462856
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Some tests in go/types can still not use the typecheck helper functions
because they need a specific fileset for position information.
(We could use a single global file set for all tests to make this work.)
Change-Id: I73552b08a00f08d809c319d3d2328acee9532619
Reviewed-on: https://go-review.googlesource.com/c/go/+/461694
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Add the code to generate initorder.go but do not enable the generation
of that file for now because the generated use uses error_ which has
implications for gopls use (error_ produces a single error instead of
pultiple \t-indented follow-on errors).
Change-Id: I5cd8acdeb8845dbb4716f19cf90d88191dd4216c
Reviewed-on: https://go-review.googlesource.com/c/go/+/461692
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The linux/sparc64 port is incomplete—it doesn't work, and it doesn't
have a builder. Now that dist supports broken ports, mark it as such.
The incomplete map was created to hide ports that aren't functional
from dist list output. Now that we have the broken port concept, it
seems largely redundant, so remove it for now.
For #56679.
Updates #28944.
Change-Id: I34bd23e913ed6d786a4d0aa8d2852f2b926fe4b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/458516
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This change makes it easier for clients to debug mutual TLS connection failures. Currently, there are a few situations where invalid client auth leads to a generic "bad certificate" alert. 3 specific situations have a more appropriate TLS alert code, based on the alert descriptions in the appendix of both RFC5246 and RFC8446.
1. The server is configured to require client auth, but no client cert was provided; the appropriate alert is "certificate required". This applies only to TLS 1.3, which first defined the certificate_required alert code.
2. The client provided a cert that was signed by an authority that is not in the server's trusted set of CAs; the appropriate alert is "unknown certificate authority".
3. The client provided an expired (or not yet valid) cert; the appropriate alert is "expired certificate".
Otherwise, we still fall back to "bad certificate".
Fixes#52113
Change-Id: I7d5860fe911cad8a1615f16bfe488a37e936dc36
GitHub-Last-Rev: 34eeab587b
GitHub-Pull-Request: golang/go#53251
Reviewed-on: https://go-review.googlesource.com/c/go/+/410496
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
With benchinit, we see a noticeable improvement in init times:
name old time/op new time/op delta
GoTypes 83.4µs ± 0% 43.7µs ± 1% -47.57% (p=0.029 n=4+4)
name old alloc/op new alloc/op delta
GoTypes 26.5kB ± 0% 18.8kB ± 0% -29.15% (p=0.029 n=4+4)
name old allocs/op new allocs/op delta
GoTypes 238 ± 0% 154 ± 0% -35.29% (p=0.029 n=4+4)
Port the same change to cmd/compile/internal/types and types2.
Updates #26775.
Change-Id: Ia1f7c4a4ce9a22d66e2aa9c9b9c341036993adca
Reviewed-on: https://go-review.googlesource.com/c/go/+/460544
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Avoid unnecessary allocations when calling reflect.TypeOf;
we can use nil pointers, which fit into an interface without allocating.
This saves about 1% of CPU time.
The builtin types are limited to typeIds between 0 and firstUserId,
and since firstUserId is 64, builtinIdToType does not need to be a map.
We can simply use an array of length firstUserId, which is simpler.
This saves about 1% of CPU time.
idToType is similar to firstUserId in that it is a map keyed by typeIds.
The difference is that it can grow with the user's types.
However, each added type gets the next available typeId,
meaning that we can use a growing slice, similar to the case above.
nextId then becomes the current length of the slice.
This saves about 1% of CPU time.
typeInfoMap is stored globally as an atomic.Value,
where each modification loads the map, makes a whole copy,
adds the new element, and stores the modified copy.
This is perfectly fine when the user registers types,
as that can happen concurrently and at any point in the future.
However, during init time, we sequentially register many types,
and the overhead of copying maps adds up noticeably.
During init time, use a regular global map instead,
which gets replaced by the atomic.Value when our init work is done.
This saves about 2% of CPU time.
Finally, avoid calling checkId in bootstrapType;
we have just called setTypeId, whose logic for getting nextId is simple,
so the extra check doesn't gain us much.
This saves about 1% of CPU time.
Using benchinit, which transforms GODEBUG=inittrace=1 data into Go
benchmark compatible output, results in a nice improvement:
name old time/op new time/op delta
EncodingGob 175µs ± 0% 162µs ± 0% -7.45% (p=0.016 n=5+4)
name old alloc/op new alloc/op delta
EncodingGob 39.0kB ± 0% 36.1kB ± 0% -7.35% (p=0.016 n=5+4)
name old allocs/op new allocs/op delta
EncodingGob 588 ± 0% 558 ± 0% -5.10% (p=0.000 n=5+4)
Updates #26775.
Change-Id: I28618e8b96ef440480e666ef2cd5c4a9a332ef21
Reviewed-on: https://go-review.googlesource.com/c/go/+/460543
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Per benchinit, this makes a big difference to init times:
name old time/op new time/op delta
InternalProfile 185µs ± 1% 6µs ± 1% -96.51% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
InternalProfile 101kB ± 0% 4kB ± 0% -95.72% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
InternalProfile 758 ± 0% 25 ± 0% -96.70% (p=0.008 n=5+5)
The fixed 0.2ms init cost is saved for any importer of net/http/pprof,
but also for cmd/compile, as it supports PGO now.
A Go program parsing profiles might not even need to compile these
regular expressions at all, if it doesn't encounter any legacy files.
I suspect this will be the case with most invocations of cmd/compile.
Updates #26775.
Change-Id: I8374dc64459f0b6bb09bbdf9d0b6c55d7ae1646e
Reviewed-on: https://go-review.googlesource.com/c/go/+/460545
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The Value type implements Aux interface because it is being used as a
"avoid clobbering flags" marker by amd64, x86 and s390x SSA parts.
Create a boolean that implements the Aux interface. Use it as the marker
instead. We no longer need Value to implement Aux.
Resolves a TODO.
See CL 275756 for more info.
Change-Id: I8a1eddf7e738b8aa31e82f3c4c590bafd2cdc56b
Reviewed-on: https://go-review.googlesource.com/c/go/+/461156
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Jakub Ciolek <jakub@ciolek.dev>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
With GOAMD64=V3 the canonical isPowerOfTwo function:
func isPowerOfTwo(x uintptr) bool {
return x&(x-1) == 0
}
Used to compile to:
temp := BLSR(x) // x&(x-1)
flags = TEST(temp, temp)
return flags.zf
However the blsr instruction already set ZF according to the result.
So we can remove the TEST instruction if we are just checking ZF.
Such as in multiple pieces of code around memory allocations.
This make the code smaller and faster.
Change-Id: Ia12d5a73aa3cb49188c0b647b1eff7b56c5a7b58
Reviewed-on: https://go-review.googlesource.com/c/go/+/448255
Run-TryBot: Jakub Ciolek <jakub@ciolek.dev>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Convert the scheduling pass from scheduling backwards to scheduling forwards.
Forward scheduling makes it easier to prioritize scheduling values as
soon as they are ready, which is important for things like nil checks,
select ops, etc.
Forward scheduling is also quite a bit clearer. It was originally
backwards because computing uses is tricky, but I found a way to do it
simply and with n lg n complexity. The new scheme also makes it easy
to add new scheduling edges if needed.
Fixes#42673
Update #56568
Change-Id: Ibbb38c52d191f50ce7a94f8c1cbd3cd9b614ea8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/270940
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This is the second round to look for spelling mistakes. This time the
manual sifting of the result list was made easier by filtering out
capitalized and camelcase words.
grep -r --include '*.go' -E '^// .*$' . | aspell list | grep -E -x '[A-Za-z]{1}[a-z]*' | sort | uniq
This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.
Change-Id: Ie8a2092aaa7e1f051aa90f03dbaf2b9aaf5664a9
GitHub-Last-Rev: fc2bd6e0c5
GitHub-Pull-Request: golang/go#57737
Reviewed-on: https://go-review.googlesource.com/c/go/+/461595
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This useConstraintTypeInference flag was debugging purposes only and
is not needed anymore. It's already gone in go/types.
Also, adjust/fix some comments.
Change-Id: I713be5759f05c618fcf26e16cf53dfb3626bba93
Reviewed-on: https://go-review.googlesource.com/c/go/+/461690
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The pconn write loop closes a request's body after sending the
request, but in the case where the write loop exits with an
unsent request in writech the body is never closed.
Close the request body in this case.
Fixes#49621
Change-Id: Id94a92937bbfc0beb1396446f4dee32fd2059c7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/461675
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In CL 408734 we introduced a fall back to base offset 0 if reading a
directory entry at the computed base offset failed. We have now found
a file in the wild for which the computed base offset is incorrect,
but happens to refer to a valid directory entry. In this CL, we change
the fallback such that if the first directory header relative to base
offset 0 is valid, we just use base offset 0.
Change-Id: Ia9ace20c1065d1f651035f16f7d91d741ab1dbf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/461598
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
We need to make sure that when we get the stack pointer, we get it
at the right time.
V = GetCallerSP
Call()
W = GetCallerSP
If Call causes a stack growth, then we will be in a situation
where V != W. So it matters when GetCallerSP operations get scheduled.
Add a memory argument to GetCallerSP so it can't be reordered with
things like calls.
Change-Id: I6cc801134c38e358c5a1ec0c09d38379a16a4184
Reviewed-on: https://go-review.googlesource.com/c/go/+/453515
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Martin Möhrmann <martin@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The SPanchored opcode is identical to SP, except that it takes a memory
argument so that it (and more importantly, anything that uses it)
must be scheduled at or after that memory argument.
This opcode ensures that a LEAQ of a variable gets scheduled after the
corresponding VARDEF for that variable.
This may lead to less CSE of LEAQ operations. The effect is very small.
The go binary is only 80 bytes bigger after this CL. Usually LEAQs get
folded into load/store operations, so the effect is only for pointerful
types, large enough to need a duffzero, and have their address passed
somewhere. Even then, usually the CSEd LEAQs will be un-CSEd because
the two uses are on different sides of a function call and the LEAQ
ends up being rematerialized at the second use anyway.
Change-Id: Ib893562cd05369b91dd563b48fb83f5250950293
Reviewed-on: https://go-review.googlesource.com/c/go/+/452916
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Martin Möhrmann <martin@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The standard way to generate code in a Go package is via //go:generate
directives, which are invoked by the developer explicitly running:
go generate import/path/of/said/package
Switch to using that approach here.
This way, developers don't need to learn and remember a custom way that
each particular Go package may choose to implement its code generation.
It also enables conveniences such as 'go generate -n' to discover how
code is generated without running anything (this works on all packages
that rely on //go:generate directives), being able to generate multiple
packages at once and from any directory, and so on.
Change-Id: I0e5b6a1edeff670a8e588befeef0c445613803c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/460135
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Allow GODEBUG users to report how many times a setting
resulted in non-default behavior.
Record non-default-behaviors for all existing GODEBUGs.
Also rework tests to ensure that runtime is in sync with runtime/metrics.All,
and generate docs mechanically from metrics.All.
For #56986.
Change-Id: Iefa1213e2a5c3f19ea16cd53298c487952ef05a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/453618
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Long ago we decided that panic(nil) was too unlikely to bother
making a special case for purposes of recover. Unfortunately,
it has turned out not to be a special case. There are many examples
of code in the Go ecosystem where an author has written panic(nil)
because they want to panic and don't care about the panic value.
Using panic(nil) in this case has the unfortunate behavior of
making recover behave as though the goroutine isn't panicking.
As a result, code like:
func f() {
defer func() {
if err := recover(); err != nil {
log.Fatalf("panicked! %v", err)
}
}()
call1()
call2()
}
looks like it guarantees that call2 has been run any time f returns,
but that turns out not to be strictly true. If call1 does panic(nil),
then f returns "successfully", having recovered the panic, but
without calling call2.
Instead you have to write something like:
func f() {
done := false
defer func() {
if err := recover(); !done {
log.Fatalf("panicked! %v", err)
}
}()
call1()
call2()
done = true
}
which defeats nearly the whole point of recover. No one does this,
with the result that almost all uses of recover are subtly broken.
One specific broken use along these lines is in net/http, which
recovers from panics in handlers and sends back an HTTP error.
Users discovered in the early days of Go that panic(nil) was a
convenient way to jump out of a handler up to the serving loop
without sending back an HTTP error. This was a bug, not a feature.
Go 1.8 added panic(http.ErrAbortHandler) as a better way to access the feature.
Any lingering code that uses panic(nil) to abort an HTTP handler
without a failure message should be changed to use http.ErrAbortHandler.
Programs that need the old, unintended behavior from net/http
or other packages can set GODEBUG=panicnil=1 to stop the run-time error.
Uses of recover that want to detect panic(nil) in new programs
can check for recover returning a value of type *runtime.PanicNilError.
Because the new GODEBUG is used inside the runtime, we can't
import internal/godebug, so there is some new machinery to
cross-connect those in this CL, to allow a mutable GODEBUG setting.
That won't be necessary if we add any other mutable GODEBUG settings
in the future. The CL also corrects the handling of defaulted GODEBUG
values in the runtime, for #56986.
Fixes#25448.
Change-Id: I2b39c7e83e4f7aa308777dabf2edae54773e03f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/461956
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
modindex defines its own type Package that must be exactly the
same as build.Package (there are conversions between them).
The normal reason to do this is to provide a different method set,
but there aren't any different methods. And if we needed to do that,
we could write
type Package build.Package
instead of repeating the struct definition. Remove the type entirely
in favor of direct use of build.Package.
This makes the modindex package not break when fields are
added to go/build.Package.
Change-Id: I8ffe9f8832bbc62be93a72e6a09d807ddbce216b
Reviewed-on: https://go-review.googlesource.com/c/go/+/462255
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
test_shuffle was added in CL 310033. It takes about 4½ seconds on my
workstation prior to this CL, most of which is spent linking and
running test binaries in 'go test'.
We can reduce that time somewhat (to 3¾ seconds) by simply running the
test fewer times (cases of 'off', 'on', positive, zero, and negative
values seem sufficient), but we should also avoid that linking
overhead at all in short mode.
Fixes#57709.
Change-Id: I908a70435ccfb1ca16ed23aec17512bf2b267b21
Reviewed-on: https://go-review.googlesource.com/c/go/+/461455
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
The mustBlock helper returns a function that verifies that the blocked
operation does eventually complete. However, it used an arbitrary
10-second timeout in place of “eventually”.
Since the test is checking a synchronization library, bugs are likely
to manifest as deadlocks. It may be useful to log what operation is in
flight if such a deadlock occurs; however, since we can't bound how
long a “reasonable” operation should take, the log message should only
be informational — it should not cause the test to fail.
While we're here, let's also set a better example by not leaking
time.After timers in the tests..
Fixes#57592.
Change-Id: I4e74e42390679bffac7a286824acb71b08994c17
Reviewed-on: https://go-review.googlesource.com/c/go/+/461000
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This uses the new Cancel and WaitDelay fields of os/exec.Cmd
(added in #50436) to interrupt or kill the 'hg serve' command
when its incoming http.Request is canceled.
This should keep the vcweb hg handler from getting stuck if 'hg serve'
hangs after the request either completes or is canceled.
Fixes#57597 (maybe).
Change-Id: I53cf58e8ab953fd48c0c37f596f99e885a036d9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/460997
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test is flaky, apparently due to a typo'd operator in CL 21447
that causes it to compare “same port OR IP” instead of
“same port AND IP”.
If we merely fixed the comparison, the test would hopefully stop being
flaky itself, but we would still be left with another problem:
repeatedly dialing a port that we believe to be unused can interfere
with other tests, which may open the previously-unused port and then
attempt a single Dial and expect it to succeed. Arbitrary other Dial
calls for that port may cause the wrong connection to be accepted,
leading to spurious test failures.
Moreover, the test can be extremely expensive for the amount of data
we hope to get from it, depending on the system's port-reuse
algorithms and dial implementations. It is already scaled back by up
to 1000x on a huge number of platforms due to latency, and may even be
ineffective on those platforms because of the arbitrary 1ms Dial
timeout. And the incremental value from it is quite low, too: it tests
the workaround for what is arguably a bug in the Linux kernel, which
ought to be fixed (and tested) upstream instead of worked around in
every open-source project that dials local ports.
Instead of trying to deflake this test, let's just get rid of it.
Fixes#18290.
Change-Id: I8a58b93d67916a33741c9ab29ef99c49c46b32c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/460657
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
These tests were only run on GOARCH=amd64, but the rationale given in
CL 11858043 was GC precision on 32-bit platforms. Today, we have far
more 64-bit platforms than just amd64, and I believe that GC precision
on 32-bit platforms has been substantially improved as well.
The GOARCH restriction seems unnecessary.
Updates #57166.
Updates #5368.
Change-Id: I45c608b6fa721012792c96d4ed94a6d772b90210
Reviewed-on: https://go-review.googlesource.com/c/go/+/456120
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Austin Clements <austin@google.com>
- Use testenv.Command instead of exec.Command to try to get more
useful timeout behavior.
- Parallelize tests that appear not to require global state.
(And add explanatory comments for a few that are not
parallelizable for subtle reasons.)
- Consolidate some “Helper” tests with their parent tests.
- Use t.TempDir instead of os.MkdirTemp when appropriate.
- Factor out subtests for repeated test helpers.
For #36107.
Updates #22315.
Change-Id: Ic24b6957094dcd40908a59f48e44c8993729222b
Reviewed-on: https://go-review.googlesource.com/c/go/+/458015
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
CL 444277 fixed Time.UnmarshalText and Time.UnmarshalJSON to properly
unmarshal timestamps according to RFC 3339 instead of according
to Go's bespoke time syntax that is a superset of RFC 3339.
However, this change seems to have broken an AWS S3 unit test
that relies on parsing timestamps with single digit hours.
It is unclear whether S3 emits these timestamps in production or
whether this is simply a testing artifact that has been cargo culted
across many code bases. Either way, disable strict parsing for now
and re-enable later with better GODEBUG support.
Updates #54580
Change-Id: Icced2c7f9a6b2fc06bbd9c7e90f90edce24c2306
Reviewed-on: https://go-review.googlesource.com/c/go/+/462286
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Tests must not write to GOROOT: it might not writable (for example, if
it is owned by root and the user is non-root), and in general we can't
assume that the configuration in which the test is run matches the
configuration with which the installed tools were built.
In this specific case, CL 454836 (for #57007) installs 'cmd' with
CGO_ENABLED=0, but most builders still run the tests with CGO_ENABLED
unset.
Updates #57007.
Change-Id: I2795fcd3ff61c164dc730b62f697f307ab3a167b
Reviewed-on: https://go-review.googlesource.com/c/go/+/461689
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Follow-up on CL 461687 which missed the go/types change.
(As an aside, we cannot yet generate this change because
go/types uses a positioner and types2 just uses a syntax.Pos.)
Change-Id: I28113a2efdc3ddd30cb9a80d2cb2c802ff035ec2
Reviewed-on: https://go-review.googlesource.com/c/go/+/461688
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Various Linux distributions edit cmd/go/internal/cfg/cfg.go to change
the default settings of GOPROXY and GOSUMDB. Make it possible for
them to do this without editing the go command source code by
introducing GOROOT/go.env and moving those defaults there.
With the upcoming changes for reproducible builds (#24904),
this should mean that Linux distributions distribute binaries
that are bit-for-bit identical to the Go distribution binaries,
even when rebuilding the distribution themselves.
Fixes#57179.
Change-Id: Ib2ecc61e6d036f97db6fd47dca757c94fdea5629
Reviewed-on: https://go-review.googlesource.com/c/go/+/462198
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
- Build cmd with CGO_ENABLED=0. Doing so removes the C compiler
toolchain from the reproducibility perimeter and also results in
cmd/go and cmd/pprof binaries that are statically linked,
so that they will run on a wider variety of systems.
In particular the Linux versions will run on Alpine and NixOS
without needing a simulation of libc.so.6.
The potential downside of disabling cgo is that cmd/go and cmd/pprof
use the pure Go network resolver instead of the host resolver on
Unix systems. This means they will not be able to use non-DNS
resolver mechanisms that may be specified in /etc/resolv.conf,
such as mDNS. Neither program seems likely to need non-DNS names
like those, however.
macOS and Windows systems still use the host resolver, which they
access without cgo.
- Build cmd with -trimpath when building a release.
Doing so removes $GOPATH from the file name prefixes stored in the
binary, so that the build directory does not leak into the final artifacts.
- When CC and CXX are empty, do not pick values to hard-code into
the source tree and binaries. Instead, emit code that makes the
right decision at runtime. In addition to reproducibility, this
makes cross-compiled toolchains work better. A macOS toolchain
cross-compiled on Linux will now correctly look for clang,
instead of looking for gcc because it was built on Linux.
- Convert \ to / in file names stored in .a files.
These are converted to / in the final binaries, but the hashes of
the .a files affect the final build ID of the binaries. Without this
change, builds of a Windows toolchain on Windows and non-Windows
machines produce identical binaries except for the input hash part
of the build ID.
- Due to the conversion of \ to / in .a files, convert back when
reading inline bodies on Windows to preserve output file names
in error messages.
Combined, these four changes (along with Go 1.20's removal of
installed pkg/**.a files and conversion of macOS net away from cgo)
make the output of make.bash fully reproducible, even when
cross-compiling: a released macOS toolchain built on Linux or Windows
will contain exactly the same bits as a released macOS toolchain
built on macOS.
The word "released" in the previous sentence is important.
For the build IDs in the binaries to work out the same on
both systems, a VERSION file must exist to provide a consistent
compiler build ID (instead of using a content hash of the binary).
For #24904.
Fixes#57007.
Change-Id: I665e1ef4ff207d6ff469452347dca5bfc81050e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/454836
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
We need to clear GOEXPERIMENT any time we are invoking a bootstrap
toolchain. One line missed the clearing of GOEXPERIMENT.
There were three different lines using different syntaxes and subtly
different sets of variables being cleared, so hoist them into a function
so it's all in one place.
Also quote $GOROOT_BOOTSTRAP consistently.
Change-Id: I6c5a5d70c694c24705bbc61298b28ae906c0cf6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/456635
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
I often create dummy files holding various data named things like 'z'.
If a file (not directory) GOROOT/src/z exists, it confuses cmd/go into
thinking z is a standard library package, which breaks the test
Script/mod_vendor.
This CL fixes internal/goroot to only report that something is a standard
library package when a directory with that name exists, not just a file.
Change-Id: I986c9a425e78d23c7e033aeadb8e9f71aab2b878
Reviewed-on: https://go-review.googlesource.com/c/go/+/461955
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Unified IR added several new IR fields for holding *runtime._type
expressions. To avoid throwing off any frontend semantics
(particularly inlining cost heuristics), they were marked as
`mknode:"-"` so that code wouldn't visit them.
Unfortunately, this has a bad interaction with the static init
inlining optimization, because the latter relies on ir.EditChildren to
substitute all parameters. This potentially includes dictionary
parameters, which can appear within the new RType fields.
This CL adds a new ir.EditChildrenWithHidden function that also edits
these fields, and switches staticinit to use it. Longer term, we
should unhide the RType fields so that ir.EditChildren visits them
normally, but that's scarier so late in the release cycle.
Fixes#57778.
Change-Id: I98c1e8cf366156dc0c81a0cb79029cc5e59c476f
Reviewed-on: https://go-review.googlesource.com/c/go/+/461686
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
This CL introduces the new files util.go and util_test.go for both
type checkers; these files factor out functionality that is different
between the type checkers so that more code (that is otherwise mostly
the same) can be generated.
With cmpPos/CmpPos factored out, go/types/scope.go can now be generated.
Change-Id: I35f67e53d83b3c5086a559b1e826db83d38ee217
Reviewed-on: https://go-review.googlesource.com/c/go/+/461596
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL replaces the internal trace flag with Config.trace.
While unexported, it can still be set for testing via reflection.
The typical use is for manual tests, where -v (verbose) turns on
tracing output. Typical use:
go test -run Manual -v
This change makes go/types match types2 behavior.
Change-Id: I22842f4bba8fd632efe5929c950f4b1cab0a8569
Reviewed-on: https://go-review.googlesource.com/c/go/+/461081
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
go/types:
- gofmt a couple of files
types2:
- add loong64 to sizes list (present in go/types)
- fix a type in validtype.go
- co-locate an accessor with others in typeparam.go
This changes further reduce discrepancy between types2 and go/types.
Change-Id: I2e6a09f1c4b8dbc947c48af13031ff58a2bc6f4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/460996
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This also brings some of the types2 testing code better in sync with
go/types.
Also: fix a minor bug in resolver_test.go (continue traversing
SelectorExpr if the first part is not an identifier).
Change-Id: Ib6c5f6228812b49c185b52a4f02ca5b393418e01
Reviewed-on: https://go-review.googlesource.com/c/go/+/460760
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
During constraint type inference, unification may fail because it
operates with limited information (core types) even if the actual
type argument satisfies the type constraint in question.
On the other hand, it is safe to ignore failing unification during
constraint type inference because if the failure is true, an error
will be reported when checking instantiation.
Fixes#53650.
Change-Id: Ia76b21ff779bfb1282c1c55f4174847b29cc6f3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/454655
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Use ERROR for substrings, and ERRORx for regexp error patterns.
Correctly unquote patterns for ERROR and ERRORx.
Adjust all tests in internal/types/testdata and locally as needed.
The changes to internal/types/testdata were made through
repeated applications of regexpr find/replace commands
and manual cleanups.
Fixes#51006.
Change-Id: Ib9ec5001243b688bf5aee56b7d4105fb55999ab4
Reviewed-on: https://go-review.googlesource.com/c/go/+/455755
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Before matching the pattern, the double quotes are simply stripped
(no Go string unquoting) for now. This is a first step towards use
of proper Go strings as ERROR patterns.
The changes were obtained through a couple of global regexp
find/replace commands:
/\* ERROR ([^"]+) \*/ => /* ERROR "$1" */
// ERROR ([^"]+)$ => // ERROR "$1"
followed up by manual fixes where multiple "/* ERROR"-style
errors appeared on the same line (in that case, the first
regexp matches the first and last ERROR).
For #51006.
Change-Id: Ib92c2d5e339075aeec1ea74c339b5fecf953d1a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/455718
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Sorting is only needed if there are multiple matching errors on
the same line. Instead, in that rare case, select the error that
is closest.
Follow-up on CL 456137.
Change-Id: Ia2056b21c629f3a42495e32de89607fbefb82fa7
Reviewed-on: https://go-review.googlesource.com/c/go/+/456335
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This adds the (adjusted) syntax.CommentMap function and corresponding
test to the types_test package so that we can use it for collecting
ERROR comments in the next CL.
For #51006.
Change-Id: I63ce96e7394c28c02d5a292250586cc49c1f6e19
Reviewed-on: https://go-review.googlesource.com/c/go/+/456125
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Change the ErrorMap function to collect all comments with a comment
text that matches a given regexp pattern. Also rename it to CommentMap.
Adjust uses and corresponding test.
Adjust various type-checker tests with incorrect ERROR patterns.
For #51006.
Change-Id: I749e8f31b532edbf8568f27ba1546dc849efd143
Reviewed-on: https://go-review.googlesource.com/c/go/+/456155
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Cherry Mui <cherryyz@google.com>
This is the start of the Go 1.21 development cycle, so update the
Version value accordingly. It represents the Go 1.x version that
will soon open up for development (and eventually become released).
For #40705.
For #57736.
Change-Id: I31b739f632bdc8d14f46560e0e5bf333fb8e7740
Reviewed-on: https://go-review.googlesource.com/c/go/+/462456
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
2023-01-17 19:47:10 +00:00
3700 changed files with 180078 additions and 102080 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
