A while back in this release the sanitizer tests were enabled
for ppc64le, where previously they were never run. This
uncovered some errors in these tests on ppc64le. One linker
fix was made but there are still bugs in how tsan is made to
work within the code, especially in how signals are enabled
with cgo.
Some attempts were made to make this work but intermittent
failures continue to happen with the Trybots so I am just
going to disable this test for ppc64le within cmd/dist.
Updates #45040
Change-Id: I5392368ccecd4079ef568d0c645c9f7c94016d99
Reviewed-on: https://go-review.googlesource.com/c/go/+/315430
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Because x/arch is now lazy, this removes the checksum for rsc.io/pdf
from the go.sum file: the requirements of rsc.io/pdf are known not to
be relevant to any package imported within the cmd packages.
For #36460
Updates #36905
Change-Id: I3abb6a8029cd0c9099b592ccb01ca5606c93edec
Reviewed-on: https://go-review.googlesource.com/c/go/+/316110
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
It seems like getgrouplist is supported since Solaris 11.3 (released in
2016):
https://docs.oracle.com/cd/E86824_01/html/E54766/getgrouplist-3c.html
Use it to implement (*User).GroupIds on solaris, like on other Unix
platforms.
Unfortunately it looks like getgrouplist was added to illumos only
fairly recently, see
f2c438c505
Thus, don't use it on GOOS=illumos for now.
Updates #14709
Change-Id: Ibfcdbfca6b7d1af96630512d08921e5637ca76d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/315278
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Follow CL 23967 and CL 24021 which did the same on linux and freebsd,
respectively.
Updates #13987
Updates #16028
Change-Id: Ia30ef8b5cffd8f9eb75c29ee5fe350dac2be6d44
Reviewed-on: https://go-review.googlesource.com/c/go/+/315279
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously calling fmt.Sprintf("%#v", t) on a time.Time value would
yield a result like:
time.Time{wall:0x0, ext:63724924180, loc:(*time.Location)(nil)}
which does not compile when embedded in a Go program, and does not
tell you what value is represented at a glance.
This change adds a GoString method that returns much more legible
output:
"time.Date(2009, time.February, 5, 5, 0, 57, 12345600, time.UTC)"
which gives you more information about the time.Time and also can be
usefully embedded in a Go program without additional work.
Update Quote() to hex escape non-ASCII characters (copying logic
from strconv), which makes it safer to embed them in the output of
GoString().
Fixes#39034.
Change-Id: Ic985bafe4e556f64e82223c643f65143c9a45c3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/267017
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Print the packages where the duplicates come from.
Change-Id: Ib3dc9aa0a3f5ddd97b03744be6d01d4bfcb33996
Reviewed-on: https://go-review.googlesource.com/c/go/+/315949
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>
Currently, when ABI wrappers are used, we don't use ABI aliases.
One exception is shared linkage. When loading a shared library, if
a symbol has only one ABI, and the name is not mangled, we don't
know what ABI it is, so we have to use ABI aliases.
This CL makes it always mangle ABIInternal function name in shared
linkage, so we know what ABI to choose when loading a shared
library. And we now can fully stop using ABI aliases when ABI
wrappers are used.
Change-Id: Id15d9cd72a59f391f54574710ebba7dc44cb6e23
Reviewed-on: https://go-review.googlesource.com/c/go/+/315869
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This is a port of CL 315729 to go/types, adjusted for the slightly
different test set-up in go/types.
Added a TODO to reconcile these differences.
Change-Id: I71cae712d8fc23b7311ce35e09168b258e07fa35
Reviewed-on: https://go-review.googlesource.com/c/go/+/315850
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a 1:1 port of CL 315689 to go/types.
Change-Id: If71186b3719be8433c9d21b22c51ffde2cadd55b
Reviewed-on: https://go-review.googlesource.com/c/go/+/315849
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of CL 315169 to go/types. It uses a slightly different
mechanism for evaluating the convertibility error message, to be
consistent with operand.assignableTo.
Change-Id: Iea2e2a9fbb4cf17d472b2b7392786118e079528a
Reviewed-on: https://go-review.googlesource.com/c/go/+/315809
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Convert the syscall package on openbsd/386 to use libc rather than performing
direct system calls.
Updates #36435
Change-Id: Ifcfbca0e6b933762596a564243caa850dac01442
Reviewed-on: https://go-review.googlesource.com/c/go/+/287654
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Use libc rather than performing direct system calls for the runtime on
openbsd/386.
Updates #36435
Change-Id: I0cd65368bc824c81f5f98ea24e4f82db5468b170
Reviewed-on: https://go-review.googlesource.com/c/go/+/287653
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If something "huge" is allocated, and the zeroing is trivial (no pointers
involved) then zero it by chunks in a loop so that preemption can occur,
not all in a single non-preemptible call.
Benchmarking suggests that 256K is the best chunk size.
Updates #42642.
Change-Id: I94015e467eaa098c59870e479d6d83bc88efbfb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/270943
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
In Cl 302071 we changed the compiler to use a different recipe for
selecting the DWARF frame offset for output parameters, to reflect the
fact that registerized output params don't have a stack memory
location on entry to the function. In the process, however, we
switched from using an abbrev pf DW_ABRV_PARAM to an abbrev of
DW_ABRV_AUTO, which means that Delve can't recognize them correctly.
To fix the problem, switch back to picking the correct abbrev entry,
while leaving the new offset recipe intact.
Updates #40724.
Updates #45720.
Change-Id: If721c9255bcd030177806576cde3450563f7a235
Reviewed-on: https://go-review.googlesource.com/c/go/+/315610
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>
When constructing multi-piece DWARF location expressions for
struct-typed parameters using the register ABI, make sure that the
location expressions generated properly reflect padding between
elements (this is required by debuggers). Example:
type small struct { x uint16 ; y uint8 ; z int32 }
func ABC(p1 int, p2 small, f1 float32) {
...
In the DWARF location expression for "p2" on entry to the routine, we
need pieces for each field, but for debuggers (such as GDB) to work
properly, we also need to describe the padding between elements. Thus
instead of
<rbx> DW_OP_piece 2 <rcx> DW_OP_piece 1 <rdi> DW_OP_piece 4
we need to emit
<rbx> DW_OP_piece 2 <rcx> DW_OP_piece 1 DW_OP_piece 1 <rdi> DW_OP_piece 4
This patch adds a new helper routine in abiutils to compute the
correct padding amounts for a struct type, a unit test for the helper,
and updates the debug generation code to call the helper and insert
apadding "piece" ops in the right spots.
Updates #40724.
Updates #45720.
Change-Id: Ie208bee25776b9eb70642041869e65e4fa65a005
Reviewed-on: https://go-review.googlesource.com/c/go/+/315071
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Revise the code that generates DWARF location expressions for input
parameters to get it to work properly with the new register ABI when
optimization is turned off.
The previously implementation assumed stack locations for all
input+output parameters when -N (disable optimization) was in effect.
In the new implementation, a register-resident input parameter is
given a 2-element location list, the first list element pointing to
the ABI register(s) containing the param, and the second element
pointing to the stack home once it has been spilled.
NB, this change fixes a bunch of the Delve pkg/proc unit tests (maybe
about half of the outstanding failures). Still a good number that need
to be investigated, however.
Updates #40724.
Updates #45720.
Change-Id: I743bbb9af187bcdebeb8e690fdd6db58094ca415
Reviewed-on: https://go-review.googlesource.com/c/go/+/314431
Trust: Than McIntosh <thanm@google.com>
Trust: Cherry Zhang <cherryyz@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>
It is documented elsewhere in the package documentation but this additional
mention of it will hopefully reduce confusion.
Fixes#44261
Change-Id: I4e9d8f4564ebb7fbe047c92ee2cdffedb39f2a31
GitHub-Last-Rev: 64b6421503
GitHub-Pull-Request: golang/go#45839
Reviewed-on: https://go-review.googlesource.com/c/go/+/314969
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Include a NOP with the SP in order to disable/bypass vet asmdecl checks
for runtime.mstart_stub on openbsd/386. Without this we get:
runtime/sys_openbsd_386.s:33:1: [386] mstart_stub: use of 32(SP) points beyond argument frame
Change-Id: I834ae3dbceffcb5776481b076ec2afe3700671cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/315789
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
The SSA code for debug variable location analysis (for DWARF) has two
special 'sentinel' values that it uses to handshake with the
debugInfo.GetPC callback when capturing the PC values of debug
variable ranges after prog generatoin: "BlockStart" and "BlockEnd".
"BlockStart" has the expected semantics: it means "the PC value of the
first instruction of block B", but "BlockEnd" does not mean "PC value
of the last instruction of block B", but rather it is implemented as
"the PC value of the last instruction of the function". This causes
confusion when reading the code, and seems to to result in implementation
flaws in the past, leading to incorrect ranges in some cases.
To help with this, add a new sentinel "FuncEnd" (which has the "last
inst in the function" semantics) and change the implementation of
"BlockEnd" to actually mean what its name implies (last inst in
block).
Updates #45720.
Change-Id: Ic3497fb60413e898d2bfe27805c3db56483d12a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/314930
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>
Use %q instead of %s to print unchecked bytes. Also strip the
"\x00" byte, as "go116ld" reads better than "\x00go116ld".
Change-Id: Id3d1f426ea91d53a55b928dac4a68e1333b80158
Reviewed-on: https://go-review.googlesource.com/c/go/+/315750
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Switch openbsd/386 to locking via libc, rather than performing direct
system calls.
Update #36435
Change-Id: I8198171e21f9acf28846ad723ea9ff48f7c8a69d
Reviewed-on: https://go-review.googlesource.com/c/go/+/287652
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This switches openbsd/386 to thread creation via pthreads, rather than doing
direct system calls.
Update #36435
Change-Id: I000a815fc0edd0272c3285954f3f007229bc60a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/250577
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The comment for this special case claims:
> There's no directory for import "C" or import "unsafe".
However, there clearly is a directory for "unsafe" in
GOROOT/src/unsafe, and all of our integration tests seem to pass
without this special case. As far as I can tell, it's just confusing.
Also note that the internal/goroot package explicitly considers
package "unsafe" to be in the standard library; see CL 137435.
For #36460
Change-Id: Ib857d18f731a7f3c911c1bd116a34e3a9b3d74a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/315412
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
GODEBUG=lazymod=log causes the go command to log a stack dump whenever
the full module graph is loaded in a lazy module.
GODEBUG=lazymod=strict does the same, but also terminates the command
with a nonzero exit code.
For #36460
Change-Id: Ia5a4c46069044bcc157b285f64c2392990d70bd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/315411
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
In order to prevent edit wars with previous cmd/go releases,
the new version annotations are only included if the main module
specifies 'go 1.17' or higher.
Fixes#36876
Change-Id: Iba15e47dd1ac2c16d754679a9b501db4069fa250
Reviewed-on: https://go-review.googlesource.com/c/go/+/315409
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This change adds two possible upgrade paths for lazy loading:
1. Run 'go mod tidy -go=1.17'.
2. Starting in a module with no existing 'go' directive,
run any 'go' command that updates the go.mod file.
In the latter case, commands other than 'go mod tidy'
may leave the go.mod file *very* untidy if it had non-trivial
dependencies. (The 'go' invocation will promote all
implicit eager dependencies to explicit lazy ones,
which preserves the original module graph — most of which is
not actually relevant.)
'go mod tidy -go=1.17' can be used to enable lazy loading without
accidentally downgrading existing transitive dependencies.
'go mod tidy -go=1.16' can be used to disable lazy loading and clear
away redundant roots in a single step (if reducing the go version), or
to prune away dependencies of tests-of-external-tests (if increasing
the go version).
'go mod tidy -go=1.15' can be used to add dependencies of
tests-of-external-tests, although there isn't much point to that.
DO NOT MERGE
This change still needs an explicit test and a release note.
Fixes#45094
For #36460
Change-Id: I68f057e39489dfd6a667cd11dc1e320c1ee1aec1
Reviewed-on: https://go-review.googlesource.com/c/go/+/315210
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
For #36460
For #41297
Updates #29666
Change-Id: I5f324c0ef9a164f8043d2188101d141bb5fa7454
Reviewed-on: https://go-review.googlesource.com/c/go/+/309191
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
For #36460
For #29666
Change-Id: I9e46f7054d52c053be80c483757cdd34b22822d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/309190
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
For #36460
Change-Id: I606314054bd9064f7c4053f56049fabbaec54143
Reviewed-on: https://go-review.googlesource.com/c/go/+/309189
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
For #36460
Change-Id: Ibdbaa893ded772617e22f12db7a0463604db5195
Reviewed-on: https://go-review.googlesource.com/c/go/+/308516
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
For #36460
Change-Id: Ib4b1baea35826c3e359456f8dba09a49283e7fee
Reviewed-on: https://go-review.googlesource.com/c/go/+/315069
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This change activates the dormant “lazy loading” codepaths added in CL
265777 and its predecessors. Dependencies of modules that declare 'go
1.17' or higher are loaded lazily, and the dependencies in the go.mod
file maintain additional invariants to support more efficient lazy
loading for downstream dependent modules.
See https://golang.org/design/36460-lazy-module-loading for the
detailed design.
For #36460
Change-Id: Ic12ee7842aef9580357fcf8909d87654fcb2ad12
Reviewed-on: https://go-review.googlesource.com/c/go/+/314634
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This will permit us to write ABIInternal assembler code for linux-amd64.
For #40724
Change-Id: I681866651554eda4229d6faa7f0c1ba42d07e57d
Reviewed-on: https://go-review.googlesource.com/c/go/+/315390
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TestManual is used for debugging; in this case we usually want to
see error messages reported rather than checked against ERROR comments
in the provided files. Make this the default. Use the new -verify
flag to verify reported errors against ERROR comments.
With this change we cannot get an error list for the non-manual
tests, but that is usually not useful anyway because there are
usually many errors in those test files. Run those tests manually
instead.
Also, corrected -lang flag synopsys: it applies to all tests, not
just TestManual.
Change-Id: I56e0ea0583840fc3ea150d9ccfc330370b66191c
Reviewed-on: https://go-review.googlesource.com/c/go/+/315729
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Running the TestManual test (for manual debugging) requires
user-provided files as input. Rather than using another flag
(-files) to provide these files, just use the (remaining)
command line arguments.
Change-Id: I9b20d9f1a6a7ce839bbd690c311ce3f0d0a10496
Reviewed-on: https://go-review.googlesource.com/c/go/+/315689
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The Go object file format can change from version to version.
Tools like cmd/objdump and cmd/nm only onderstand the current
version of the object file. Currently, when it encounters an
object built with a different version of the toolchain, it emits
a generic error "unrecognized object file", which is not very
helpful for users. This CL makes it emit a clearer error. Now it
emits
objdump: open go116.o: go object of a different version: go116ld
Change-Id: I063c6078ed1da78f97cea65796779ae093a1a8cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/315609
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>
Adds a method within Values for detecting whether a query parameter is set.
Fixes#45100
Change-Id: I6bb49417e8547e11cc7e8d55c5211d24ee436ec1
GitHub-Last-Rev: 0b27cdab90
GitHub-Pull-Request: golang/go#45835
Reviewed-on: https://go-review.googlesource.com/c/go/+/314850
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Change-Id: I897864984bd4b79f2e224ea1a7f323e0bd5e2ef0
GitHub-Last-Rev: b85415541d
GitHub-Pull-Request: golang/go#45849
Reviewed-on: https://go-review.googlesource.com/c/go/+/314991
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ben Shi <powerman1st@163.com>
Trust: Matthew Dempsky <mdempsky@google.com>
golang.org/cl/284138 introduced a regression: running "gofmt foo" would
silently ignore the file due to its lack of a ".go" extension, whereas
the tool is documented otherwise:
Given a file, it operates on that file; given a directory, it
operates on all .go files in that directory, recursively.
This wasn't caught as there were no tests for these edge cases. gofmt's
own tests are regular Go tests, so it's hard to test it properly without
adding an abstraction layer on top of func main.
Luckily, this kind of test is a great fit for cmd/go's own script tests,
and it just takes a few straightforward lines.
Finally, add the relevant logic back, with documentation to clarify its
intentional purpose.
Fixes#45859.
Change-Id: Ic5bf5937b8f95fcdad2b6933227c8b504ef38a82
Reviewed-on: https://go-review.googlesource.com/c/go/+/315270
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Robert Griesemer <gri@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Sort the comment map entries before printing.
Makes it easier to use the output for debugging.
For #39753.
Change-Id: Ic8e7d27dd2df59173e2c3a04a6b71ae966703885
Reviewed-on: https://go-review.googlesource.com/c/go/+/315370
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
These generate similar machine code sequences to
other symbol accesses, therefore we should merge them.
Change-Id: Id8ead284d430fadd2e58bad255deb465498dfade
Reviewed-on: https://go-review.googlesource.com/c/go/+/314109
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
When the class of p.To is C_NAUTO4K, STP series instructions will be translated
into add/sub + stp instructions, the total size is 8. Currently this size
value in optab is 12, this CL fixes it.
Change-Id: Ife1b9e9f8a28edca9b59f62b45a80d83f38993b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/314210
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
There's no reason not to, and it'll help me test an upcoming fix
for #43956. The API additions look reasonable to me, and they'll
go through a more comprehensive API audit during the freeze.
Change-Id: I0daa6e978b199d69568f5100fdfc1b4bcfaeaef2
Reviewed-on: https://go-review.googlesource.com/c/go/+/315349
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The original value was rounded too early, which lead to the
surprising behavior that float64(math.SmallestNonzeroFloat64 / 2)
wasn't 0. That is, the exact compile-time computation of
math.SmallestNonzeroFloat64 / 2 resulted in a value that was
rounded up when converting to float64. To address this, added 3
more digits to the mantissa, ending in a 0.
While at it, also slightly increased the precision of MaxFloat64
to end in a 0.
Computed exact values via https://play.golang.org/p/yt4KTpIx_wP.
Added a test to verify expected behavior.
In contrast to the other (irrational) constants, expanding these
extreme values to more digits is unlikely to be important as they
are not going to appear in numeric computations except for tests
verifying their correctness (as is the case here).
Re-enabled a disabled test in go/types and types2.
Updates #44057.
Fixes#44058.
Change-Id: I8f363155e02331354e929beabe993c8d8de75646
Reviewed-on: https://go-review.googlesource.com/c/go/+/315170
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
