Adds rules that rewrites statements such as ~P&~Q as ~(P|Q) and ~P|~Q as ~(P&Q), removing an extraneous instruction.
Change-Id: Icedb97df741680ddf9799df79df78657173aa500
GitHub-Last-Rev: f22e2350c9
GitHub-Pull-Request: golang/go#60018
Reviewed-on: https://go-review.googlesource.com/c/go/+/493175
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Stefan M <st3f4nm4d4@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@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>
This CL updates riscv instructions by
https://github.com/riscv/riscv-opcodes
which adds instruction:
APAUSE
And removes the following unused instructions:
AFENCEI
AFMVQX
AFMVXQ
AHFENCEGVMA
AHFENCEVVMA
ASLLIRV32
ASRAIRV32
ASRLIRV32
AURET
Change-Id: I314570c643af3e6bbc9d2cd471b6b39985bcbdff
Reviewed-on: https://go-review.googlesource.com/c/go/+/409415
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: M Zhuo <mzh@golangcn.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>
This updates the doc comment to reflect the behavior of the method.
On error the method returns a partial result.
Fixes#59991
Change-Id: I71e9dfa37e0488c85abd3eeede2a1a34cb74239b
GitHub-Last-Rev: 389488e536
GitHub-Pull-Request: golang/go#60084
Reviewed-on: https://go-review.googlesource.com/c/go/+/494055
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Fix comments, including duplicate is, wrong phrases and articles, misspellings, etc.
Change-Id: I8bfea53b9b275e649757cc4bee6a8a026ed9c7a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/493035
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Test the built-in handlers using the testing/slogtest package.
Change-Id: I6464b6730293461c38b84fb2bf33cdd09173dd6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/488255
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@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>
#57433 added slices.Equal, using it can reduce the amount of code
Change-Id: I70d14b6c4c24da641a34ed36c900d9291033f526
Reviewed-on: https://go-review.googlesource.com/c/go/+/492576
Reviewed-by: Than McIntosh <thanm@google.com>
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>
Run-TryBot: shuang cui <imcusg@gmail.com>
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>
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>
