Since x/tools is now lazy, this removes a significant fraction of
otherwise-irrelevant dependencies from the go.sum file.
The remaining extraneous go.sum lines come from the dependency on
github.com/google/pprof. Since that module is outside of the Go
project proper, I do not plan to submit a PR to make it lazy until
after the Go 1.17 release.
For #36460
Updates #36905
Change-Id: I214492cf931fca797817124ecdcbccd4ebb7505b
Reviewed-on: https://go-review.googlesource.com/c/go/+/316452
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
The outdated comment in modfile.go was missed in CL 315409.
Upon a closer look at the test case in mod_go_version_vendor.txt, it
is almost completely redundant with the new test in
mod_vendor_goversion.txt. Make it completely redundant and remove it.
Updates #36876
Change-Id: Ibcd1f6b426460aaafbd6dc0be93078547904572b
Reviewed-on: https://go-review.googlesource.com/c/go/+/316209
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>
Because x/crypto is now lazy, this removes the remaining checksums for
older-than-selected dependencies from src/go.sum.
It also removes a significant fraction of the irrelevant checksums
from src/cmd/go.sum.
For #36460
Updates #36905
Change-Id: I33af5fc638aa1d1c66df3a1d86542912e95a7f50
Reviewed-on: https://go-review.googlesource.com/c/go/+/316451
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Even though x/mod is now lazy, this has no immediate effect on the
size of cmd/go.sum: all of the existing dependencies are still pulled
in via the dependency on x/tools, which is itself not yet lazy (that's
CL 315570).
For #36460
Updates #36905
Change-Id: I7bce5fe2596a2d71e4df08f5d5f4cb8dcdb8512c
Reviewed-on: https://go-review.googlesource.com/c/go/+/316489
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
We were already setting GIT_SSH_COMMAND (if unset) to explicitly
include 'ControlMaster=no' in order to disable connection pooling.
Now we also set 'BatchMode=yes' to suppress password prompts for
password-protected keys.
While we're here, we also set GCM_INTERACTIVE=never to suppress
similar prompts from the Git Credential Manager for Windows.
Fixes#44904
Change-Id: Iebb050079ff7dd54d5b944c459ae212e9e6f2579
Reviewed-on: https://go-review.googlesource.com/c/go/+/300157
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>
Lots of constant SSA values we put in the entry block so that
CSE can easily combine them. With -N, however, we don't run CSE, so
putting values in the entry block only serves to extend their lifetime
for no benefit.
Fixes#45897. The number of live SSA values per block goes from >5K to 22.
Memory use goes from ~3GB to ~400MB.
Change-Id: I620b423611790a900e0d4cd270eac5dbdddf2a2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/316369
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This is part of getting debugging into good shape
with the register ABI. (This may generate a backport
for 1.16, there was some regression there as well.)
This is not necessarily fully-baked yet; my goal is to
make it work "well enough" for actual debugging, then
revisit the metrics, which are currently ignorant
of registers used for passing parameters (currently,
rejects them as a valid option).
Updates #40724.
Change-Id: Ib649adf39f947b7b54895c5bf181cf48ca4d38a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/311689
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>
At this time, the golang.org/s/release process arranges such that the
api/go1.n.txt file is created when a Go 1.N Beta 1 release is being cut.
The API check is currently configured so that tests don't fail visibly
even if api/go1.n.txt becomes a subset of the actual API additions in
the upcoming Go 1.N release as long as 'go version' has "devel" in it.
The first time that 'go version' output drops the "devel" substring
during testing is after the release-branch.go1.N branch is created
as part of the process to cut a Go 1.N Release Candidate 1 release.
The month or so between Beta 1 and RC 1 is well into the freeze and
deliberate API changes are rare and very intentional. There seems to
be agreement that it's healthy to make the API check stricter during
that time period. Doing so will ensure that api/go1.n.txt cannot get
stale after creation without anyone noticing, and may catch CLs that
don't have the intended diff on the API.
This CL changes behavior to be simple and clear: from the moment
an api/go1.n.txt file corresponding to the current Go version in
development is added to the tree, silent API additions stop being
permitted.
This CL also moves the magical "override the value of -allow_new flag
if runtime.Version() contains 'devel' string" behavior from cmd/api
command to the run.go script that calls it, making the CLI of cmd/api
itself less surprising.
Fixes#43956.
Change-Id: I89468207573f7ccdbc9f12625dcdd3ef2bcf8f10
Reviewed-on: https://go-review.googlesource.com/c/go/+/315350
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
As a side effect, this also upgrades x/sys to the version currently
required by the latest x/net.
Because x/net is now lazy, it no longer requires checksums for
older-than-selected versions of x/sys, x/term, and x/text.
For #36460
Updates #36905
Change-Id: I242815e202aa7d482fc3983a6717bece10ea8111
Reviewed-on: https://go-review.googlesource.com/c/go/+/316251
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>
Even though x/term is now lazy, this has no overall effect (yet) on
the contents of cmd/go.sum, because the dependency that would be
pruned out (an old version of x/sys) is still transitively required
through x/crypto, x/sys, and/or x/tools.
Once those modules are also lazy (CL 316109, CL 316111, and CL 315570
respectively), the extra go.sum entries for x/sys will drop out.
For #36460
Updates #36905
Change-Id: I79e715328f7c417ea20ae8fe4f8e0e3eb71ee6c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/316250
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>
CL 312214 added unsafe.{Add,Slice}, which may appears in expression that
evaluating requires function calls. "mayCall" does not handle that
case, causing linux-amd64-noopt builder failed.
Fixes#45917
Change-Id: I900aefb702122480be621355def3d2c20eadbe70
Reviewed-on: https://go-review.googlesource.com/c/go/+/316170
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Assignment between input parameters causes them to have more than
one "Name", and running this backwards from names to values can end
up confusing (conflating) parameter spill slots.
Around 105a6e9518, this cases a stack overflow running
go test -race encoding/pem
because two slice parameters spill (incorrectly) into the same
stack slots (in the AB?I-defined parameter spill area).
This also tickles a failure in cue, which turned out to be
easier to isolate.
Fixes#45851.
Updates #40724.
Change-Id: I39c56815bd6abb652f1ccbe83c47f4f373a125c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/313212
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>
When regabi is used sorting by stack offset will not preserve the order
of function arguments. Trust that variables are already ordered
correctly when creating debug_info entries.
Fixes#45720
Change-Id: I1dbdd185975273f70244a23302d34f082347603d
Reviewed-on: https://go-review.googlesource.com/c/go/+/315280
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Jeremy Faller <jeremy@golang.org>
Fix up a slightly stale comment in the part of ssa generation that
zeros ambiguously live variables: with the advent of the register ABI,
the ir.Func "Dcl" slice is no longer entirely sorted by frame offset,
although this is still the case for the local vars in Dcl.
Change-Id: I633f43d16f0d4e0b444193a6edb6b2aa1154eea7
Reviewed-on: https://go-review.googlesource.com/c/go/+/316309
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>
Currently we have two code paths of writing the text segment. They
are semantically the same:
- if we split text sections, we write all ".text" sections as
text and the the rest as data.
- if we do not split text sections, we write the first section
as text and the rest as data. The first section is named ".text"
and is the only one in this case.
Unify the code.
Change-Id: Ic639eed625615be3c8a8d41f5b47e901552f587a
Reviewed-on: https://go-review.googlesource.com/c/go/+/316049
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For ABI0 assembly functions that have Go declarations, generate
traceback argument info and attach it to the assembly functions.
So we can print argument in tracebacks if e.g. assembly function
panics.
Only do this for ABI0 functions, as for ABIInternal assembly
functions it is likely that they never spill arguments to memory.
Change-Id: I7e601ccd9aded5e6af2f02be975bf81ff9948f4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/315870
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 "..." argument is passed to non-variadic function, the
compiler may skip that check, but continue checking whether the number
of arguments matches the function signature.
That causes the sanity check which was added in CL 255241 trigger.
Instead, we should report an invalid use of "...", which matches the
behavior of new type checker and go/types.
Fixes#45913
Change-Id: Icbb254052cbcd756bbd41f966c2c8e316c44420f
Reviewed-on: https://go-review.googlesource.com/c/go/+/315796
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When creating programs with large text sections on ppc64le,
trampolines are needed for calls that are too far; however
they are not created if the code is generated such that the TOC
register r2 is initialized and maintained in the code because
then the external linker can create the trampolines. Previously
the function DynlinkingGo was used to determine this but in the
case where plugins are used, this could return true even though
r2 is not valid.
To fix this problem I've added a new function r2Valid which returns
true when the build options indicate that the r2 is
initialized and maintained. Because of the ways that
DynlinkingGo is used I wanted to maintain its previous
behavior.
Fixes#45850
Change-Id: I6d902eba6ad41757aa6474948b79acdbd479cb38
Reviewed-on: https://go-review.googlesource.com/c/go/+/315289
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Currently, for stack objects, the compiler emits metadata that
includes the offset and type descriptor for each object. The type
descriptor symbol has many fields, and it references many other
symbols, e.g. field/element types, equality functions, names.
Observe that what we actually need at runtime is only the GC
metadata that are needed to scan the object, and the GC metadata
are "leaf" symbols (which doesn't reference other symbols). Emit
only the GC data instead. This avoids bringing live the type
descriptor as well as things referenced by it (if it is not
otherwise live).
This reduces binary sizes:
old new
hello (println) 1187776 1133856 (-4.5%)
hello (fmt) 1902448 1844416 (-3.1%)
cmd/compile 22670432 22438576 (-1.0%)
cmd/link 6346272 6225408 (-1.9%)
No significant change in compiler speed.
name old time/op new time/op delta
Template 184ms ± 2% 186ms ± 5% ~ (p=0.905 n=9+10)
Unicode 78.4ms ± 5% 76.3ms ± 3% -2.60% (p=0.009 n=10+10)
GoTypes 1.09s ± 1% 1.08s ± 1% -0.73% (p=0.027 n=10+8)
Compiler 85.6ms ± 3% 84.6ms ± 4% ~ (p=0.143 n=10+10)
SSA 7.23s ± 1% 7.25s ± 1% ~ (p=0.780 n=10+9)
Flate 116ms ± 5% 115ms ± 6% ~ (p=0.912 n=10+10)
GoParser 201ms ± 4% 195ms ± 1% ~ (p=0.089 n=10+10)
Reflect 455ms ± 1% 458ms ± 2% ~ (p=0.050 n=9+9)
Tar 155ms ± 2% 155ms ± 3% ~ (p=0.436 n=10+10)
XML 202ms ± 2% 200ms ± 2% ~ (p=0.053 n=10+9)
Change-Id: I33a7f383d79afba1a482cac6da0cf5b7de9c0ec4
Reviewed-on: https://go-review.googlesource.com/c/go/+/313514
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Add missing version check. Even though this is a new types2 error
we separate between the compiler and the types2 error message: we
have the compiler error message to match the compiler style, and
we have a types2-specific error message to match the types2 style
for these kinds of errors (for now).
Eventually we need to decide which style we like better and clean
this up.
Follow-up on https://golang.org/cl/301650.
Updates #395.
Change-Id: I5b779f345994c66b1f4a4db466466f98b7d3c491
Reviewed-on: https://go-review.googlesource.com/c/go/+/315169
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Bryan C. Mills
Keith Randall
David Chase
Dmitri Shuralyov
Cuong Manh Le
Alessandro Arzilli
Than McIntosh
Cherry Zhang
Lynn Boger
Matthew Dempsky
Robert Griesemer
Daniel Martí
Paul E. Murphy
eric fang