This reverts commit 99914db5ee.
aka CL 473875
Reason for revert: init order change that required this CL is causing some problems in some internal Google programs.
Change-Id: I801e278ab58d542c05c0332a9f1977b9588b6151
Reviewed-on: https://go-review.googlesource.com/c/go/+/474975
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Keith Randall <khr@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
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>
This code is generic to ppc64/ppc64le - there is no need to limit it to
aix or linux.
Updates #56001
Change-Id: I613964a90f9c5ca637720219a0260d65427f4be0
Reviewed-on: https://go-review.googlesource.com/c/go/+/473697
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.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>
If the test actually deadlocks, we probably want a goroutine dump to
debug it anyway. Otherwise, the arbitrary timeout can only cause
spurious failures.
Fixes#36179.
Change-Id: Ic2037496959a38d3231eefdbc1dd5d45eebdf306
Reviewed-on: https://go-review.googlesource.com/c/go/+/474582
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>
Change-Id: Ifb8d64f18b67c8b712feec29ffb6719c6e9718ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/474198
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This issue has been fixed with unified IR, so just add a test.
Update #53087
Change-Id: I965d9f27529fa6b7c89e2921c65e5a100daeb9fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/410197
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Keith Randall <khr@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>
This ISA 3.0 (power9) instruction is helpful for some string functions
in a future change.
Change-Id: I1a659488ffb5099f8c89f480c39af4ef9c4b556a
Reviewed-on: https://go-review.googlesource.com/c/go/+/472635
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
Fixes#58882
Change-Id: I65842a4aa3f808533e28128078e7e94a9b121404
Reviewed-on: https://go-review.googlesource.com/c/go/+/473915
Reviewed-by: Carlos Amedee <carlos@golang.org>
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: Andy Pan <panjf2000@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
reloctype_strings.go is out-of-date since CL 462035, regenerate it.
Found while working on CL 461737.
Change-Id: I5cf910ab14c3618d6653c87861a4d53d3c91feff
Reviewed-on: https://go-review.googlesource.com/c/go/+/473875
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Carlos Amedee <carlos@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>
No changes to non-tracing related code.
Change-Id: I3d004528281111a4479a02543a3e5443485182cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/474135
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>
Add functionality to retrieve values for .dynamic entries that don't
correspond to entries in the string table.
Fixes#56892
Change-Id: I6edabc8ca331c819e442d06e19b7f4df8343372b
Reviewed-on: https://go-review.googlesource.com/c/go/+/452617
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>
Change-Id: Ib2c4ddec9740f7c21c180c9f0980394dceeedfaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/473975
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
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 type doesn't implement an interface due to an ambiguous method,
say so in the error message instead of just reporting a missing method.
Fixes#57352.
Change-Id: I5608f893c485de578b7f86362ca6f66033653695
Reviewed-on: https://go-review.googlesource.com/c/go/+/473658
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
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 reverts CL 465805 (commit 3eedba50b1).
Reason for revert: The longtest on Windows was typoed, silently ignored, and it turns out it fails there.
Change-Id: I362e9a22a7ec569314a0da932730ba137a98ecda
Reviewed-on: https://go-review.googlesource.com/c/go/+/473795
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Bryan Mills <bcmills@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>
Stop depending on base.Pos for these.
Change-Id: I58dea44f8141eb37b59a6e9f7db0c6baa516ad93
Reviewed-on: https://go-review.googlesource.com/c/go/+/472296
Reviewed-by: Keith Randall <khr@google.com>
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>
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: I1e4d3878ebe6e8953527aedb730824971d722cac
Reviewed-on: https://go-review.googlesource.com/c/go/+/462035
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>
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>
A 0-sized no-op shouldn't prevent us from detecting that the first
instruction is from an inlined callee.
Update #58300
Change-Id: Ic5f6ed108c54a32c05e9b2264b516f2cc17e4619
Reviewed-on: https://go-review.googlesource.com/c/go/+/467977
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
TestGdbPanic expects crash() to raise a SIGABRT signal interceptable
by gdb, but Windows doesn't have signals.
Windows builders haven't caught this failing test because they still
don't have gdb installed (tracked in #22021).
Change-Id: I7c7f2523a54d61aea0a9821c4db7c79e58a7217c
Reviewed-on: https://go-review.googlesource.com/c/go/+/473116
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
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>
After CL 470215 it should be safe to run this test on Plan 9.
Fixes#26945
Change-Id: I17880b696d2e91e6c4862fac05e6372f44e69b22
Reviewed-on: https://go-review.googlesource.com/c/go/+/472436
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Remove unnecessary assignments by using the same two variables
for methods consistently throughout.
Change-Id: I8b9bc8dbc8022b2472724d2a170f2635de3306e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/472915
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>
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>
For now this is simply a mechanical combination without any
relevant logic changes. This will make it easier to review
subsequent changes.
Change-Id: Ic2e2ae32b031d2dda0f69a08a5cc2349748bd25d
Reviewed-on: https://go-review.googlesource.com/c/go/+/472675
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>
Auto-Submit: Robert Griesemer <gri@google.com>
