As part of #40267, 'go install' is now fully responsible for building
and installing executables. 'go get' will only be used to change
versions in go.mod. The -d flag no longer has any effect; its behavior
is the default.
When 'go get' is invoked inside a module on a main package outside of
the main module, it no longer prints any warning. In 1.16-1.17, we
suggested using -d in this situation, but we want
'go get example.com/cmd' to be able to upgrade a tool dependency
without needing -d to suppress the warning.
For #43684
Change-Id: I9daf29c123a5a0e382aa326d62721cb26fc26c19
Reviewed-on: https://go-review.googlesource.com/c/go/+/349997
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>
Do not require the byte or rune unread by the call to match the last
return from ReadByte or ReadRune, since in practice the
implementations of these methods (especially ReadByte) may also unread
bytes from other Read-style methods without reporting an error.
Explicitly allow the Seek-like behavior implemented by bytes.Reader
and bufio.Reader, which can “unread” bytes that were never actually
read.
Explicitly allow ReadByte or ReadRune to return an error after a call
to a non-ReadByte or non-ReadRune operation respectively.
(In practice, implementations today allow very liberal calls to
ReadByte and tend to be more strict about ReadRune, but it seems
simpler to keep the two definitions completely parallel.)
Like CL 349054, this is techincally a breaking change, but given the
long-standing behavior of the implementations in the Go standard
library (such as strings.Reader, bytes.Buffer, and bufio.Reader),
I believe it falls under the “specification errors” exception to the
Go 1 compatibility policy.
Fixes#48449
Change-Id: I61696a59770fe83c667377ba25a072762d3f6f19
Reviewed-on: https://go-review.googlesource.com/c/go/+/351809
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This is a clean port of CL 352615 from go/types to types2 with
renames from types -> types2.
Change-Id: Ib9bae3fd8b93c3bd6c56e4e039a296cb34b0eb47
Reviewed-on: https://go-review.googlesource.com/c/go/+/352869
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a port of CL 349629 from go/types to types2, adjusted to
make it work for types2. It also includes the necessary compiler
changes, provided by mdempsky.
Change-Id: If8de174cee9c69df0d0642fcec1ee7622b7c3852
Reviewed-on: https://go-review.googlesource.com/c/go/+/351455
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Pcdata are now separate aux symbols. Read them from aux, instead
of using funcinfo.
Change-Id: Ib3e4b5cff1e3329d0600504a8829a969a9c9f517
Reviewed-on: https://go-review.googlesource.com/c/go/+/352612
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
When writing an object file, most symbols are indexed in
NumberSyms. Currently, pcdata symbols are indexed late and
separately. This is not really necessary, as pcdata symbols
already exist at the time of NumberSyms. Just do it there.
As pcdata symbols are laid out in the pclntab in a special way at
link time, distinguish them from other symbols in the content
hash. (In the old code this was partly achieved by indexing them
late.)
Change-Id: Ie9e721382b0af2cfb39350d031e2e66d79095a3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/352611
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
As pointed out in #47916, the IsConstraint method becomes ambiguously
named if ever we allow interfaces with structural restrictions outside
of constraint position.
Add instead an IsMethodSet method, which has the opposite sense and
avoids this ambiguity. In a subsequent CL the IsConstraint method will
be removed, once x/tools has been updated to use the IsMethodSet API.
Updates #47916
Change-Id: I82ad16b111464b0cd2f354b8ecdd4b3f14796cd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/352616
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>
In #47916, consensus has emerged that adding a new constructor is
preferable to using setters for type parameters. This is more consistent
with the rest of the type API, which is immutable except in cases where
mutation is necessary to break cycles (such as Named.SetUnderlying).
This CL adds a new constructor NewSignatureType that accepts type
parameters and receiver type parameters, deprecating the existing
NewSignature constructor. SetTypeParams and SetRecvTypeParams are not
yet removed: this will be done in a follow-up CL once x/tools no longer
has a dependency on the old APIs.
Updates #47916
Change-Id: I9d04dcfd304344d2aa08e527b371c3faa9d738e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/352615
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>
The goal of this change is to improve the documentation
and make it easier to keep Link.NumberSyms and writer.contentHash aligned.
No functional changes.
A subsequent change will add conditions to contentHashSection.
Change-Id: I0a274f6974459d34d5a8553081f33ea4cd87f248
Reviewed-on: https://go-review.googlesource.com/c/go/+/352669
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
As of CL 247399 we use separate symbols for PCDATA. There is no
more need for writing PCDATA directly into the object file as a
separate block.
Change-Id: I942d1a372540415e0cc07fb2a01f79718a264142
Reviewed-on: https://go-review.googlesource.com/c/go/+/352610
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Fixes#48620
Change-Id: I37a5909ad27dc4a170929cb2e2ed1045cf524d59
Reviewed-on: https://go-review.googlesource.com/c/go/+/352629
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
We were putting type descriptor funcdata,
such as type..eq.[2]interface {}.arginfo1
in type.* or typerel.* instead of go.func.*.
Fix that.
Change-Id: I779e6be3dd91c8029f2c3dc0e10a7d597c16678f
Reviewed-on: https://go-review.googlesource.com/c/go/+/352071
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A subsequent change will duplicate most of case ver116.
Make it easier to read.
Change-Id: I3a93181c7f094b12715b8a618e9efef7a1438a27
Reviewed-on: https://go-review.googlesource.com/c/go/+/351909
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The test is flaky on Android. VDSO may not be enabled so it may
not have the original problem anyway.
Change-Id: I73c2902c682a44d893e0d4e34f006c2377ef8816
Reviewed-on: https://go-review.googlesource.com/c/go/+/352509
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
As discussed in #47658, Value already has CanAddr and CanInterface to
test if a call to Addr or Inteface, respectively, does not result in a
panic.
Therefore we add CanInt, CanUint, CanFloat and CanComplex to ease the
test for a possible panic in calling, respectively, Int, Uint, Float and
Complex.
Fixes#47658
Change-Id: I58b77d77e6eec9f34234e985f631eab72b5b935e
Reviewed-on: https://go-review.googlesource.com/c/go/+/352131
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Fix some comments.
Adjust capitalization for initialisms.
Use a println directly instead of emulating it.
Change-Id: I0d8fa0eb39547e2db8113fd0358136285b86f16a
Reviewed-on: https://go-review.googlesource.com/c/go/+/351462
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This will be required when we change from storing entry PCs in _func
to entry PC offsets, which are relative to the containing module.
Notably, almost all uses of the entry method were already called
on a funcInfo. Only Func.Entry incurs the additional module
lookup cost.
This makes Entry considerably slower, but it is probably
still fast enough in absolute terms that it is OK.
name old time/op new time/op delta
Func/Name-8 8.86ns ± 0% 8.33ns ± 2% -5.92% (p=0.000 n=12+13)
Func/Entry-8 0.64ns ± 0% 2.62ns ±36% +310.07% (p=0.000 n=14+15)
Func/FileLine-8 24.5ns ± 0% 25.0ns ± 4% +2.21% (p=0.015 n=14+13)
Change-Id: Ia2d5de5f2f83fab334f1875452b9e8e87651d340
Reviewed-on: https://go-review.googlesource.com/c/go/+/351461
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A subsequent change will alter the semantics of _func.entry.
To make that change obvious and clear, change _func.entry to a method,
and rename the field to _func.entryPC.
Change-Id: I05d66b54d06c5956d4537b0729ddf4290c3e2635
Reviewed-on: https://go-review.googlesource.com/c/go/+/351460
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
_func and funcinl are type-punned.
We distinguish them at runtime by inspecting the first word.
Prior to this change, we used 0 as the sentinel value
that means that a Func is a funcinl.
That worked because _func's first word is the functions' entry PC,
and 0 is not a valid PC. I plan to make *_func's entry PC relative
to the containing module. As a result, 0 will be a valid value,
for the first function in the module.
Switch to ^0 as the new sentinel value, which is neither a valid
entry PC nor a valid PC offset.
Change-Id: I4c718523a083ed6edd57767c3548640681993522
Reviewed-on: https://go-review.googlesource.com/c/go/+/351459
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
runtime.Func.{Name,FileLine} need to be able to
go from a *_func to a funcInfo. The missing bit of
information is what module contains that *_func.
The existing implementation looked up the module
using the *_func's entry PC. A subsequent change will
store *_func's entry PC relative to the containing module.
Change the module lookup to instead for the module
whose pclntable contains the *_func,
cutting all dependencies on the contents of the *_func.
Change-Id: I2dbbfec043ebc2e9a6ef19bbdec623ac84353b10
Reviewed-on: https://go-review.googlesource.com/c/go/+/351458
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Instead of growing 2x for < 1024 elements and 1.25x for >= 1024 elements,
use a somewhat smoother formula for the growth factor. Start reducing
the growth factor after 256 elements, but slowly.
starting cap growth factor
256 2.0
512 1.63
1024 1.44
2048 1.35
4096 1.30
(Note that the real growth factor, both before and now, is somewhat
larger because we round up to the next size class.)
This CL also makes the growth monotonic (larger initial capacities
make larger final capacities, which was not true before). See discussion
at https://groups.google.com/g/golang-nuts/c/UaVlMQ8Nz3o
256 was chosen as the threshold to roughly match the total number of
reallocations when appending to eventually make a very large
slice. (We allocate smaller when appending to capacities [256,1024]
and larger with capacities [1024,...]).
Change-Id: I876df09fdc9ae911bb94e41cb62675229cb10512
Reviewed-on: https://go-review.googlesource.com/c/go/+/347917
Trust: Keith Randall <khr@golang.org>
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <martin@golang.org>
We currently make dictionaries contain a relocation pointing to
methods that generic code might use, so that those methods are not
deadcode eliminated. However, with inlining we can end up not using
the dictionary, making the reference from the dictionary to the method
no longer keep the method alive.
Fix this by keeping the dictionary alive at generic interface call sites.
It's a bit of overkill, as we only need to keep the dictionary statically
alive. We don't actually need it dynamically alive, which is what KeepAlive
does. But it works. It ends up generating a LEAQ + stack spill that aren't
necessary, but that's pretty low overhead.
To make this work, I needed to stop generating methods on shape types.
We should do this anyway, as we shouldn't ever need them. But currently
we do use them! issue44688.go has a test that only works because it calls
a method on a shape type. I've disabled that test for now, will work on it
in a subsequent CL.
Fixes#48047
Change-Id: I78968868d6486c1745f51b8b43be0898931432a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/349169
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
In a previous change, I was too aggressive in substInstType() in not
generating methods for shape types during import. We do actually want to
generate the method nodes - we just don't want to generate method bodies
(which we would never use). We may need the method nodes for checking
types later in the compile (especially with inlining).
So, we do generate method nodes for shape types during import. In
order to avoid the name collision we previously had, we now add
".nofunc." to the method nodes for shape types (during import and in the
type substituter). We do that by passing in a 'isMethodNode' arg to
MakeInstSym. We keep the normal name (without ".nofunc") for any other
method nodes, and for the instantiated functions that help with
implementing the methods of fully-instantiated types. The ".nofunc"
names will never appear in the executable, since we don't generate any
method bodies for the method nodes of shape types.
Change-Id: I3e57e328691214140ca5f48d32011552d2a0d45d
Reviewed-on: https://go-review.googlesource.com/c/go/+/352470
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The dictionary argument is implicit; the user doesn't need to see it.
Update #48578
Change-Id: I367ba4b6622119d3e01aaded90463d16823915a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/352119
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
They tend to be things like ".shape.int" which are noisy, if not
otherwise confusing.
It would be nice to somehow print the real instantiations here, but that
requires keeping track of the dictionary argument so the instantiating
types could be found. One day, maybe, but not today.
Fixes#48578
Change-Id: I0968d24e110b6d47c9468c45372a6979575a8d29
Reviewed-on: https://go-review.googlesource.com/c/go/+/352118
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The sigprofNonGo and sigprofNonGoPC functions are only used on unix-like
platforms. In preparation for unix-specific changes to sigprofNonGo,
move it (plus its close relative) to a unix-specific file.
Updates #35057
Change-Id: I9c814127c58612ea9a9fbd28a992b04ace5c604d
Reviewed-on: https://go-review.googlesource.com/c/go/+/351790
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: David Chase <drchase@google.com>
Using setitimer on Linux to request SIGPROF signal deliveries in
proportion to the process's on-CPU time results in under-reporting when
the program uses several goroutines in parallel. Linux calculates the
process's total CPU spend on a regular basis (often every 4ms); if the
process has spent enough CPU time since the last calculation to warrant
more than one SIGPROF (usually 10ms for the default sample rate of 100
Hz), the kernel is often able to deliver only one of them. With these
common settings, that results in Go CPU profiles being attenuated for
programs that use more than 2.5 goroutines in parallel.
To avoid in effect overflowing the kernel's process-wide CPU counter,
and relying on Linux's typical behavior of having the active thread
handle the resulting process-targeted signal, use timer_create to
request a timer for each OS thread that the Go runtime manages. Have
each timer track the CPU time of a single thread, with the resulting
SIGPROF going directly to that thread.
To continue tracking CPU time spent on threads that don't interact with
the Go runtime (such as those created and used in cgo), keep using
setitimer in addition to the new mechanism. When a SIGPROF signal
arrives, check whether it's due to setitimer or timer_create and filter
as appropriate: If the thread is known to Go (has an M) and has a
timer_create timer, ignore SIGPROF signals from setitimer. If the thread
is not known to Go (does not have an M), ignore SIGPROF signals that are
not from setitimer.
Counteract the new bias that per-thread profiling adds against
short-lived threads (or those that are only active on occasion for a
short time, such as garbage collection workers on mostly-idle systems)
by configuring the timers' initial trigger to be from a uniform random
distribution between "immediate trigger" and the full requested sample
period.
Updates #35057
Change-Id: Iab753c4e5101bdc09ef9132eec84a75478e05579
Reviewed-on: https://go-review.googlesource.com/c/go/+/324129
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This adds ABIInternal to the race function declarations.
Change-Id: I99f8a310972ff09b4d56eedbcc6e9609bab0f224
Reviewed-on: https://go-review.googlesource.com/c/go/+/352369
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: Ie90d8dd3f644a96cda706c6a5286e99042e070bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/352129
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
Updates golang/go#37595
Change-Id: I7568e7416d5504e9dc67061c79f66e3a0d597dee
Reviewed-on: https://go-review.googlesource.com/c/go/+/351470
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: David Chase <drchase@google.com>
Change-Id: I9921ba5c29ada6ff06d147f6d9b46a29101c449c
Reviewed-on: https://go-review.googlesource.com/c/go/+/350694
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: David Chase <drchase@google.com>
Change-Id: Ic0a97fd7bb89865448e436e5c092415a29d8badf
Reviewed-on: https://go-review.googlesource.com/c/go/+/352009
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: David Chase <drchase@google.com>
Cribbed and modified from arm64, verify each transformation
rewrites a too-far conditional branch as expected.
Change-Id: I87d35085158ed7d7478aa9725b273401fcd0bd01
Reviewed-on: https://go-review.googlesource.com/c/go/+/347049
Trust: David Chase <drchase@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
This adds the changes for the register ABI in the runtime
functions for ppc64x:
- Add spill functions used by runtime
- Add ABIInternal to functions
Some changes were needed to the stubs files
due to vet issues when compiling for linux/ppc64.
Change-Id: I010ddbc774ed4f22e1f9d77833bd55b919d95c99
Reviewed-on: https://go-review.googlesource.com/c/go/+/351590
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This should have been part of https://golang.org/cl/340049 but I
overlooked it. That commit added fast path code when the destination
image was *not* an *image.RGBA. This commit edits func drawRGBA.
name old time/op new time/op delta
RGBA1-4 5.11ms ± 1% 1.12ms ± 1% -78.01% (p=0.008 n=5+5)
RGBA2-4 8.69ms ± 1% 2.98ms ± 1% -65.77% (p=0.008 n=5+5)
Updates #44808.
Updates #46395.
Change-Id: I899d46d985634fc81ea47ff4f0d436630e8a961c
Reviewed-on: https://go-review.googlesource.com/c/go/+/351852
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
In CL 349613,we have supported types.IdentityStrict() that does strict
type comparison.
Therefore, OCONVNOP becomes a possible case in call.X.Op().
Fixes#48604
Change-Id: Ibab27ffcf09656e3380314662f05f38294c1c6ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/351857
Trust: Dan Scales <danscales@google.com>
Trust: David Chase <drchase@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
For #48617
Change-Id: I6c00b7912c441ac323a0adede63b7d4a9ae6f92d
Reviewed-on: https://go-review.googlesource.com/c/go/+/351858
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 349614. we removed the early transformation code that
was needed to create the implicit CONVIFACE nodes.
Because the transformCall function is not called when translating OFUNCINST.
So we add in needed CONVIFACE nodes via typecheckaste().
Fixes#48598
Change-Id: If9dc7040cdc38ef2e52fdbb08c840095651426f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/351856
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Deal correctly with a blank local variable with type param type. This is
a special case, because a blank local variable is not in the fn.Dcl
list. In this case, we must explicitly create a new blank node with the
correct substituted type, so we have correct types if the blank local
variable has an initializing assignment.
Fixes#48602
Change-Id: I903ea44b29934e180404e32800773b7309bf297b
Reviewed-on: https://go-review.googlesource.com/c/go/+/352117
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Based on comments in CL 348469.
Note that with this change, F.Fuzz no longer calls
runtime.Goexit. This simplifies our logic and makes F.Fuzz more
predictable.
Change-Id: I6c3c65b0e8e8f261621cbe2f17375e8164ef60a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/351316
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>
gofmt is pretty heavily CPU-bound, since parsing and formatting 1MiB
of Go code takes much longer than reading that amount of bytes from
disk. However, parsing and manipulating a large Go source file is very
difficult to parallelize, so we continue to process each file in its
own goroutine.
A Go module may contain a large number of Go source files, so we need
to bound the amount of work in flight. However, because the
distribution of sizes for Go source files varies widely — from tiny
doc.go files containing a single package comment all the way up to
massive API wrappers generated by automated tools — the amount of
time, work, and memory overhead needed to process each file also
varies. To account for this variability, we limit the in-flight work
by bytes of input rather than by number of files. That allows us to
make progress on many small files while we wait for work on a handful
of large files to complete.
The gofmt tool has a well-defined output format on stdout, which was
previously deterministic. We keep it deterministic by printing the
results of each file in order, using a lazily-synchronized io.Writer
(loosly inspired by Haskell's IO monad). After a file has been
formatted in memory, we keep it in memory (again, limited by the
corresponding number of input bytes) until the output for all previous
files has been flushed. This adds a bit of latency compared to
emitting the output in nondeterministic order, but a little extra
latency seems worth the cost to preserve output stability.
This change is based on Daniel Martí's work in CL 284139, but using a
weighted semaphore and ephemeral goroutines instead of a worker pool
and batches. Benchmark results are similar, and I find the concurrency
in this approach a bit easier to reason about.
In the batching-based approach, the batch size allows us to "look
ahead" to find large files and start processing them early. To keep
the CPUs saturated and prevent stragglers, we would need to tune the
batch size to be about the same as the largest input files. If the
batch size is set too high, a large batch of small files could turn
into a straggler, but if the batch size is set too low, the largest
files in the data set won't be started early enough and we'll end up
with a large-file straggler.
One possible alternative would be to sort by file size instead of
batching: identify all of the files to be processed, sort from largest
to smallest, and then process the largest files first so that the
"tail" of processing covers the smallest files. However, that approach
would still fail to saturate available CPU when disk latency is high,
would require buffering an arbitrary amount of metadata in order to
sort by size, and (perhaps most importantly!) would not allow the
`gofmt` binary to preserve the same (deterministic) output order that
it has today.
In contrast, with a semaphore we can produce the same deterministic
output as ever using only one tuning parameter: the memory footprint,
expressed as a rough lower bound on the amount of RAM available per
thread. While we're below the memory limit, we can run arbitrarily
many disk operations arbitrarily far ahead, and process the results of
those operations whenever they become avaliable. Then it's up to the
kernel (not us) to schedule the disk operations for throughput and
latency, and it's up to the runtime (not us) to schedule the
goroutines so that they complete quickly.
In practice, even a modest assumption of a few megabytes per thread
seems to provide a nice speedup, and it should scale reasonably even
to machines with vastly different ratios of CPU to disk. (In practice,
I expect that most 'gofmt' invocations will work with files on at most
one physical disk, so the CPU:disk ratio should vary more-or-less
directly with the thread count, whereas the CPU:memory ratio is
more-or-less independent of thread count.)
name \ time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 11.9s ± 2% 2.7s ± 3% 2.8s ± 5%
name \ user-time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 13.5s ± 2% 14.4s ± 1% 14.7s ± 1%
name \ sys-time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 465ms ± 8% 229ms ±28% 232ms ±31%
name \ peak-RSS-bytes baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 77.7MB ± 4% 162.2MB ±10% 192.9MB ±15%
For #43566
Change-Id: I4ba251eb4d188a3bd1901039086be57f0b341910
Reviewed-on: https://go-review.googlesource.com/c/go/+/317975
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
