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>
This is necessary to make hashes be consistent across runs,
otherwise ASLR messes up search.
Change-Id: Icf668dfe4c2008709f7767397b6700d0d5439287
Reviewed-on: https://go-review.googlesource.com/c/go/+/493857
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@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 wasmer runtime will be used to test our wasip1
implementation against the WASI runtime from wasmer.io.
For #59907
Change-Id: Ie7e48c39e03075815ddca46d996b6ec87009b12a
Reviewed-on: https://go-review.googlesource.com/c/go/+/493775
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Bryan Mills <bcmills@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>
Change-Id: Ia4cfdea3df8834e6260527ce8e6e894a0547070f
Reviewed-on: https://go-review.googlesource.com/c/go/+/425299
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: WANG Xuerui <git@xen0n.name>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
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>
Michael Stapelberg thought the former messages had
upside potential, Russ and I agreed.
Also slightly tweaked the json logging, not sure if
anyone will use it but it should at least be okay.
Change-Id: Iaab75114dd5f5d8f011fab22d32b57abc0272815
Reviewed-on: https://go-review.googlesource.com/c/go/+/493135
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Stapelberg <stapelberg@google.com>
Vendoring for use with the internal/godebug test
and eventually the cmd/compile test as well.
Change-Id: I3f7151949cff584705cb32ba39bf5de5cd45c3f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/493597
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
This implements the proposal #58671.
Must be explicitly enabled and requires proposal approval.
For #58671.
Change-Id: I150e78f4f3282d6b7cf9d90feeb5f1c5a36d8c38
Reviewed-on: https://go-review.googlesource.com/c/go/+/492835
Auto-Submit: 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>
Run-TryBot: Robert Griesemer <gri@google.com>
No changes to the moved functions.
Generate const.go for go/types.
Change-Id: I5ac412cecd9f618676a01138aed36428bbce3311
Reviewed-on: https://go-review.googlesource.com/c/go/+/493715
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 matches the go/types version of Checker.overflow.
Preparation for generating this function (and others)
for go/types.
Change-Id: I84117203247011bd2e96c9cf53fd5a443e528bbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/493558
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>
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>
Instead of writing them to a file and executing that file.
For #59998
Change-Id: I341786926762359f67dccb475295afbbb8ed1054
Reviewed-on: https://go-review.googlesource.com/c/go/+/493555
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@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>
If the LHS of an assignment is neither addressable nor a map expression
(and not the blank identifier), explicitly say so for a better error
message.
For #3117.
Change-Id: I4bffc35574fe390a0567e89182b23585eb5a90de
Reviewed-on: https://go-review.googlesource.com/c/go/+/492875
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>
Auto-Submit: Robert Griesemer <gri@google.com>
An untyped nil argument cannot be used to infer any type information.
We don't need to include it in the untyped arguments.
Change-Id: Ied44738ff1b135e65a3acfa19223cd3889b7fa7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/492695
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 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>
We don't want std to depend on x/tools, so just as we
did with txtar, copy the bisect package into internal
rather than using a require + vendor.
Change-Id: Id775254f7c765a9244ba6eaf041c13e6e5c5e9f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/492595
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
This reverts CL 485500.
Reason for revert: This breaks internal tests at Google, see b/280861579 and b/280820455.
Change-Id: I426278d400f7611170918fc07c524cb059b9cc55
Reviewed-on: https://go-review.googlesource.com/c/go/+/492995
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Chressie Himpel <chressie@google.com>
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>
