Daniel Martí [Fri, 12 Jun 2020 14:14:42 +0000 (15:14 +0100)]
cmd/go: error when -c or -i are used with unknown flags
Other test flags passed to the test binary, such as -run or -count, are
equally pointless when -c or -i are used, since the test binary is never
run. However, custom flags in that scenario are far more likely to be
due to human error, such as:
# note the "ldflags" typo, which silently did nothing
go test -c -lflags=-w
Instead, make this scenario error. It seems unlikely that anyone is
using -c along with intended custom-defined test flags, and if they are,
removing those extra flags that do nothing is probably a good idea
anyway.
We don't add this restriction for the flags defined in 'go help
testflag', since they are far less likely to be typos or unintended
mistakes. Another reason not to do that change is that other commands
similarly silently ignore no-op flags, such as:
# -d disables the build, so -ldflags is never used
go get -d -ldflags=-w
Fixes #39484.
Change-Id: I6ba2f6866562fe8f8fceaf4cd862d874bf5cd978
Reviewed-on: https://go-review.googlesource.com/c/go/+/237697
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Changkun Ou [Sat, 19 Sep 2020 21:32:12 +0000 (23:32 +0200)]
testing: send t.signal only if there is no panic
If a signal is sent to t.signal before the panic is triggered,
a panicking test may end up with "warning: no tests to run" because
the tRunner that invokes the test in t.Run calls runtime.Goexit on
panic, which causes the panicking test not be recorded in runTests.
Send the signal if and only if there is no panic.
Fixes #41479
Change-Id: I812f1303bfe02c443a1902732e68d21620d6672e
Reviewed-on: https://go-review.googlesource.com/c/go/+/256098
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Trust: Emmanuel Odeke <emm.odeke@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
Sean Liao [Thu, 21 May 2020 15:52:33 +0000 (17:52 +0200)]
encoding/json: allow semicolon in field key / struct tag
Allow ';' as a valid character for json field keys and struct tags.
Fixes #39189
Change-Id: I4b602a1b0674ff028db07623682f0d1e8e9fd6c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/234818
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Trust: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Alberto Donizetti [Thu, 24 Sep 2020 12:36:34 +0000 (14:36 +0200)]
cmd/compile: more amd64 typed aux rules
Passes
gotip build -toolexec 'toolstash -cmp' -a std
Change-Id: Id9da1240ca810fe07f23c56b36900b6e35a10a6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/257037
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
CL 250357 exported net.ErrClosed to allow more reliable detection
of closed network connection errors. Use that error in crypto/tls
as well.
The error message is changed from "tls: use of closed connection"
to "use of closed network connection", so the code that detected such
errors by looking for that text in the error message will need to be
updated to use errors.Is(err, net.ErrClosed) instead.
Fixes #41066
Change-Id: Ic05c0ed6a4f57af2a0302d53b00851a59200be2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/256897 Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Constantin Konstantinidis [Sat, 29 Aug 2020 09:10:50 +0000 (11:10 +0200)]
cmd/compile: enforce strongly typed rules for ARM (GOARM)
Toolstash-check successful for remaining rules using GOARM value.
Change-Id: I254f80d17839ef4957c1b7afbdb4db363a3b9367
Reviewed-on: https://go-review.googlesource.com/c/go/+/240997
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
SparrowLii [Tue, 25 Aug 2020 08:33:50 +0000 (16:33 +0800)]
math/big: replace division with multiplication by reciprocal word
Division is much slower than multiplication. And the method of using
multiplication by multiplying reciprocal and replacing division with it
can increase the speed of divWVW algorithm by three times,and at the
same time increase the speed of nats division.
Change-Id: I049f1196562b20800e6ef8a6493fd147f93ad830
Reviewed-on: https://go-review.googlesource.com/c/go/+/250417
Trust: Giovanni Bajo <rasky@develer.com>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Alberto Donizetti [Wed, 23 Sep 2020 12:41:33 +0000 (14:41 +0200)]
cmd/compile: switch to typed for amd64 flag const rules
Passes
gotip build -toolexec 'toolstash -cmp' -a std
Change-Id: I5a322c9a3922107aa3bfcddfae732dcd6e15ac3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/256738
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
The IndexString implementation in the bytealg package requires that
the string passed into it be in the range '2 <= len(s) <= MaxLen'
where MaxLen may be any value (including 0).
CL 156998 added calls to bytealg.IndexString where MaxLen was not
first checked. This led to an illegal instruction on s390x with
the vector facility disabled.
This CL guards the calls to bytealg.IndexString with a MaxLen check.
If the check fails then the code now falls back to the pre CL 156998
implementation (a loop over the runes in the string).
Since the MaxLen check is now in place the generic implementation is
no longer called so I have returned it to its original unimplemented
state.
In future we may want to drop MaxLen to prevent this kind of
confusion.
Fixes #41552.
Change-Id: Ibeb3f08720444a05c08d719ed97f6cef2423bbe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/256717
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Munday <mike.munday@ibm.com> Reviewed-by: Keith Randall <khr@golang.org>
Constantin Konstantinidis [Sat, 4 Jul 2020 09:01:29 +0000 (11:01 +0200)]
cmd/compile: enforce strongly typed rules for ARM (8)
add type casting to int32: L148-L156, L774-L778
Toolstash-check successful
Change-Id: Ib6544c1d7853c2811def5b18786e1fc5c18086ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/256097 Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Change-Id: I69e8e9f964c1f35615e4e19401c3f661e1e64a3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/256100 Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Change-Id: I80f90716477f269a227be28b14bf913b78ef375d
Reviewed-on: https://go-review.googlesource.com/c/go/+/228824
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Introduce GOOS=ios for iOS systems. GOOS=ios matches "darwin"
build tag, like GOOS=android matches "linux" and GOOS=illumos
matches "solaris". Only ios/arm64 is supported (ios/amd64 is
not).
GOOS=ios and GOOS=darwin remain essentially the same at this
point. They will diverge at later time, to differentiate macOS
and iOS.
Uses of GOOS=="darwin" are changed to (GOOS=="darwin" || GOOS=="ios"),
except if it clearly means macOS (e.g. GOOS=="darwin" && GOARCH=="amd64"),
it remains GOOS=="darwin".
The instructions have already been updated in greater
detail in "Step 2: Configure git authentication", but
the overview needs updated to reflect the new workflow.
Change-Id: I6f411a3dc500a9058036a4a828403c0153e4220a
Reviewed-on: https://go-review.googlesource.com/c/go/+/256857
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Constantin Konstantinidis [Sat, 4 Jul 2020 09:29:40 +0000 (11:29 +0200)]
cmd/compile: enforce strongly typed rules for ARM (4)
"mul by constant" until "div by constant"
L547-L609
Change-Id: I19ebb5694e383878f505d34df2591a51fe38431a
Reviewed-on: https://go-review.googlesource.com/c/go/+/254662 Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Alberto Donizetti [Sun, 20 Sep 2020 07:15:29 +0000 (09:15 +0200)]
cmd/compile: switch to typed aux in more amd64 rules
Passes
gotip build -toolexec 'toolstash -cmp' -a std
Change-Id: I9acda12d24f85d0b12d0cbbedbf9df3b4afcb31b
Reviewed-on: https://go-review.googlesource.com/c/go/+/256099
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Change-Id: I5b6ef0da5052e3381ee9c714bbff541c11ed0259
Reviewed-on: https://go-review.googlesource.com/c/go/+/246837
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Constantin Konstantinidis [Fri, 15 May 2020 18:35:00 +0000 (20:35 +0200)]
cmd/compile: enforce strongly typed rules for ARM (6)
End of "constant folding in *shift ops" until EOF
(L1070-)
Toolstash-check is successful.
Change-Id: I55846a459aca5238f831750f04132e13a0baeed7
Reviewed-on: https://go-review.googlesource.com/c/go/+/234198 Reviewed-by: Giovanni Bajo <rasky@develer.com> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
Constantin Konstantinidis [Thu, 14 May 2020 05:43:01 +0000 (07:43 +0200)]
cmd/compile: enforce strongly typed rules for ARM (5)
From "absorb InvertFlags" until "constant folding in *shift ops"
L666-L1011
Toolstash-check is successful.
Change-Id: Ieed7d4643dc3dc2b3649477e87aebd22c81d1322
Reviewed-on: https://go-review.googlesource.com/c/go/+/234197 Reviewed-by: Giovanni Bajo <rasky@develer.com> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
Constantin Konstantinidis [Sun, 10 May 2020 19:55:55 +0000 (21:55 +0200)]
cmd/compile: enforce strongly typed rules for ARM (3)
Toolstash-check successful from L270 until L543.
Change-Id: Ic39ab86c80f970bfb21e318284f6bb3e8a994220
Reviewed-on: https://go-review.googlesource.com/c/go/+/233439 Reviewed-by: Giovanni Bajo <rasky@develer.com> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
Constantin Konstantinidis [Sun, 10 May 2020 06:10:47 +0000 (08:10 +0200)]
cmd/compile: enforce strongly typed rules for ARM (2)
Toolstash-check successful from L0 until L268
Change-Id: Ifc55ea1e4177c21107c521fc72da2da7b507b8ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/232811 Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
QueryPackage was a wrapper around QueryPattern with extra validation,
called only once from within the same package. Most of that validation
was already performed much earlier, in (*loader).Load. Inline the
remaining validation and remove the needless indirection.
For #36460
Change-Id: I108a01d416197db8f886889554e07b29f0c37f3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/256057
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Change-Id: I3989bcb051ae57dd2d8f89759d241d4cdce49659
Reviewed-on: https://go-review.googlesource.com/c/go/+/255969
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
cmd/go: add a '-e' flag to 'mod tidy' and 'mod vendor'
This flag, like the -e flag to 'go list', instructs the command to
make a best effort to continue in spite of errors for specific packages.
Fixes #26603
Change-Id: I5ee2f50c71870ae8ef3f9b3e5b045474adcca525
Reviewed-on: https://go-review.googlesource.com/c/go/+/255960
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
This change replaces ImportPaths, ImportPathsQuiet, LoadALL, and
LoadVendor with a single LoadPackages function, with a LoadOpts struct
that more clearly documents the variations in behavior.
It also eliminates the cmd/go/internal/load.ImportPaths function,
which was undocumented and had only one call site (within its own
package).
The modload.LoadTests global variable is subsumed by a field in the
new LoadOpts struct, and is no longer needed for callers that invoke
LoadPackages directly. It has been (temporarily) replaced with a
similar global variable, load.ModResolveTests, which can itself be
converted to an explicit, local argument.
For #37438
For #36460
Updates #40775
Fixes #26977
Change-Id: I4fb6086c01b04de829d98875db19cf0118d40f8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/255938
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Michael Pratt [Fri, 21 Aug 2020 15:51:25 +0000 (11:51 -0400)]
runtime: add sched.lock assertions
Functions that require holding sched.lock now have an assertion.
A few places with missing locks have been fixed in this CL:
Additionally, locking is added around the call to procresize in
schedinit. This doesn't technically need a lock since the program is
still starting (thus no concurrency) when this is called, but lock held
checking doesn't know that.
Updates #40677
Change-Id: I198d3cbaa727f7088e4d55ba8fa989cf1ee8f9cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/250261
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Michael Pratt [Fri, 21 Aug 2020 15:49:56 +0000 (11:49 -0400)]
runtime: check held locks with staticlockranking
When lock ranking is enabled, we can now assert that lock preconditions
are met by checking that the caller holds required locks on function
entry.
This change adds the infrastructure to add assertions. Actual assertions
will be added for various locks in subsequent changes.
Some functions are protected by locks that are not directly accessible
in the function. In that case, we can use assertRankHeld to check that
any lock with the rank is held. This is less precise, but it avoids
requiring passing the lock into the functions.
Updates #40677
Change-Id: I843c6874867f975e90a063f087b6e2ffc147877b
Reviewed-on: https://go-review.googlesource.com/c/go/+/245484
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Dmitri Shuralyov [Thu, 17 Sep 2020 16:32:24 +0000 (12:32 -0400)]
all: update vendored dependencies during Go 1.16 development
The Go 1.16 development cycle has started. This is the time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
Those versions have already gone through code review, and now they
will undergo additional testing during the development period.
If there are new issues in these dependencies discovered, we have
development period to deal with that. We will do this update once
more at the end of the development cycle, by the code freeze, and
so doing it now will make that update smaller and safer.
Overall, this change will help us build confidence that the
Go 1.16 release and its selected dependencies will be robust.
Also increment the Go language version to 1.16 in standard library
go.mod files.
This change was created with a program from CL 256357 patch set 1
(which updates golang.org/x modules only) and the bundle tool at
CL 255053 patch set 1:
$ updatestd -goroot=$HOME/gotip -branch=master
> go version
go version devel +eda1d40544 Mon Sep 21 16:50:07 2020 +0000 darwin/amd64
> go env GOROOT
/Users/dmitshur/gotip
> go version -m /Users/dmitshur/go/bin/bundle
/Users/dmitshur/go/bin/bundle: go1.15.2
path golang.org/x/tools/cmd/bundle
mod golang.org/x/tools (devel) # CL 255053 PS 1
dep golang.org/x/mod v0.3.0 h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=
dep golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
debug/dwarf: speed up SkipChildren for compilation units
For a common pattern of iterating only over top-level compilation units (CU)
Reader.SkipChildren has decode and meterialize all CU subentries just
to skip them, because DW_TAG_compile_unit does not have DW_AT_sibling.
However, CUs have total size encoded before the unit and we already parse them
and know all unit sizes.
Optimize Reader.SkipChildren to use that size when skipping CUs children.
This speeds up iteration over a 1.3GB object file from 7.5s to 0.73s.
Change-Id: I2a8f00955159b4bd13571409f4817805f934cb69
Reviewed-on: https://go-review.googlesource.com/c/go/+/256217
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Than McIntosh <thanm@google.com>
Michael Pratt [Fri, 18 Sep 2020 21:53:12 +0000 (17:53 -0400)]
runtime: expand gopark documentation
unlockf is called after the G is put into _Gwaiting, meaning another G
may have readied this one before unlockf is called.
This is implied by the current doc, but add additional notes to call out
this behavior, as it can be quite surprising.
Updates #40641
Change-Id: I60b1ccc6a4dd9ced8ad2aa1f729cb2e973100b59
Reviewed-on: https://go-review.googlesource.com/c/go/+/256058
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Michael Anthony Knyszek [Mon, 10 Aug 2020 20:02:22 +0000 (20:02 +0000)]
runtime: disable stack shrinking in activeStackChans race window
Currently activeStackChans is set before a goroutine blocks on a channel
operation in an unlockf passed to gopark. The trouble is that the
unlockf is called *after* the G's status is changed, and the G's status
is what is used by a concurrent mark worker (calling suspendG) to
determine that a G has successfully been suspended. In this window
between the status change and unlockf, the mark worker could try to
shrink the G's stack, and in particular observe that activeStackChans is
false. This observation will cause the mark worker to *not* synchronize
with concurrent channel operations when it should, and so updating
pointers in the sudog for the blocked goroutine (which may point to the
goroutine's stack) races with channel operations which may also
manipulate the pointer (read it, dereference it, update it, etc.).
Fix the problem by adding a new atomically-updated flag to the g struct
called parkingOnChan, which is non-zero in the race window above. Then,
in isShrinkStackSafe, check if parkingOnChan is zero. The race is
resolved like so:
* Blocking G sets parkingOnChan, then changes status in gopark.
* Mark worker successfully suspends blocking G.
* If the mark worker observes parkingOnChan is non-zero when checking
isShrinkStackSafe, then it's not safe to shrink (we're in the race
window).
* If the mark worker observes parkingOnChan as zero, then because
the mark worker observed the G status change, it can be sure that
gopark's unlockf completed, and gp.activeStackChans will be correct.
The risk of this change is low, since although it reduces the number of
places that stack shrinking is allowed, the window here is incredibly
small. Essentially, every place that it might crash now is replaced with
no shrink.
This change adds a test, but the race window is so small that it's hard
to trigger without a well-placed sleep in park_m. Also, this change
fixes stackGrowRecursive in proc_test.go to actually allocate a 128-byte
stack frame. It turns out the compiler was destructuring the "pad" field
and only allocating one uint64 on the stack.
Fixes #40641.
Change-Id: I7dfbe7d460f6972b8956116b137bc13bc24464e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/247050
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
runtime: improve error messages after allocating a stack that is too big
In the current implementation, we can observe crashes after calling
debug.SetMaxStack and allocating a stack larger than 4GB since
stackalloc works with 32-bit sizes. To avoid this, we define an upper
limit as the largest feasible point we can grow a stack to and provide a
better error message when we get a stack overflow.
Fixes #41228
Change-Id: I55fb0a824f47ed9fb1fcc2445a4dfd57da9ef8d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/255997
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Giovanni Bajo <rasky@develer.com> Reviewed-by: Keith Randall <khr@golang.org>
unicode/utf8: document the handling of runes out of range in EncodeRune
Document the way EncodeRune currently handles runes which are
out of range. Also add an example showing that behaviour.
Change-Id: I0f8e7645ae053474ec319085a2bb6d7f73bc137c
Reviewed-on: https://go-review.googlesource.com/c/go/+/255998 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Giovanni Bajo <rasky@develer.com>
Trust: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
surechen [Wed, 6 May 2020 12:04:35 +0000 (20:04 +0800)]
math: Remove redundant local variable Ln2
Use the const variable Ln2 in math/const.go for function acosh.
Change-Id: I5381d03dd3142c227ae5773ece9be6c8f377615e
Reviewed-on: https://go-review.googlesource.com/c/go/+/232517 Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Jay Lee [Fri, 18 Sep 2020 05:49:09 +0000 (05:49 +0000)]
time: support colon at start of TZ value
According to POSIX, there are three formats for TZ variable. When
it refers to timezone file, it should starts with a colon. This commit
removes the colon if it exists, so that it keeps compatible with both
the spec and the old behavior.
Change-Id: I30cfeaea530d24e174de309952338cb1146694a5
GitHub-Last-Rev: 11d83d11ca2eca9d542036cf5e23559388fd323e
GitHub-Pull-Request: golang/go#27570
Reviewed-on: https://go-review.googlesource.com/c/go/+/134217
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Change-Id: I61a13f7d6410e4931efaa20307bdf1cc0037afc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/255200
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Change-Id: I2233a6a157ec8feffaefd6a8ee65b1c38778c1cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/255238 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Keith Randall [Fri, 18 Sep 2020 21:19:22 +0000 (14:19 -0700)]
reflect: use zero buffer to back the Value returned by Zero
In the common case (<1KB types), no allocation is required
by reflect.Zero.
Also use memclr instead of memmove in Set when the source
is known to be zero.
Fixes #33136
Change-Id: Ic66871930fbb53328032e587153ebd12995ccf55
Reviewed-on: https://go-review.googlesource.com/c/go/+/192331
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Martin Möhrmann <moehrmann@google.com>
cmd/link: don't mark a symbol's GoType reachable when -linkshared
In CL 231397, we stopped marking symbols' GoType reachable in
general, but not when -linkshared. It was left as a TODO. This CL
addresses it.
The problem was that the type names are mangled in the shared
library, so we need to mangle the name consistently in the
executable as well (regardless of whether the symbol is reachable
or not), so that the GCProg generation code can find the
corresponding symbol from the shared library.
Change-Id: I1040747402929a983ec581109f1681a77893682e
Reviewed-on: https://go-review.googlesource.com/c/go/+/255964
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Keith Randall [Thu, 20 Aug 2020 21:22:30 +0000 (14:22 -0700)]
runtime/debug: provide Addr method for errors from SetPanicOnFault
When we're building a panic that's triggered by a memory fault when
SetPanicOnFault has been called, include an Addr method. This
method reports the address at which the fault occurred.
Fixes #37023
RELNOTE=yes
Change-Id: Idff144587d6b75070fdc861a36efec76f4ec7384
Reviewed-on: https://go-review.googlesource.com/c/go/+/249677
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
David Chase [Wed, 15 Jul 2020 13:07:00 +0000 (09:07 -0400)]
cmd/compile: generate late-lowering static calls
This is testing for the limited case of zero or one SSA-able results.
One regression is that the later expansion of "Dereference" into
Move into argument slots thwarts the
MOVE A -> B, MOVE B -> C
replaced-by
MOVE A -> B, MOVE A -> C
optimization; the second move is written instead as a Dereference at the
phase where the optimization occurs, and because the target of the
dereference is not visible in the dereference, it's not possible to verify
that A and B or A and C don't overlap in some peculiar way (and for results
fed to args, they can).
Regression is repaired in a later CL by changing when calls are expanded.
Change-Id: Ia0f48a9d483d5a54a99657a24b12b25b8edde55f
Reviewed-on: https://go-review.googlesource.com/c/go/+/242782
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Jay Conrod [Fri, 18 Sep 2020 15:48:18 +0000 (11:48 -0400)]
cmd/go/internal/modload: don't report path errors when loading retractions
When we load module retractions from the latest version of a module,
it's possible that the latest version has a different module path than
the version we're loading. This can happen when a module is renamed or
a go.mod file is added for the first time.
We should not report an error in this case. Retractions should still
apply to old aliases of a module.
Fixes #41350
Change-Id: If1bc0b6b2b26fc7023e02fc211aa0cd8eb00796e
Reviewed-on: https://go-review.googlesource.com/c/go/+/255961
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
cmd/link: propagate UsedInIface through method descriptor
The linker prunes methods that are not directly reachable if the
receiver type is never converted to interface. A type can be
converted to interface using reflection through other types.
The linker already takes this into consideration but it missed
the case that the intermediate is a method descriptor. Handle
this case.
Change-Id: I590efc5da163c326db8d43583908a2ef67f65d9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255858
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org>
Matthew Dempsky [Fri, 18 Sep 2020 04:38:42 +0000 (21:38 -0700)]
cmd/compile: more comprehensive tests for #24991
The revised test now checks that unsafe-uintptr correctly works for
variadic uintptr parameters too, and the CL corrects the code so this
code compiles again.
The pointers are still not kept alive properly. That will be fixed by
a followup CL. But this CL at least allows programs not affected by
that to build again.
Updates #24991.
Updates #41460.
Change-Id: If4c39167b6055e602213fb7522c4f527c43ebda9
Reviewed-on: https://go-review.googlesource.com/c/go/+/255877
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Than McIntosh [Thu, 17 Sep 2020 19:35:31 +0000 (15:35 -0400)]
cmd/compile,cmd/asm: dump sym ABI versions for -S=2
When -S=2 is in effect for the compiler/assembler, include symbol ABI
values for defined symbols and relocations. This is intended to help
make it easier to distinguish between a symbol and its ABI wrapper.
Change-Id: Ifbf71372392075f15363b40e882b2132406b7d6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255718
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
Than McIntosh [Thu, 17 Sep 2020 19:31:07 +0000 (15:31 -0400)]
cmd/asm: make asm -S flag consistent with compile -S flag
Change things so that the -S command line option for the assembler
works the same as -S in the compiler, e.g. you can use -S=2 to
get additional detail.
Change-Id: I7bdfba39a98e67c7ae4b93019e171b188bb99a2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255717
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Jay Conrod [Thu, 17 Sep 2020 19:54:13 +0000 (15:54 -0400)]
cmd/go: flip relationship between load and modload
Previously, modload imported load, but it mainly just did so in order
to install callbacks to the modload API. This was important during vgo
development, but there's no longer a strong reason to do this. Nothing
modload imports strongly depends on load, so there's little danger of
a dependency cycle.
This change deletes the callbacks in load and instead, makes load call
exported functions in modload directly. In the future, these functions
may have different signatures than their GOPATH counterparts.
Change-Id: Ifde5c3ffebd190b5bd184924ec447d272b936f27
Reviewed-on: https://go-review.googlesource.com/c/go/+/255719
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Keith Randall [Thu, 17 Sep 2020 16:55:23 +0000 (09:55 -0700)]
cmd/compile: propagate go:notinheap implicitly
//go:notinheap
type T int
type U T
We already correctly propagate the notinheap-ness of T to U. But we
have an assertion in the typechecker that if there's no explicit
//go:notinheap associated with U, then report an error. Get rid of
that error so that implicit propagation is allowed.
Adjust the tests so that we make sure that uses of types like U
do correctly report an error when U is used in a context that might
cause a Go heap allocation.
Fixes #41451
Update #40954
Update #41432
Change-Id: I1692bc7cceff21ebb3f557f3748812a40887118d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255637
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
cmd/addr2line: don't assume that GOROOT_FINAL is clean
Fixes #41447
Change-Id: I4460c1c7962d02c41622a5ea1a3c4bc3714a1873
Reviewed-on: https://go-review.googlesource.com/c/go/+/255477
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
David Chase [Mon, 13 Jul 2020 18:44:14 +0000 (14:44 -0400)]
cmd/compile: add variable length TRESULTS type for SSA use.
This type is very much like TTUPLE, but not just for pairs.
Used to describe results of a pre-expansion function call.
(will later probably also be used to describe the incoming args).
Change-Id: I811850cfcc2b3de85085eb4c2eca217c04c330b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/242360
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Alex Opie [Thu, 17 Sep 2020 04:31:50 +0000 (04:31 +0000)]
cmd/go: use the correct linker config in the buildID hash
The linker config is hashed into the buildID; however,
the GOROOT_FINAL environment variable that is
actually used when -trimpath is specified was not
reflected in that hash. This change fixes that.
Fixes #38989
Change-Id: I418a21a9f6293ca63c101d22b501dfdba8e91ac6
GitHub-Last-Rev: 4cf82920e4a76173c5cb5359b059e87ee7fc7f51
GitHub-Pull-Request: golang/go#40296
Reviewed-on: https://go-review.googlesource.com/c/go/+/243557
Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Jay Conrod [Tue, 15 Sep 2020 16:59:05 +0000 (12:59 -0400)]
cmd/go: prepare tests for GO111MODULE=on by default
Set GO111MODULE=off explicitly in tests specific to GOPATH mode.
Added a go.mod file to other tests that assumed GOPATH mode.
Fixed an issue in the build metadata file generated in
modload/build.go, which did not end with a newline. This broke the
build_dash_x test, which expects to be able to run the script printed
by 'go build -x' to produce the same result. The script is broken if
the build metadata file doesn't end with a newline.
Change-Id: I59f2a492a9f5a66f6c4aa702f429909d5c5e815d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255051
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Lynn Boger [Mon, 31 Aug 2020 13:43:40 +0000 (09:43 -0400)]
cmd/compile: use combined shifts to improve array addressing on ppc64x
This change adds rules to find pairs of instructions that can
be combined into a single shifts. These instruction sequences
are common in array addressing within loops. Improvements can
be seen in many crypto packages and the hash packages.
These are based on the extended mnemonics found in the ISA
sections C.8.1 and C.8.2.
Some rules in PPC64.rules were moved because the ordering prevented
some matching.
Joel Sing [Tue, 18 Aug 2020 17:07:26 +0000 (03:07 +1000)]
cmd/internal/obj/riscv: clean up lowerJALR
This cleans up the last of the direct obj.Prog rewriting, removing lowerJALR
and replacing it with correct handling for AJALR during instruction encoding.
Change-Id: Ieea125bde30d4c0edd2d9ed1e50160543aa8f330
Reviewed-on: https://go-review.googlesource.com/c/go/+/249077 Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Joel Sing <joel@sing.id.au>
syscall, cmd/go/internal/lockedfile/internal/filelock: add and use Flock on illumos
Copy the syscall wrapper from golang.org/x/sys/unix CL 255377 to provide
Flock on illumos and switch cmd/go/internal/lockedfile/internal/filelock
to use it.
Matthew Dempsky [Wed, 16 Sep 2020 22:41:47 +0000 (15:41 -0700)]
cmd/compile: skip looking for OCLOSURE nodes in xtop
xtop holds package's top-level declaration statements, but OCLOSURE
only appears in expression contexts. xtop will instead hold the
synthetic ODCLFUNC representing OCLOSURE's function body.
This CL makes the loop consistent with the later phases that only look
for ODCLFUNC nodes in xtop.
Passes toolstash-check.
Change-Id: I852a10ef1bf75bb3351e3da0357ca8b2e26aec6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/255340
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
David Chase [Fri, 26 Jun 2020 22:19:01 +0000 (18:19 -0400)]
cmd/compile: make translation to calls for SSA look more "value-oriented"
The existing translation assumes an in-memory return values, thus it returns
the address of the result(s). Most consumers immediately load from the
address to get the value, and in late call expansion that is the favored idiom,
and it is also the favored idiom when arguments and results use registers
instead of memory.
Change-Id: Ie0ccc70f399682a42509d847b330ef3956462d56
Reviewed-on: https://go-review.googlesource.com/c/go/+/240186
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
David Chase [Fri, 12 Jun 2020 17:48:26 +0000 (13:48 -0400)]
cmd/compile: introduce special ssa Aux type for calls
This is prerequisite to moving call expansion later into SSA,
and probably a good idea anyway. Passes tests.
This is the first minimal CL that does a 1-for-1 substitution
of *ssa.AuxCall for *obj.LSym. Next step (next CL) is to make
this change for all calls so that additional information can
be stored in AuxCall.
Change-Id: Ia3a7715648fd9fb1a176850767a726e6f5b959eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/237680
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Alberto Donizetti [Wed, 16 Sep 2020 11:13:50 +0000 (13:13 +0200)]
cmd/compile: be more specific in cannot assign errors
"cannot assign to" compiler errors are very laconic: they never
explain why the lhs cannot be assigned to (with one exception, when
assigning to a struct field in a map).
This change makes them a little more specific, in two more cases: when
assigning to a string, or to a const; by giving a very brief reason
why the lhs cannot be assigned to.
Change-Id: I244cca7fc3c3814e00e0ccadeec62f747c293979
Reviewed-on: https://go-review.googlesource.com/c/go/+/255199
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Michael Anthony Knyszek [Wed, 16 Sep 2020 17:08:55 +0000 (17:08 +0000)]
runtime: actually fix locking in BenchmarkMSpanCountAlloc
I just submitted CL 255297 which mostly fixed this problem, but totally
forgot to actually acquire/release the heap lock. Oops.
Updates #41391.
Change-Id: I45b42f20a9fc765c4de52476db3654d4bfe9feb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/255298
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Keith Randall [Thu, 27 Aug 2020 21:05:52 +0000 (14:05 -0700)]
cmd/compile: make go:notinheap error message friendlier for cgo
Update #40954
Change-Id: Ifaab7349631ccb12fc892882bbdf7f0ebf3d845f
Reviewed-on: https://go-review.googlesource.com/c/go/+/251158
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
Keith Randall [Wed, 26 Aug 2020 21:17:35 +0000 (14:17 -0700)]
cmd/cgo: use go:notinheap for anonymous structs
They can't reasonably be allocated on the heap. Not a huge deal, but
it has an interesting and useful side effect.
After CL 249917, the compiler and runtime treat pointers to
go:notinheap types as uintptrs instead of real pointers (no write
barrier, not processed during stack scanning, ...). That feature is
exactly what we want for cgo to fix #40954. All the cases we have of
pointers declared in C, but which might actually be filled with
non-pointer data, are of this form (JNI's jobject heirarch, Darwin's
CFType heirarchy, ...).
Fixes #40954
Change-Id: I44a3b9bc2513d4287107e39d0cbbd0efd46a3aae
Reviewed-on: https://go-review.googlesource.com/c/go/+/250940
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Keith Randall [Wed, 26 Aug 2020 21:07:35 +0000 (14:07 -0700)]
cmd/compile: allow aliases to go:notinheap types
The alias doesn't need to be marked go:notinheap. It gets its
notinheap-ness from the target type.
Without this change, the type alias test in the notinheap.go file
generates these two errors:
notinheap.go:62: misplaced compiler directive
notinheap.go:63: type nih must be go:notinheap
The first is a result of go:notinheap pragmas not applying
to type alias declarations.
The second is the result of then trying to match the notinheap-ness
of the alias and the target type.
Add a few more go:notinheap tests while we are here.
Update #40954
Change-Id: I067ec47698df6e9e593e080d67796fd05a1d480f
Reviewed-on: https://go-review.googlesource.com/c/go/+/250939
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Trust: Keith Randall <khr@golang.org>